[time-nuts] Ublox Neo-6M time error.

[Tom Van Baak]

Hi Mark,

What does u-center report for the NEO-6M? Or how about TAC32?

Check the precise alignment of the 1PPS and the NMEA/binary/SCPI message stream.

Since the messages cannot coincide with the 1PPS, firmware has two choices: the message can describe the time of the previous 1PPS or the time of the next 1PPS. Vendors differ. Depending on your software or how you receive the 1PPS or how you interpret the packets, there are possibilities for off-by-one second errors due to this.

The same issue occurs with sawtooth correction: is the correction for the 1PPS that just occurred a fraction of a second ago, or the correction for the 1PPS that will occur in a fraction of a second from now? Vendors differ.

The good news is that vendors all agree on NMEA: it's the time of the current second, not the next second. But the bad news is that this makes it impossible to handle UTC leap seconds with standard NMEA. By the time you find out there was a leap second it's too late. At least one vendor has a custom leap second pending NMEA message to work-around this.

/tvb

----- Original Message ----- 
From: "Mark Sims" <holrum at hotmail.com>
To: <time-nuts at febo.com>
Sent: Tuesday, May 31, 2016 6:20 PM
Subject: [time-nuts] Ublox Neo-6M time error.


I had two machines running Lady Heather with the singing chime clock mode enabled (that plays a chant from the Missa Assumpta on the quarter hours).   

One machine was connected to a Ublox Neo-6M receiver and another to a Z3801A.   I noticed that the two machines sang their jaunty monk tunes offset by around one second.  Since a man with two singing GPS clocks never knows what time it is,  I replaced the Z3801A with a Jupiter-T and the two clocks were still out of sync.   Finally I tried  Motorola M12+ and UT receivers and the same thing happened.  It looks like the Ublox time is ahead by a second compared to all the other receivers.   I then specified a -1 second "rollover" correction to the Ublox machine and the two clocks sang in perfect harmony.   Has anybody noticed such behavior with other receivers?

BTW,  note that the Ublox binary time message has a "fractional nanoseconds of the seconds field" (+/- 500,000 nanoseconds) correction that must be applied to the hrs:min:secs values (which I am doing).  The fractional time offset forms a sawtooth with around a 120 second period.  Attached is a GIF... white is the nanosecond fractional time offset.  Magenta is the receiver estimate of its time error (both in nanoseconds).  The Trimble Resolution-T receivers report a similar "local clock bias" value, but they don't seem to document what it actually is...



     


--------------------------------------------------------------------------------


> _______________________________________________
> 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.