Re: Re: ✘ Release blockers?

[Fred Wright]

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.  In particular, they're making the 
svid *larger* than the PRN by 87, which is clearly backwards.

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

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

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;

This is consistent with the following:

https://en.wikipedia.org/wiki/Wide_Area_Augmentation_System
https://www.gpsworld.com/the-almanac/#SBAS
https://media.defense.gov/2016/Jul/22/2001580805/-1/-1/1/L1%20C-A%206%20JAN%2016.PDF
https://www.icao.int/airnavigation/Documents/NSP5_Report%20on%20Agenda%20Item%202.APPENDIX%20A2%20-%20DFMC%20SBAS%20SARPS%20Part%20B.pdf
http://mgex.igs.org/IGS_MGEX_Status_SBAS.php

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.

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

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

The PRNs in the first table are plausible, in agreement with what I've 
posted, and not in agreement with the code.  But in the second table, 
using 33-64 for SBAS is broken (not that that means it doesn't happen), 
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.

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

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

I'm talking specifically about SBAS here, which generally seems to be 
handled by SBAS-specific code.

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

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.

On Thu, 26 Dec 2019, Hal Murray wrote:
> address@hidden said:
> > > That's the loop writing stuff that I encountered a few days ago.
> > If this is reproducible, it would be good to determine:
> > A) Is this a daemon bug or just a test bug?
> > B) Is it a new bug since 3.19?
>
> It depends on what "this" or "it" binds to.
>
> There is nothing new about NetBSD and FreeBSD needing WRITE_PAD.  I don't know
> where the bug is.
>
> This is the first time that I've noticed the loop writing to disk.  But that
> doesn't say that the older versions did or didn't do the same thing.

I'm referring specifically to the infinite loop ("the loop writing 
stuff"), not miscellaneous test flakiness.

Fred Wright