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

[Gary E. Miller]

Yo Luke!

I dont bother to respond to whinging.  If you can boil that down to
a few answers to questions I asked, or a few technical questions,
then I'll look at what you write.

I have enough yak to shear without more bikehsedding to do.

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

> [+gpsd-users]
> 
> On Wed, Feb 26, 2020 at 8:06 PM Gary E. Miller <address@hidden> wrote:
> 
> > 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. 
> 
> Look, I have tried to read and respond to every word, and do
> everything exactly as you have asked -- at first exactly following
> the FAQ, and then after you gave me the actual methods you want me to
> use, following your methods instead. And I'll keep trying. The
> mistake I think you keep pointing out is that I missed giving the
> full commandline I used on more than one occasion.
> 
> 
> > Good.  Or you could just use cgps or xgps and skip a ton of steps.
> > The data is right there, decoded and everythong.  
> 
> 
> That is pretty much exactly the thing that you have told me not to do
> at least three separate times, as far as I can can interpret the
> following:
> 
> (1)
> 
> > > Here is an example of output captured from the cgps display:  
> > Not useful.  
> 
> (2)
> 
> > Do not mistake what cgps shows for what the M8 is sending.  
> 
> (3)
> 
> > > Here are the first few messages displayed by cgps,  
> > Once again, useless.  You are not using cgps as your client and the
> > way cgps interacts with gpsd is not how your client is interacting
> > with gpsd.  
> 
> 
> As far as feedback like this:
> 
> I use the raw log as I
> > have no access to your running daemon, but locally you use the
> > simple tools gpsd provides.
> >  
> 
> ..can you please put together a FAQ section with some simple,
> canonical examples of commands (i.e. commands with the most useful
> default switches) for debugging: capturing logs, decoding logs,
> decoding live gpsd data, replaying logs, decoding binary format data,
> etc. -- and with a short explanation of when to use raw gpsd data,
> and what differences to expect when using data received in a client
> like cgps? The info you sent me so far has been very helpful. But if
> it had already been posted on the gpsd site, it would have saved me a
> lot of time, and would have saved you having to coach me in this
> stuff. Remember I'm coming at this with zero knowledge, and you're
> stating a lot of usage patterns and commands like they should already
> be obvious to me -- they're not. It will probably save you time in
> the future too when others need to report bugs if the site has all
> this info.
> 
> > 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.
> >  
> 
> I did not speculate about anything. I stated I did not know. If you
> have not seen this happen before, and/or don't know the cause, that's
> fine. But it is fair for me to at least ask if you have seen this
> phenomenon before, because I am brand new to this and you are not.
> 
> > /usr/sbin/gpsd $GPSD_OPTIONS $OPTIONS $DEVICES
> >
> > Uh, systemd does not launch cgps.  
> 
> 
> Actually that's exactly what it does.
> 
> 
> > systemd manages daemons, not client programs  
> 
> 
> The way it does this is by maintaining a socket file to see if the
> daemon (the client program) is up. Other that that, pretty much the
> *only* thing systemd does is launch client programs. Some client
> programs use some of the more advanced facilities of systemd, but
> cgps does not -- the only thing the Fedora cgps package does is to
> include the .service file so that systemd knows the name of the
> binary and the commandline arguments. So there is absolutely zero
> difference between whether I launch cgps or systemd does, assuming
> the commandline arguments are the same in both ways of launching cgps.
> 
> > 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
> >  
> 
> $ pstree -paul | fgrep gpsd
>   |-gpsd,22880,nobody
> 
> 
> > But, as I said before, I don't do systemd.  So, useless info to
> > me.  
> 
> 
> So forget I mentioned systemd, if you want. If it will make you more
> comfortable, I can launch cgps manually in the future, with no
> commandline arguments -- but I guarantee there will be zero
> difference in behavior or logs between systemd launch and manual
> launch.
> 
> > 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 more or less offered to write a new ROS gpsd client from scratch in
> my last message, so I would be that potential maintainer.
> 
> > 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.
> >  
> 
> Of course I can study those. But you're also not always reading my
> questions -- I didn't ask for a list of which clients were included
> in the gpsd repo. I asked you what code you actually like, since you
> have strong opinions about what a good gpsd client should look like
> (or at least what a bad gpsd client looks like). So among the clients
> available in the gpsd repo, is there one in particular that has good
> quality code, and uses the gpsd API in an optimal way? If they're all
> of equal quality, I'll just pick one.
> 
> 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
> > misunderstanding?
> >  
> > > 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.
> >  
> [...]
> 
> > Just keep in mind that "altitude" is undefined and not to be ever
> > mentioned again.  
> 
> 
> Let's survey the clients you recommended to me (other than gpscat,
> which is irrelevant) to see how they represent altMSL or altHAE:
> 
> `cgps`: "Altitude"
> `xgps`: "Altitude"
> `gpspipe -w`: "alt"
> `gpxlogger -D 3`: "ALTITUDE: altitude: [...]"
> 
> Therefore I don't think it's fair for you to come down hard on my use
> of the word "altitude" when gpsd clients all use the word "altitude"
> exclusively, rather than altMSL or altHAE. The standard clients don't
> even specify which altitude number they are citing, they just call it
> "altitude". If you want this word to never be mentioned again, you
> need to fix all those clients.
> 
> So for your future reference, if I ever use the word "altitude",
> please interpret it as "the number shown in the 'Altitude' display of
> the cgps client". I don't even know which of the two options the
> client is displaying, but I presume you know. If you ask me to give
> you specific altMSL or altHAE numbers, I will look those up using the
> commandline patterns you have given me.
> 
> 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.
> >  
> 
> Thanks. This should also be in the FAQ under debugging instructions,
> along with any similar commands for other GPS chipsets.
> 
> The output I get from `ubxtool -v 2 > /tmp/ubx.log` is attached.
> 
> > 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.  
> 
> 
> I'm not saying I hope to see the problem in a specific place. I'm
> saying I hope I can find evidence to reject any of the currently
> possible hypotheses, such as that the M8 hardware is buggy or quirky,
> or that cgps' binary u-blox driver may be buggy or doesn't understand
> the M8N's hardware's quirks, or that clients are interpreting cgps'
> update messages in a way that causes the clients to perceive the
> behavior I have described even though the problem is not in cgps
> itself. The only way to collect this evidence is to look at logs, as
> you have repeatedly pointed out.




RGDS
GARY
---------------------------------------------------------------------------
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

pgpQAB7kxcPJL.pgp
Description: OpenPGP digital signature