[time-nuts] TU30 jump second
bg at lysator.liu.se
Tue Apr 4 12:56:53 EDT 2017
Hi Bob & Bo,
This was discussed a long time ago on
which is defunced since many years. To measure the delay I suggest setting it up as a NMEA refclock to ntpd. But fudge it so that it is only collecting data to watch and log the offsets. IIRC delays for the receiver I had was 1013ms or 2013ms in NMEA-mode.
1024 wk issues are not related to this. And as discussed many times in the archives. Rx firmware programmers often checked dates to see if they were older than say the firmware release date. If so they added 1024wk. Thus the magic rollover-dates are often not the actual problem dates.
Sent from my smartphone.
-------- Original message --------From: Bob kb8tq <kb8tq at n1k.org> Date: 04/04/2017 17:47 (GMT+01:00) To: timenuts at rudius.net, Discussion of precise time and frequency measurement <time-nuts at febo.com> Subject: Re: [time-nuts] TU30 jump second
> 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 ….
> Indeed the TU30 is a old device. I guess some 30 years if not more looking at the components. F/W I have no idea.
> The 10 kHz seems unaffected.
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
More information about the time-nuts