[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Duplicate or near-duplicate messages on u-blox M8

From: Gary E. Miller
Subject: Re: Duplicate or near-duplicate messages on u-blox M8
Date: Wed, 26 Feb 2020 19:05:55 -0800

Yo Luke!

On Wed, 26 Feb 2020 19:23:56 -0700
Luke Hutchison <address@hidden> wrote:

> > Patience is not really what you want from us, you want answers, and
> > I'm trying to give those to you.  Many of us are happy to take the
> > time to help people get it right.  GNSS do not really work the way
> > you think they do, so try to be flexible.  
> As I have said in previous messages, I am grateful that you are
> taking the time to look into this issue. However I do want to point
> out that emotionally-charged phrases like "useless" and "pay
> attention" and "I'll ask again" do not present a welcoming
> environment to a newcomer. I have been on enough open source mailing
> lists for the last 30 years to know that communities that don't fall
> over themselves to be diplomatic and generous towards newcomers
> rarely last long, and eventually implode. I have thick skin, but you
> will alienate some people with language choices like this, and you
> have used phrases like this in every message so far.

Maybe read a little better, try to answer questions asked, not repeat
mistakes previously pointed out, and I'll not need to use such words.

And remember, any pop-psych site will remind you the only person you
know you can change, is yourself.

> With that out of the way, I'll try to condense my responses as each
> successive response back and forth is getting longer.

Good.  Stick to what you see, how you see it, and what you think it

> > OK, thanks for explaining. I just tested this:
> > I'm unclear what you tested and how?  
> > > height = 1332.800
> > > hMSL = 1351.616
> > > geoid separation = -18.816 (same exact value as before for the
> > > same location, despite a drift in altitude measurement)  
> > Where did you get that?  cgps, xgps, ubxtool, gps_udm?  
> I obtained height and hMSL using the only method you showed me so far
> to determine the geoid -- exactly as you suggested it. `gpspipe -R -n
> 100 > raw.log` followed by `ubxtool -f raw.log -v 2`. I'm trying to
> follow your instructions exactly.

Good.  Or you could just use cgps or xgps and skip a ton of steps.  The
data is right there, decoded and everythong.  I use the raw log as I
have no access to your running daemon, but locally you use the simple
tools gpsd provides.

> Yes, I did a hard reset of the receiver because after the receiver
> started outputting NMEA in `gpspipe` output, I wanted to go back to
> defaults, particularly after your emphasis on the binary protocol
> being the gold standard.

Note that a "hard reset" does not necessarily return to defaults.  Your
assumptions keep tripping you up.  A "hard reset" merely reverts to the
saved settings.  Saved, as opposed to current (not saved) settings.

> I have no idea what switched the receiver to
> NMEA mode.

No need to chase that until you get an idea.  Speculation is not
helpful, yet.  Work on good experimental technique.

> The only tools I have even used with gpsd during the
> course of this conversation thread are `gpspipe`, `gpscat`, `cgps`
> and `xgps` -- and I have used all of them with default values. The
> only commandline switch I may have supplied (e.g. to `gpscat`) was
> the device, e.g. `-F /dev/ttyUSB0`. I haven't configured anything or
> overridden any defaults for any of those programs. So what do you
> think switched the receiver from binary to NMEA mode?

No idea.  Speculation just confuses things.

> systemd sucks for sure, but all it does is launch the cgps binary,
> nothing more, nothing less. I sent you the .service file previously,
> but this is the launch command:

Uh, systemd does not launch cgps.  systemd manages daemons, not client
programs  But, as I said before, I don't do systemd.  So, useless info to

> And since none of the three above environment variables is either set
> or is non-empty in the two gpsd config files, this commandline
> reduces to simply:
> /usr/sbin/gpsd

Prove it.  Try this, as root:
        pstree -paul | fgrep gpsd

> > > The code is junk, for sure. Do you have any specific issues you
> > > can point out, and/or pointers to a good (simple) gpsd client
> > > that could be studied to produce a better ROS gpsd client?  
> > I have many specific issues with that code, but I have more than
> > enough issues with the gpsd to care.  I see a 4 year old MR waiting
> > on the gps_udm code.  Not gonna waste my time on that.  
> I am not debating that gps_udm is good, I already said it's junk.

Yup.  As you said, you already said that.  No need to repeat yourself.

> However it's the only game in town in ROS right now.

Not my problem.  I'd be happy to work with a maintainer of it, but no
such thing exists.  So, not my problem.

> I'm asking for a
> concrete pointer to some actually-good gpsd client code, so that I
> can strip out gps_udm and replace it with something more modern,
> clean, and correct.

None of the gpsd clients make sense to you?  gpsd has C, C++, Python
and PHP clients.

> Can you please point me to some client code you
> actually like, so I can take a look?

cgps, xgps, gpspipe, gpscat, gpxlogger, etc.  All there in gpsd.

Many ways to skin this cat.

> It sounds like you still don't have an idea of what is causing the
> problem.

Ah, you have mentioned several "problems".  Some, like "altitude" seem
to be coming and going, and are exagerated by the old and obviously
broken gps_udm client.  The others, like epX changing, and slight jitter
in lat/lon, are normal.

So, how about, in the interests of brevity, you pick one and
focus on that one, instead of any of my word choices that you are

> I will try capturing a raw log that shows the alternating
> altitude.

I guess you did not read my admonishments that "altitude" is an
undefined and useless term.  Please note I repeat myself only when
you fail to get it the first time.

In the future, for brevity, use altMSL or altHAE.  Use them precisely,
or don't bother.  When you continue to think "altitude" you are setting
yourself up to fail.

Another thing to do, is to look at that lightly processed raw data
this way:
        ubxtool -v 2

That will show NMEA and lightly decoded u-blox binary in real time.

> Hopefully the problem will show up in the raw log, and not
> just in the behavior of clients like cgps and xgps.

I don't care where the issue may be, and neither should you.  It is
where it is.  You watch the data flow, check it for what you expect, and
the anomoly is where you find it.

Just keep in mind that "altitude" is undefined and not to be ever
mentioned again.

And we know one client error with "altitude" is in the gps_udm code.  So
look at that last.

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpwQQ_CGvyoC.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]