[Top][All Lists]

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

Re: ✘ Add NEO-M9N NMEA logfile.

From: Fred Wright
Subject: Re: ✘ Add NEO-M9N NMEA logfile.
Date: Thu, 23 Jul 2020 14:40:29 -0700 (PDT)
User-agent: Alpine 2.23 (OSX 453 2020-06-18)

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

reply via email to

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