[time-nuts] TU30 jump second

[Magnus Danielson]

Hi,

On 04/04/2017 05:47 PM, Bob kb8tq wrote:
> Hi
>
>
>> On Apr 4, 2017, at 10:01 AM, Bo Hansen <timenuts at rudius.net> wrote:
>>
>> Hi all
>>
>> The data can be a bit hard to read in an email. So I will give it another try.
>>
>> PC-time | Diff. | GPS-time | Diff.
>> ...
>> 011606.005 | 0.992 | 011604 |1
>> 011607.013 | 1.008 | 011605 |1
>> 011608.005 | 0.992 | 011607 |2 <--- The issue
>> 011609.013 | 1.008 | 011608 |1
>> 011610.004 | 0.991 | 011609 |1
>> ...
>>
>> I used a terminal program to log the NMEA data to a file and do the PC timestamp. Calculations were done in a spreadsheet by me. The PC-time is kept under control by Meinberg and also OK vs. <http://www.time.is> during the time of observation.
>>
>> The PC-timestamp wobble is not the issue. It is a combination of the PC-time itself and the NMEA wobble. Nobody should expect the NMEA data to come at the same time every time relative to the 1 PPS. As Björn correctly points out it is always late and wobbles with processor load.
>>
>> Sometimes the 2-something lag can last for many hours - I have seen more than 48 h.
>>
>> The issue is the "seconds jump". The issue is not the relative difference between the PC-time and the GPS-time but the jump, e.g. using Tac32 reveals that the TU30 is always ~1200 ms late on in case of the "jump second" ~2300 ms late.
>>
>> I wonder if it has anything to do with the Week 1024 Syndrome?
>
> We are roughly 2 years away from the next week 1023 to week 0 GPS rollover point. If you see this multiple times in a 20 year period
> it is not a 1024 week issue ….

The 1024 week issue exist in several shifted variants. A single receiver 
with a particular firmware would only experience one of them thought, 
typically. It would manifest itself as 1024 weeks offset in date, but 
everything else would work, it's just that the display date would get 
offset.

Bob, there is a report somewhere that explains it. :)

The second error you have there has likely some other source. Processing 
scheduling could get wrong for instance. There is a few things to be 
careful about to get a good solid result. It is not surprising if this 
was not rock solid for all implementations back in the days.

Cheers,
Magnus