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
_______________________________________________
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
