Re: ✘ Add NEO-M9N NMEA logfile.

[Gary E. Miller]

Yo Fred!

On Wed, 29 Jul 2020 17:32:48 -0700 (PDT)
Fred Wright <fw@fwright.net> wrote:

> > I'll ask again: what mishandling?  On what u-blox model?  Works for
> > me.  
> 
> I already answered this, though it shows as "Message not available"
> in the archive.  Here's the main excerpt:

If the archive did not get it, then I likely did not either.

> > It's the known problem with multiple GSV groups.  At one point, a
> > special kludge was added for the specific case of GPGSV/GLGSV (and
> > only if they appear in that order), but it doesn't work for the
> > more general case. The result is that each update in the
> > GP/GL/GA/GB case produces three successive SKY reports, with
> > increasing sets of satellites, restarting on each update cycle.
> > I'm pretty sure the reason it's only three instead of four is due
> > to the GP/GL coagulation.

Oh, as you say, known problem.  If you have an idea to fix it then
have at it.

> > Then just run one of the relevant clients (though in trying it for
> > this email I stubled across a previously unknown crash in xgps).
> > The display is very spastic, as many of the satellites keep coming
> > and going on every update.  
> -----------------------------------------------------------------------------
> 
> BTW, gpsmon in this case is even more spastic than the other
> programs,

Everything gpsmon does is spastic.  I never use it.  Beyond repair.

> The short answer is that the presence of NMEA sentences poisons the 
> handling of u-blox data in many cases.  This only became a problem
> when "binary" stopped disabling NMEA.

So turn off NMEA.  The number of complaints about what gpsd
turned on and off in u-blox keeps rising.  No agreement on
what to do, so let every use suit himself.

> In theory, gpsd could do a better job of "blending" NMEA and binary,
> but that's a significant undertaking.

Yes, and for no win over just going all binary.  Or all NMEA.

> > Exact same code is called elsewhere.  So not the code that is
> > called, but when it is called.  
> 
> Exactly.  Though it turns out that this is the right place (but not
> the right conditions) to call it.

Suggestions welcome.  The current code works for some, but not all.

> > A lot longer than that.  There was a long thread about it here early
> > this year.  That code that 35b1cfYea changed fixed some really,
> > really, old and bad bugs.  
> 
> Care to elaborate?

A long thread, s/b easy to find.

> > Which is solved when the receiver is configured for NMEA or binary.
> > Which gpsctl -b/-n does.  But should happen on init, which e2e0f8d5
> > was doubly doing for most people.  Seems not at all for you.  
> 
> No, with the recent changes, "binary" means NMEA+binary, which is 
> problematic.

If gpsctl -b is broken for you, please proved a log from gpsd of what
it is doing.  Works for me.

> > GSV every second would be a bug.  The receiver only updates GSV
> > every 10 seconds or so.  SVINFO is updated at the same rate the
> > receiver updates its internal data.  So 10 seconds is about right.  
> 
> 1Hz is both the factory-default update rate for GSV, and the rate 
> configured by gpsd when it's configuring for NMEA.

Yes.

> If you're seeing 
> something different, it probably means that you've reconfigured your 
> receiver(s) and avoided having gpsd change the settings.

I am not.

> But testing
> with reconfigured receivers isn't representative of what most users
> will see.

Lost me.  Way too many independent threads going around here...

> > Yup, forever.  I do not think a perfect solution is possible until
> > u-blox 9.  
> 
> It just means that it has to poll CFG-PRT to determine the ID before
> doing anything that cares about it.  The code that I'm currently
> testing (though I had to put that aside for the library stuff) does
> exactly that.

Sadly polling of u-blox is problematic.  u-blox drops requests
far too often for polling to be reliable.  I'd be happy if you got it
to work, but not this cycle.  Better to never need CFG-PRT.  It is
never needed on 9-series, and a PITA on earlier firmware.


> >> partially motivated by some confusion over how to handle the
> >> GR-601W, I was reluctant to touch that code without an actual
> >> GR-601W to test with.  
> >
> > I can get you one, if that is your only hold-up.  But the same issue
> > happens on 7 and 8 series.  
> 
> I currently have a way to connect any MikroElektronika GPS/GNSS
> "Click" module to an FTDI serial cable, which is functionally similar
> to the GR-601W.  I have Click modules with LEA-6S, NEO-M8N, and
> NEO-M9N.  The LEA-6S case is closest to the GR-601W.  The biggest
> difference is that the USB/UART adapter here is FTDI rather than
> Prolific.  In most respects, that's a plus (Google "Prolific vs FTDI"
> to see), but it does mean that it's not fully crapwise-compatible
> with the GR-601W.

So now you don't need one?  Let me know your final answer.

> I'd planned to verify that I hadn't broken autobaud, even though none
> of the changes I've made should interact with autobaud.  But it
> appears that autobaud was already broken, at least as far back as
> 3.19.  Fortunately, the new option to set the speed makes that less
> problematic.

Odd, autobaud working for me.  Just way slow.

> >> Thus, the short-term fix would be to put back the
> >> two-way mode-switched mask as before, except for including the
> >> RTCM3 bit along with UBX.  
> >
> > Which reverts all the problems that got fixed.  
> 
> Which problems?

As discussed on this list.

> > Nope.  The old code would readily brick the u-blox.  Can't have
> > that.  
> 
> In which case?  The most dangerous thing it currently does is to
> start probing before it knows it has the right baud rate, potentially
> sending complete garbage to the receiver.  But that's a completely
> separate issue.

As discussed on this list and IRC.  When the protocol mask conflicts
with the enabled messages, you get nothing.  N ot gonna go nack to that
mess.

> I've certainly never seen a case of a receiver getting literally 
> "bricked" (i.e. in a state where even a power cycle wouldn't
> recover).

Most u-blox have no way to save config.  Those that do can be bricked.

> Including NMEA data in "binary" mode at the very least greatly
> increases the probability of data overrun at lower baud rates.

Yup, no one disagrees with that.  How to ensure that is the issue.

> 1) Adjust the protocol mask.

Nope.  Not gonna do that.  Bricking is not an option.

> 2) Adjust the individual message/sentence rates.

Yup.  Which is what gpsd does now, with a few holes.

> Clearly #2 could cause much more interference with user configuration
> than #1, so it's less desirable.

Blocking all NMEA or all binary with out user intervention is more
desireable?  Nope.  That is the bug that got fixed.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

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

pgp2XqGkBW7_O.pgp
Description: OpenPGP digital signature