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

Martin Burnicki martin.burnicki at burnicki.net
Thu Jan 28 03:30:13 EST 2016


brian wrote:
> This may be a dumb question, but I am new to using LadyHeather with my
> Thunderbolt (previously it had been slaved to driving a clock display
> but that broke, which made me get around to installing a serial card in
> my linux box)...
> 
> Are these "events" something I should be able to see in LH?  If so what
> should I be looking for?     I see a pair of off-setting events in the
> graphs (a sharp negative spike in DAC Voltage & PPS, followed later by
> a sharp positive spike of the same magnitude),  but not sure if I am
> seeing what I want to see, of if this is actually what I am looking
> for.

It depends on what you mean by "events".

The problem should not affect normal GPS time, so navigation should not
have been affected since only the conversion from GPS time to UTC was
messed up.

If you use the PPS output which normally corresponds to the changeover
of the UTC second then the PPS slope should have stepped by 13.7 us or
not, depending on if and when the GPS receiver accepted the faulty UTC
correction data set from on of the satellites which broadcast it.

If you use the 1 PPS signal to discipline an oscillator thenit depends
on how the oscillator control loop deals with such time step, whether it
silently follows the step, or if it generates some kind of alarm due to
this unusual step.

In this case the problem was visible when you looked at the current UTC
correction parameters decoded from the satellites' nav messages.

For example, using a Meinberg GPS180PEX card with its Linux driver you
can see the following status:

martin at pc-martin:~> mbgstatus -vvv /dev/mbgclock0

mbgstatus v3.4.99 copyright Meinberg 2001-2015

GPS180PEX 029511026220 (FW 2.04, ASIC 8.06) at port 0xE000, irq 16
Normal Operation, 9 sats in view, 9 sats used
Osc type: TCXO, DAC cal: -550, fine: +666
Date/time:  Th, 2016-01-28 08:19:53.05 UTC, st: 0x14
Local HR time:  2016-01-28 08:19:53.0548183 UTC, st: 0x0014
Status info: Input signal available
Status info: Time is synchronized
Status info: Receiver position has been verified
Last sync:  Th, 2016-01-28 08:19:00.00 UTC, st: 0x14
Receiver Position:
  x: 3885686m y: 631143m z: 5001726m
  lat: +51.9824 lon: +9.2258 alt: 167m
  latitude:  N  51 deg 58 min 56.47 sec
  longitude: E   9 deg 13 min 33.05 sec
CSUM: 1615, valid: 0001
t0t: 1881|503808.0000000, A0: -9.31323e-10 A1: 3.55271e-15
WNlsf: 1851, DN: 3, offs: 17/17
UTC offset parameter: 17s, no leap second announced.

where the line starting with "t0t" prints the UTC correction data which
was faulty in this case.

While the problem occurred I ran this command periodically and grepped
the t0t line only, so at the "recovery" time you cold see this:

t0t: 1792|0.0000000, A0: -1.3696e-05 A1: 1.24345e-14
t0t: 1792|0.0000000, A0: -1.3696e-05 A1: 1.24345e-14
t0t: 1792|0.0000000, A0: -1.3696e-05 A1: 1.24345e-14
t0t: 1792|0.0000000, A0: -1.3696e-05 A1: 1.24345e-14
t0t: 1881|319488.0000000, A0: 0 A1: 1.24345e-14
t0t: 1881|319488.0000000, A0: 0 A1: 1.24345e-14
t0t: 1881|319488.0000000, A0: 0 A1: 1.24345e-14
t0t: 1881|319488.0000000, A0: 0 A1: 1.24345e-14
t0t: 1881|319488.0000000, A0: 0 A1: 1.24345e-14

Please note the week number here is the fully expanded week number:

1792 == 0x700, i.e. the 8 bit truncated value is 0, which is wrong
1881 == 0x759, i.e. the 8 bit truncated value is 0x59 == 89 correctly

Unfortunately I don't know if the thunderbold can output this kind of
data, and if LH can display it. I've not played with those, yet.

Martin




More information about the time-nuts mailing list