Fw: Skytraq / GPS Almanac
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
From: "Said Jackson" saidjack@jackson-labs.com
Sent: Tuesday, September 26, 2017 12:07 PM
Tom,
Not sure if you have heard of the recent changes to the GPS Almanac causing
issues with the Skytraq receivers. This has apparently happened around 9/20.
We have received word from Skytraq that units operating in ROM mode (3D
Mobile mode) are affected, but not units using the Position Hold/Auto Survey
Flash mode, and units that are presently running will continue to run well.
Units operating in 3D Mobile mode that are reset or power-cycled will not be
able to achieve a GPS Fix. This is a now verified bug in the Skytraq ROM
firmware.
Just to re-iterate the above: units operated in Auto Survey - Position Hold
mode are not affected at all by this.
We are working on a patch for this for users that need to run the units in
3D Mobile mode, and hope to have one in the next few days. This patch will
have to be applied here at JLT, so units will have to be returned here once
the patch is available.
In the meantime units that are powered-on and operating properly should be
left powered-on, or switched to Position Hold mode (but the switch must be
made while power is removed from the board!)
This is very unfortunate, and we are very sorry for the inconvenience this
might be causing users. Apparently this is likely affecting all ROM-operated
Skytraq receivers. Not good.
In parallel we are also trying to reach the GPSOC to determine why the
parameter switch was done, and if they can please revert back to the old
setting which apparently had been used for decades until last week.
Please let me know if you have heard additional reports or info, and please
feel free to post the above info on Time Nuts.
Bye,
Said
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
At 05:20 PM 9/26/2017, 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.
I have ublox LEA-6T data logged from 18:30 on 8-26 through 05:30 on
9-18. It includes the RXM-SFRB subframe buffer messages. Would that
be of any help, or did I shut it off too early?
--
newell N5TNL
Maybe this can be useful:
https://www.navcen.uscg.gov/pdf/gps/IDOC_IODE_Final_Response_150814.pdf
On Wed, Sep 27, 2017 at 5:58 AM, Scott Newell newell+timenuts@n5tnl.com wrote:
At 05:20 PM 9/26/2017, 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.
I have ublox LEA-6T data logged from 18:30 on 8-26 through 05:30 on 9-18. It
includes the RXM-SFRB subframe buffer messages. Would that be of any help,
or did I shut it off too early?
--
newell N5TNL
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.
I don’t have any SkyTraq navigation modules, but I power cycled a couple of my clocks (with the timing modules) and they came back up as they usually do, so I can tentatively confirm that in survey-and-hold mode they don’t appear to have any problems getting a fix. TBD is vetting the results to insure there’s no loss of accuracy, but I haven’t seen any weirdness from any of my GPSDOs at least.
Sent from my iPhone
On Sep 27, 2017, at 4:59 AM, Azelio Boriani azelio.boriani@gmail.com wrote:
Maybe this can be useful:
https://www.navcen.uscg.gov/pdf/gps/IDOC_IODE_Final_Response_150814.pdf
On Wed, Sep 27, 2017 at 5:58 AM, Scott Newell newell+timenuts@n5tnl.com wrote:
At 05:20 PM 9/26/2017, 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.
I have ublox LEA-6T data logged from 18:30 on 8-26 through 05:30 on 9-18. It
includes the RXM-SFRB subframe buffer messages. Would that be of any help,
or did I shut it off too early?
--
newell N5TNL
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.
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.
Status -- all is back to normal with GPS as of this morning. At least for now, the folks that run GPS appear to have reversed the change made last week that triggered latent bugs in some receivers. A note from Said just now:
Hi Tom,
Would you mind posting to Time nuts that this is a confirmed IODC MSB
non-zero weird-but-legal-behavior/issue, and that this seems to have been
corrected as of this morning?
Notwithstanding that it seems the GPS system has fixed the "anomaly"
this morning, we confirmed that the fix works (on live-sky signals last evening)
and are still implementing the fix here, and have received confirmation that
Skytraq also fixed it moving forward.
We have confirmed that other products in our library such as our Rockwell
Collins and uBlox receivers did not find offense at the signal. I wonder how
Trimble units faired?
Thanks,
Said
Trimble, Motorola, ublox, everyone was fine -- except for Skytraq, as far as I know.
Thanks again to Jay Grizzard for making this a quick & fun anomaly to observe. I'd like to imagine Said's quick posting to time-nuts and Jay's dramatic plots helped in some way to bring attention and resolution.
https://www.febo.com/pipermail/time-nuts/2017-September/107050.html
https://www.febo.com/pipermail/time-nuts/2017-September/107051.html
/tvb