[Top][All Lists]

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

Re: release?

From: Fred Wright
Subject: Re: release?
Date: Sun, 1 Jan 2023 19:08:43 -0800 (PST)

On Sat, 31 Dec 2022, Gary E. Miller wrote:
On Sat, 31 Dec 2022 00:57:17 -0800 (PST)
Fred Wright <> wrote:

I didn't see any issues with build/check on a wide variety of
platforms. But the skyview spasticity is still present.  It can be
seen with cgps, xgps, or xgpsspeed (xgps being the most obvious).
I'm using a uBlox M9N receiver with a multi-system antenna.

That is because your GNSS is being spastic about sending sky data.
There is no right answer, short of fixing the receiver firmware.

Nope. And I've attached a logfile (-Rw) to show that. If you look at it with ubxtool, you can see that numSvs only varies between 38 and 39 during this interval, while the xgps display toggles at 1Hz between that and ~30 during that interval. It almost certainly relates to the alternate SKY reports with no satellites. I suspect that the only reason all the satellites don't come and go relates to the timing of building the display in the client vs. the list being cleared and rebuilt every second.

If the intent is that SKY reports with no satellites are legitimate (just to report slightly changed DOP values), then all clients need to be fixed to retain the old satellite list when that happens, and this behavior needs to be clearly documented so that third-party programs can be fixed as well.

The prRes behavior is another story. I started looking into this, but I don't have any more time tonight. The values are reported in both UBX-NAV-SAT and UBX-NAV-SIG, so my initial guess was an inconsistency between the two, with them fighting each other in the output reports. But the few cases I spot checked looked like they were consistent between the messages.

The actual values of prRes are also "interesting". Although the quantity is nominally defined as signed, I don't see how a residual can possibly be negative. But many of the values reported by both ubxtool and xgps are negative, with some strange scaling between the two that also seems inconsistent with the definition (the doc says 0.1m units).

I do have some ideas for after the release to add a lot of latency and
reduce flicker.  My guess is it will have to be an optionas the extra
latency will annoy many.

I've also had some ideas on how to fix issues with GSV, which don't add much latency, but that isn't relevant here, or in any other case where the receiver provides single reports covering all satellites.

With the 3.24 xgps (and the latest gpsd), both Sats Seen and Sats
Used toggle between zero and values that are probably correct.  With
the current xgps (and still the latest gpsd), Sats Used is reasonably
stable (varying a bit as one would expect; right now ~18), but Sats
Seen toggles between two very different values (right now 32 vs. 40),
where the larger is probably correct.

You can thank NMEA 4.11 for that.  It has to do with the way the
receiver dribbles out the sky data.

Nope. This is a u-Blox receiver providing UBX binary messages (the gpsd default behavior), except in the gpsmon case.

Fred Wright

Attachment: sattest.log
Description: Binary data

reply via email to

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