gpsd-dev
[Top][All Lists]
Advanced

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

Re: release?


From: Gary E. Miller
Subject: Re: release?
Date: Sun, 1 Jan 2023 19:14:45 -0800

Yo Fred!

Sounds like you have some ideas.  I look forward to the results of your
looking.  But too late for this release.

On Sun, 1 Jan 2023 19:08:43 -0800 (PST)
Fred Wright <fw@fwright.net> wrote:

> 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




RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

Attachment: pgpoU1u26TDb4.pgp
Description: OpenPGP digital signature


reply via email to

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