Re: ✘ Add NEO-M9N NMEA logfile.

[Gary E. Miller]

Yo Fred!

On Thu, 23 Jul 2020 14:40:29 -0700 (PDT)
Fred Wright <fw@fwright.net> wrote:

> > I was figuring on fixing the GSV problem before fixing the
> > mode-switching problem, since the latter makes it convenient to
> > test the former.  But I also added the logfile as a hedge, and of
> > course one can always put the receiver in NMEA mode and launch gpsd
> > with -b to get NMEA behavior.  
> 
> I've now switched my position on the order of those fixes, since:
> 
> 1) The GSV mishandling is a long-standing problem, albeit one that's 
> becoming more significant with advances in receiver technology and 
> satellite deployments.

I'll ask again: what mishandling?  On what u-blox model?  Works for me.

> 2) The mode-switching problems were introduced since the 3.20
> release, making them regressions which should be considered release
> blockers.  I'd initially thought that they were related to the u-blox
> 9, but actually it's the gpsd version not the u-blox version that
> matters.

News to me.  Care to elaborate?

> 3) If the u-blox mode switching worked properly (or at least as well
> as it did in 3.20), the GSV problem would be much less important in
> the u-blox case.

Care to elaborate?

> The automatic reconfigure in gpsd was broken by commit e2e0f8d5.
> That change isn't unreasonable per se, since gpsd was formerly doing
> a complete reconfigure upon receipt of any CFG-PRT message, even one
> that didn't apply to its own port (e.g., a response to a CFG-PRT from
> ubxtool).

Yup, the CFG-PRT was broken.  And that code was redundant:

-            /* Need to reinitialize since port changed */
-            if (session->mode == O_OPTIMIZE) {
-                ubx_mode(session, MODE_BINARY);
-            } else {
-                ubx_mode(session, MODE_NMEA);
-            }

> But it seems that the intended reconfigure code never
> worked properly

Exact same code is called elsewhere.  So not the code that is called,
but when it is called.

> (at least in some cases), and the only reason this
> went unnoticed is that the extra reconfigure in response to CFG-PRT
> gave it a second bite of the apple.

What exactly is not happending for you?

> The manual reconfigure via "gpsctl -b" was broken by commit 35b1cfYea.

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.

>  I'd puzzled over how a change that only set more bits in the
> protocol mask could result in less UBX data, until I realized that
> that wasn't what was really happening at all.  The problem is that
> the receiver now emits both NMEA and UBX data, which isn't
> necessarily a bad thing (though it's probably undesirable in common
> cases),

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.

> but the presence of the mishandled GSV data causes constant
> clobbering of the correct data from SVINFO.  This is aggravated by
> the fact that SVINFO is only appearing every 10 seconds, while GSV
> data is appearing every second.

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.

I'm still not understanding what you do not like about GSV??

> With regard to fixes:
> 
> There seem to be multiple issues with the intended reconfigure code
> in gpsd, including some mishandling of the port ID.

Yup, forever.  I do not think a perfect solution is possible until
u-blox 9.

> I've been aware
> of that for a while, but since it seems to have been at least
> 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.

> But since it's now causing real trouble, it makes sense to fix
> it, and I've cobbled together what should be a good enough
> approximation of a GR-601W for this test purpose.

I'm still not understanding what you do not like about GSV?  Or what
you define as "real trouble".


> The commit message for 35b1cfyiwea doesn't elaborate on exactly what the
> ill effect of "munging" the protocol mask was, but it seems likely
> that it has to do with the RTCM enable.

Nope.  Read the u-blox doc and the issue should be obvious.


> The whole "NMEA vs. binary"
> view is somehat oversimplified in general, anyway.

Yup, which is why the code has  been moving away from that.

> There are certain
> circumstances where getting both NMEA and binary is desirable,

Exactly what 35b1cfyiwea fixed..

> this is uncommon, and also a source of trouble as noted above.

I'm still not clear on this "trouble".

> I
> think the best solution to that issue is to have another "mixed" mode
> that could be requested,

That is what ubxtool does.

> but I don't think it makes sense to
> implement that for the upcoming release, particularly given that it
> impacts many drivers.

Nope, just u-blox.

> In any case, since RTCM (both v2 and v3) is a
> binary protocol, it makes sense to include it with UBX in the
> protocol mask.

Mandatory.

> 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.

> One could still get "mixed" mode via ubxtool, if
> desired.

Nope.  The old code would readily brick the u-blox.  Can't have that.

So now that we have discussed those commits, canm you describe the GSV
problem you keep alluding to?

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

pgpy17eEBjba1.pgp
Description: OpenPGP digital signature