Re: ✘ Add NEO-M9N NMEA logfile.

[Fred Wright]

On Tue, 14 Jul 2020, Fred Wright wrote:
> On Mon, 13 Jul 2020, Gary E. Miller wrote:
[...]
> > I must admit I never run a u-blox in NMEA mode.
>
> If switching to u-blox mode worked properly, I might never have noticed this 
> problem.  If you're using full u-blox mode with a u-blox 9, you must have 
> confgured it with ubxtool, since neither GPSD's built-in reconfiguration nor 
> "gpsctl -b" is sufficent with a u-blox 9.  But ordinary users shouldn't have 
> to resort to ubxtool to get reasonable behavior.
>
> 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.

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.

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.

I was able to bisect the (two) mode-switching problems, as follows:

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).  But 
it seems that the intended reconfigure code never worked properly (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.

The manual reconfigure via "gpsctl -b" was broken by commit 35b1cfea.  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), 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.

With regard to fixes:

There seem to be multiple issues with the intended reconfigure code in 
gpsd, including some mishandling of the port ID.  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.  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.

The commit message for 35b1cfea 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.  The whole "NMEA vs. binary" view is somehat 
oversimplified in general, anyway.  There are certain circumstances where 
getting both NMEA and binary is desirable, but this is uncommon, and also 
a source of trouble as noted above.  I think the best solution to that 
issue is to have another "mixed" mode that could be requested, but I don't 
think it makes sense to implement that for the upcoming release, 
particularly given that it impacts many drivers.  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.  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.  One could still get "mixed" mode via ubxtool, if 
desired.

Fred Wright