gpsd-dev
[Top][All Lists]
Advanced

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

Re: ✘ Release blockers?


From: Gary E. Miller
Subject: Re: ✘ Release blockers?
Date: Mon, 30 Dec 2019 20:33:46 -0800

Yo Fred!

On Mon, 30 Dec 2019 20:20:14 -0800 (PST)
Fred Wright <address@hidden> wrote:

> > Care to explain what you found?  
> 
> The introduction of gnssid should have been an opportunity to clean
> up the whole PRN mess and actually report correct official PRNs (with
> "slots" playing the PRN role in the GLONASS case).

gpsd reports "correct official PRNs" as defined by NMEA 4.x

>  Instead it seems
> to be trying to report NMEA IDs as PRNs,

Whcih they are.

> and sometimes PRNs as
> "svids",

Which sometimes they are.

> which is a nonstandard and vendor-specific term.

As the comments inn gph make clear: gnssid:svid:sigid is NMEA 4.x

If you can call NMEA 4.x a standard.

But the NMEA definitions are sparse, so I went with the more general
case u-blox definitions.

If you find any particular conversion incorrect, please post it here.

> > Care to explain this too?  Maybe someone else can fix what you see?
> > Is it a release blocker?  
> 
> It's an old bug, where some computed error values only get set once
> and never changed, due to the way gpsd_error_model() and
> gps_merge_fix() interact.

If anything gps_model() runs too often, not too little.  IMHO it should only
run once before every JSON TPV or SKY output, not on every received
packet as it does now.

> I already have a fix that targets just
> epx, epy, epc, and eps, affecting 54 regression tests.  But there are
> almost certainly more values that need the same treatment.  It seemed
> better to put off that whole cleanup until after the release.

I agree, save for later.  Touching anything in gps_model() changes
gobs of stuff.

Historically gpsd defers to GNSS receiver provided values over computed
ones.  For some receivers that is a good choice, not for others.  Research
needs to be done on that.


> >> I've done the usual testing across a wide range of machines and
> >> VMs, and it looks good to go.  
> >
> > So no blockers?  Just two issues you don't care to share?  
> 
> See above.  And "good to go" meant no blockers.

Hving been accused of rushing release, I'm just being double careful.

"Measure twice, cut once."

Thanks for the patches (xgps looks better) and the tests.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  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: pgp5ehB6aiZAO.pgp
Description: OpenPGP digital signature


reply via email to

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