Re: release?

[Fred Wright]

On Sat, 31 Dec 2022, Gary E. Miller wrote:
> On Sat, 31 Dec 2022 00:57:17 -0800 (PST)
> Fred Wright <fw@fwright.net> 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

sattest.log
Description: Binary data