[time-nuts] GPS jumps of -13.7 us?

Martin Burnicki martin.burnicki at burnicki.net
Wed Jan 27 16:49:52 UTC 2016


Magnus Danielson wrote:
> Hi,
> 
> On 01/26/2016 11:46 PM, Martin Burnicki wrote:
>> Paul Boven wrote:
>>> Hi everyone,
>>>
>>> Has anyone else seen GPS time jump by -13.7 usec today?
>>> I just heard from several geographically quite distributed radio
>>> observatories that they have seen their GPS receiver(s) jump compared to
>>> their in-house standards.
>>
>> We were able to track this down today at Meinberg.
>>
>> The problem was that some satellites were sending invalid UTC correction
>> parameters. The UTC correction parameter set not only contains current
>> leap second information but also coefficients (A0, A1, WNt, tot) for a
>> polynomial used to compensate the fractional difference between GPS time
>> and UTC(USNO).
>>
>> Normally A0 (the constant offset) is very small, close to 0. WNt and tot
>> give the week number (truncated to 8 bits) and second-of-week for which
>> A0 is valid, i.e. the reference time for the time correction parameters.
>> WNt is currently about 89.
>>
>> Today the faulty satellites sent about 13.7 microseconds for A0, and WNt
>> as well as tot were both 0. So when the GPS receiver updated its UTC
>> correction parameters from a faulty satellite the UTC correction jumped
>> from close to 0 to about 13.7 microseconds, which let the UTC time step,
>> and when the GPS receiver received the UTC parameter set from a healthy
>> satellite the UTC time stepped back.
>>
>> We have recorded a few of the faulty subframe words. If someone is
>> interested I can provide more detailed information. However, I'm
>> currently out of the office and don't have the information here right
>> now.
> 
> You know I want more details. ;-)
> 
> I did see the report you guys sent to the USCG, good work there and good
> report.

Thanks.

After we had received the first reports about GPS receiver showing a 13
us time offset one of my colleagues who maintains the firmware of our
GPS receivers started to investigate. Looking at the data sets decoded
from the satellites he saw that temporarily the UTC correction parameter
jumped from one or 2 nanoseconds to more than 13 microseconds.

So he added some debug code which let the GPS receiver sent the
satellite number plus the raw subframe words 7 and 8 as hex numbers to a
monitor program which logged them to a file.

Then we looked at the raw data, decoded the bits manually and found that
some satellites were suspicious UTC correction data with a valid checksum.

Here are some subframe words 7 and 8 captured starting around 2016-01-26
12:00 UTC from subframe 4 page 18, and the decoded parameters
according to Figure 20-1, sheet 8 of IS-GPS-200H (printed page 83, PDF
page 96)
http://www.gps.gov/technical/icwg/IS-GPS-200H.pdf

sv    sfw7       sfw8        wnt|tot      a0 bits    a0[us]
09 0x3FFFF1B3 0x23800017 --> 00|000000: 0xFFFFC68E  -13.696 *
07 0x3FFFFFEA 0x3FD3967B --> 89|319488: 0xFFFFFFFF   -0.001
02 0x3FFFFFD5 0x3FD39644 --> 89|319488: 0xFFFFFFFF   -0.001
06 0x3FFFF18C 0x23800028 --> 00|000000: 0xFFFFC68E  -13.696 *
23 0x3FFFF18C 0x23800028 --> 00|000000: 0xFFFFC68E  -13.696 *
30 0x00000000 0x00139664 --> 89|319488: 0x00000000   +0.000
05 0x0000003F 0x0013965B --> 89|319488: 0x00000000   +0.000
16 0x00000000 0x00139664 --> 89|319488: 0x00000000   +0.000
26 0x3FFFF18C 0x23800028 --> 00|000000: 0xFFFFC68E  -13.696 *
07 0x3FFFFFEA 0x3FD3967B --> 89|319488: 0xFFFFFFFF   -0.001
09 0x3FFFF1B3 0x23800017 --> 00|000000: 0xFFFFC68E  -13.696 *
02 0x3FFFFFD5 0x3FD39644 --> 89|319488: 0xFFFFFFFF   -0.001
30 0x00000000 0x00139664 --> 89|319488: 0x00000000   +0.000
05 0x0000003F 0x0013965B --> 89|319488: 0x00000000   +0.000
06 0x0000003F 0x0098D67D --> 89|405504: 0x00000002   +0.002
23 0x3FFFF18C 0x23800028 --> 00|000000: 0xFFFFC68E  -13.696 *
16 0x00000000 0x00139664 --> 89|319488: 0x00000000   +0.000
07 0x3FFFFFEA 0x3FD3967B --> 89|319488: 0xFFFFFFFF   -0.001
09 0x00000000 0x0098D642 --> 89|405504: 0x00000002   +0.002
30 0x00000000 0x00139664 --> 89|319488: 0x00000000   +0.000
02 0x3FFFFFD5 0x3FD39644 --> 89|319488: 0xFFFFFFFF   -0.001
05 0x0000003F 0x0013965B --> 89|319488: 0x00000000   +0.000
23 0x3FFFF18C 0x23800028 --> 00|000000: 0xFFFFC68E  -13.696 *
06 0x0000003F 0x0098D67D --> 89|405504: 0x00000002   +0.002
16 0x00000000 0x00139664 --> 89|319488: 0x00000000   +0.000
07 0x3FFFFFEA 0x3FD3967B --> 89|319488: 0xFFFFFFFF   -0.001
09 0x0000003F 0x0098D67D --> 89|405504: 0x00000002   +0.002
30 0x00000000 0x00139664 --> 89|319488: 0x00000000   +0.000
05 0x0000003F 0x0013965B --> 89|319488: 0x00000000   +0.000
02 0x0000003F 0x0098D67D --> 89|405504: 0x00000002   +0.002
06 0x0000003F 0x0098D67D --> 89|405504: 0x00000002   +0.002
23 0x0000003F 0x0098D67D --> 89|405504: 0x00000002   +0.002
16 0x00000000 0x00139664 --> 89|319488: 0x00000000   +0.000

You see that SVs 09, 06, 23, and 26 sent a tot time 0 and a correction
parameter A0 of -13.696 microseconds, while the A0 parameter received
from healthy satellites was only 1 or 2 nanoseconds, as usual, and the
week number wnt matches the current week number, truncated to 8 bit.

Eventually there were even more satellites sending faulty data, but
these were the ones we could track at our location.

You can also see that in the last lines the A0 value sent by SVs 6, 9,
and 23 was "normal" again, so we happily just captured a few of the last
wrong data sets.

All data captured after this was OK again. Please find the full set of
debug output in the attached text file.

Unfortunately there was no time stamp in the debug output, but we know
the satellites repeat the same page 4 once every 12 minutes.

Martin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2016-01-27-gps-subframe-4-page-18-prn-word7-word8.log
Type: text/x-log
Size: 52709 bytes
Desc: not available
URL: <http://febo.com/pipermail/time-nuts_lists.febo.com/attachments/20160127/5532bb33/attachment.bin>


More information about the Time-nuts_lists.febo.com mailing list