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

Magnus Danielson magnus at rubidium.dyndns.org
Wed Jan 27 19:00:58 EST 2016


Hi Martin,

On 01/27/2016 05:49 PM, Martin Burnicki wrote:
> Magnus Danielson wrote:
>> Hi,
>>
>> 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.

Several GPS receivers have support to output the raw data, and this is 
one very good reason. Being able to pull the interpreted data, the 
covariance matrix etc. and other state like raw pseudo-ranges and 
doppler data all helps. Being able to output RINEX is always very nice 
for many reasons. If I only had the time...

> 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

It's interesting to see how consistent these errors are.
On the other hand, it is interesting to see how it varies even for the 
same PRN. Look at how PRN 09 varies between +0.002 us and -13.696 us.

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

Many thanks for that wealth of data.

Cheers,
Magnus



More information about the time-nuts mailing list