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

Hi > On Apr 4, 2017, at 10:01 AM, Bo Hansen <timenuts@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 …. Bob > > 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. > > Bo > > _______________________________________________ > time-nuts mailing list -- time-nuts@febo.com > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there.

Hi, On 04/04/2017 05:47 PM, Bob kb8tq wrote: > Hi > > >> On Apr 4, 2017, at 10:01 AM, Bo Hansen <timenuts@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