Re: ✘ Release blockers?

[Gary E. Miller]

Yo Fred!

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?

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.
The NMEA numbers vary all over the place

So gpsd taks PRN to be whatever the GNSS receiver (and its driver) says
it is.  Then the driver converts that to gnssid:svid:sigid which
are somewhat standardized.

> They 
> ought to match this:
> 
>       https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System

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.

For example:

A $GPGSV uses PRN 65 for the first GLONASS sat, but $GLGSV uses
PRN 1 for the first GLONASS sat.

And it gets worse, NMEA is all over the place on what a PRN is.

Also, look at the gpsd doc on the subject:

    https://gpsd.io/NMEA.html#_satellite_ids

It can use an update.

> It's also not clear that it's correct to regard the NMEA numbers as 
> "svids"

Depending on the NMEA message, and receiver firmware, it may, or may
not, be correct to map the NMEA PRN to an svid.  All NMEA PRNs for GPS
(not WAAS) are identical to their svid.  The rest are a mess, and
vary by NMEA version, firmware version, and even differ from one 
NMEA message type to another.

Each constellation (GPS, GLONASS, GALILEO, BeiDou) numbers their sats
(svid) from 1. svid is only in the context of the gnssid.

> when that term usually has a different meaning, but we should
> at least get the PRNs right.

The advantage of standards is their are so many to pick from.

> 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.

> MacPro:gpsd fw$ grep -nw ' 87' *.c
> driver_garmin.c:579:          session->gpsdata.skyview[j].svid
> = (short)sats->svid + 87; driver_nmea0183.c:1179:
> *ubx_svid = 87 + nmea_satnum; driver_nmea0183.c:1279:
> *ubx_svid = 87 + nmea_satnum; driver_superstar2.c:197:
> porn = (unsigned int)(getub(buf, off + 3) >> 1) + 87;
> driver_tsip.c:76:            *svid = prn + 87; driver_tsip.c:88:
>       *svid = prn + 87; driver_ubx.c:126:            nmea_PRN = svId
> - 87; monitor_superstar2.c:50:            porn = ((unsigned
> char)getub(buf, off + 3) >> 1) + 87;

Which misses the complexity of what is going on.  I suggest you look at
that code more closely.
> 
> 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.

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.

> Also, running the 3.19 cgps against the latest daemon hangs without 
> acquiring any data.

Of course.  gpsd has NEVER had cross-version compatibility.  Maybe
someday.

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

pgpgNld8E9GlW.pgp
Description: OpenPGP digital signature