Re: ✘ Release blockers?

[Gary E. Miller]

Yo Fred!

On Thu, 26 Dec 2019 17:50:19 -0800 (PST)
Fred Wright <address@hidden> wrote:

> On Thu, 26 Dec 2019, Gary E. Miller wrote:
> >
> > On Thu, 26 Dec 2019 15:26:52 -0800 (PST)
> > Fred Wright <address@hidden> wrote:
> >  
> >> It looks like the PRN and svid are swapped for SBAS satellites.  
> >
> > That is very driver dependent.  What driver?  What do you see?
> > What do you expect to see?  
> 
> This is specifically with the ublox driver, but it looks like all the 
> drivers are doing something similar.

Yup, similar, but different.

> In particular, they're making
> the svid *larger* than the PRN by 87, which is clearly backwards.

Where?  Please be specific.  The PRN and svid handling varies wildly
depending on many things.

> > What NMEA 0183 calls the PRN is not what IS-GPS-200J calls the PRN.
> >
> > And the NMEA varies wildly by vendor.
> >
> > Outside of the GPS system, there is no standard for what a PRN
> > means.  
> 
> PRNs are standardized for SBAS.

It may be "standardized", but if you look on the gpsd regressions you
will see implementations vary wildly.

> NMEA started by using PRNs verbatim
> for GPS (non-SBAS), but then kludged in extra cases in weird ways.

Yup. "kludged in extra cases in weird ways."

And then the vendors did not read the "standard".

> > IS-GPS-200J and NMEA 0183 are the controlling documents.  SBAS PRN
> > are in the range 120-158.  But by IS-GPS-200J its svid's are 33...
> >
> > NMEA 0183, as implemented, is all over the place on what a PRN is.
> > You need to refer to your GNSS receiver doc to know.  Sometimes
> > WAAS PRN in NMEA is 120, sometimes 33.  
> 
> See IS-GPS-200J (or IS-GPS-200K, if you want to be more current),
> section 6.3.6.1, paragraph 2:
> 
>       PRN numbers 120 through 158 are reserved for SBAS;

Yes, that is what I said, and you quoted me, just above here.

> This is consistent with the following:

But inconsistent with many of the gpsd regressions, and other doc.

gpsd tries to follow standards, but ultimately when the receivers do
weird things it tries to compensate.

> I.e., *everyone* agrees that SBAS PRNs are in the 120-158 range, and 
> anything reporting otherwise is broken.  Pseudo-PRNs reported by NMEA 
> don't count.

Well, then what counts?  I say the data in the regressions counts most.

Can you point to a gpsd regression that is not doing what you think it
should be doing?

> > For example:
> >
> > A $GPGSV uses PRN 65 for the first GLONASS sat, but $GLGSV uses
> > PRN 1 for the first GLONASS sat.  
> 
> Yes, because GPGSV uses the original global pseudo-PRN numbering
> system, while GLGSV uses system-relative numbering (as does GNGSV).

Yes, as I previsouly explained.  You just used a new term "system
relative numbering" for the svid.  Same thing.

> > Also, look at the gpsd doc on the subject:
> >
> >    https://gpsd.io/NMEA.html#_satellite_ids
> >
> > It can use an update.  
> 
> The PRNs in the first table are plausible, in agreement with what
> I've posted, and not in agreement with the code.

Yes, it is out of date, the code, and comments in the code, are
correct.

>  But in the second
> table, using 33-64 for SBAS is broken (not that that means it doesn't
> happen),

We gotta define the term "broken".  If by "broken, you mean does not
conform to some "standards", then I agree.  If by "broken" you mean that
it does not handle real life cases as seen in the gpsd regressions, then
I disagree.

> since actual GPS NAV staellites are starting to use real
> PRNs in that range. And the split between 120-151 and 151-158 doesn't
> make sense.

Long ago I realized that trying to make sense of the mistakes vendors
made about the multiple competing standards was a waste of time.

I just go by the regression tests, and compariing betwen different
vendor GNSS receivers.

> >> It looks like the relevant code appears in multiple places, and
> >> even the magic number 87 isn't parameterized:  
> >
> > Yes, because different drivers use different translations.  
> 
> Except that it's actually the same offset being used in multiple
> places, as a magic hard-coded constant.

Well, it is a magic hard coded constant.  Just like Pi, earth diameters,
etc.  One of many needed by the drivers to do the large number of sat
number translations.

> >> I didn't want to fix it without finding out if there are further
> >> ramifications.  
> >
> > Good.  Don't fix what ain't broke.  before you touch it, make sure
> > any patch also handle GLONASS, GALILEO, BeiDou, IMES, etc.  
> 
> I'm talking specifically about SBAS here, which generally seems to be 
> handled by SBAS-specific code.

As I said, look at the code.  You can not handle just one case without
looking at all the other cases.

> > Check out the u-blox 9 doc for an idea of the complexity.
> >
> > PRN is a wasteland.  gnssid:svid:sigid is where the world, including
> > NMEA is moving to.  
> 
> PRNs are very well-defined and unique for GPS and SBAS.

Yes, and defined in several incompatible ways.  Look in the gpsd
regressions, it is all there plain to see.

> For other 
> systems, they generally conceptually exist, but not necessarily in a 
> nonoverlapping range, and almost certainly not with the same mapping
> to the actual PRN sequences.

Yes, a mess.

> Reporting something as a "PRN" which doesn't match official
> specifications is clearly wrong, and for that matter, reporting
> numbers >120 as alleged "svids" is almost certainly wrong as well.

IS-GPS-200K does not specify anything called an "svid".  So there can
not possibly be any conflict.

Rather than goind around and around, changing the meaning of words, how
about you show any problem that you think exists in one of the gpsd
regressions.  Talking around a problem does not illuminate it, data
does.

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

pgpMwdxGa6CHG.pgp
Description: OpenPGP digital signature