[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, 30 Jul 2020 01:08:15 -0000
User-agent: Alpine 2.23 (OSX 453 2020-06-18)

On Mon, 13 Jul 2020, Gary E. Miller wrote:

Your recent commit message:

   2cb46914 by Fred Wright at 2020-07-13T14:32:42-07:00
   Add NEO-M9N NMEA logfile.

   This is intended primarily as a sample of xxGSV sentences with four
   simultaneous GNSSes.  This is currently handled poorly, and the
   included .chk file reflects that.  The latter will need to be updated
   once the code is fixed.

Looking at the chk file for all of 5 seconds and looks good to me.

What do you see wrong?

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.

The effect is obvious with any of the clients that display constellation info. To see it with the logfile:

$ GPSD_HOME=. ./gpsfake -S test/daemon/ublox-neo-m9n-nmea.log

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.

It gets more complicated with multiple signals. Although each satellite is reported separately for each signal, it really only exists once, and with only one el/az. The only per-signal aspect is the SNR, but the current architecture isn't designed for that. Although the earlier issue is specific to NMEA, I believe this is a more general issue, and not one that's so easily fixed.

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.

Fixing the multi-signal problem may be too ambitious for this release, considering it impacts almost everything in the chain. Though a cheap fix that reports a mean SNR across signals might be doable. Of course most users don't have multi-signal receivers, anyway. The only dual-frequency receiver I have is GPS/GLONASS only, so it's not a fully general test case.

Fred Wright

reply via email to

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