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