[time-nuts] Fw: Skytraq / GPS Almanac

[J. Grizzard]

Sooooo.... Tom and I were batting this one around for a while, and think 
we mostly know what the proximal cause of the reported problems are, 
even if we don't know the specific code bug that causes the Skytraq 
failure. I have a database of recent (last year) broadcast parameters 
that made it pretty easy to spot what was going on.

Short version: The IODC ("Issue of Data, Clock") broadcast parameter is 
a 10-bit value (the lower 8 bits of which match up with the associated 
IODE ("Issue of Data, Ephemeris") value). Until recently, the IODC value 
has only contained 8-bit values, with a couple of brief minor exceptions 
(getting up to 263 for a few individual PRNs for a single almanac 
version). Starting on 2017-09-22 (at roughly 11:30UTC, give or take half 
an hour), this value began regularly (exclusively, actually) having 
values that are no longer expressible as 8-bit values. This, we are 
guessing, has triggered some latent bug in the Skytraq firmware.

I tossed up a quick graph of IODC values for each PRN for the past year 
at https://gf.lupine.org/dashboard/db/gps-temp-iodc-by-prn (pardon the 
missing data from 9/8 to 9/18, please). You can see that the values stay 
below 255 right up until the 22nd, at which point the values cross that 
threshold and just keep going up. (You can zoom out or use the arrows to 
move back in time to see that this is truly a unique event, at least as 
far back as I have data.)

Values up to 1023 are completely legitimate, but since we haven't really 
seen many over 255 (and never across the entire constellation), some 
latent bug could have easily been sitting around unknown for all these 
years.

IS-GPS-200H (20.3.4.4) specifies:

    The IODE is an 8 bit number equal to the 8 LSBs of the 10 bit IODC
    of the same data set. [...] The range of IODC will be as given in
    Table 20-XI for Block II/IIA SVs and Table 20-XII for Block
    IIR/IIR-M/IIF and GPS III SVs.

...and table 20-XI specifies:

    IODC values for blocks with 2- or 4-hour transmission intervals (at
    least the first 14 days after upload) /(these are the normal almanac
    uploads used -j)/ shall be any numbers in the range 0 to 1023
    excluding those values of IODC that correspond to IODE values in the
    range 240-255, subject to the constraints on re-transmission given
    in paragraph 20.3.4.4

...so it's possible that there's some bug in the firmware where they're 
doing "if IODE == IODC" rather than "if IODE == (IODC&0xff)", which 
would give the correct result for 99.9% of past almanacs, but not any 
more. Or it's possible they're stuffing IODC into an 8-bit variable and 
getting seemingly-repeat values out of it or something. I dunno the 
exact bug, but it seems pretty obvious that's where it is.

Always interesting when a completely valid value -- but different from 
the norm -- can uncover odd bugs like this.

(...this little adventure has also reminded Tom and I that one of us 
really needs to get around to our respective projects to record the raw 
GPS datastream full-time. I really need to build myself a little carrier 
for the still-sealed ublox chips I have so I can work on grabbing the 
raw frames from that... sigh. Too many projects, not enough time [sic])

-j

On 9/26/17 3:20 PM, Tom Van Baak wrote:
> An interesting note from Said, below...
> I've sent a couple of queries out to GPS professionals.
> Feel free to comment if you have concrete information that would help.
> Also, if during the past week any of you were logging almanacs or continuously recording the 50 bps raw data from any GPS/SV, please let me know.
>
> Thanks,
> /tvb
>