Yo Mark!

On Wed, 1 Jun 2016 01:20:27 +0000
Mark Sims holrum@hotmail.com wrote:

Yup.  Quite common when the GPS is confused about the current leap
seconds.

Usually a GPS will download the correct offset withing 30 mins of cold
start.

RGDS
GARY

Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
gem@rellim.com  Tel:+1 541 382 8588

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@hotmail.com
To: time-nuts@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...

The local clock bias value reported by the Res T is the difference between
the receiver's clock and the reference time scale ( GPS or UTC). You need
it to correct the raw pseudo ranges reported by the receiver, which are
with respect to the receiver's clock.

Cheers
Michael

On Wednesday, 1 June 2016, Mark Sims holrum@hotmail.com wrote:

The manual states that all protocol messages are sent after the 1PPS time pulse. But it looks like the nav time message is an exception.

I dumped the default data stream (just NMEA) with u-center. The first NMEA message being a GPRMC and the last being GPGGL.
From your post I figured that you were referring to the NAV-TIMEGPS message so I configured that in. The message showed up between the last NMEA message for the second and the GPRMC at the top of the next second.

15:42:31  0000  24 47 50 52 4D 43 2C 31 35 34 32 33 31 2E 30 30  $GPRMC,154231.00
0010  2C 41 2C 34 38 34 37 2E 33 35 31 39 30 2C 4E 2C  ,A,4847.35190,N,
0020  30 30 32 31 36 2E 33 30 34 31 38 2C 45 2C 30 2E  00216.30418,E,0.
0030  30 39 30 2C 2C 30 31 30 36 31 36 2C 2C 2C 41 2A  090,,010616,,,A*
0040  37 33 0D 0A                                      73
15:42:31  0000  24 47 50 56 54 47 2C 2C 54 2C 2C 4D 2C 30 2E 30  $GPVTG,,T,,M,0.0
0010  39 30 2C 4E 2C 30 2E 31 36 36 2C 4B 2C 41 2A 32  90,N,0.166,K,A2
0020  42 0D 0A                                        B
15:42:31  0000  24 47 50 47 47 41 2C 31 35 34 32 33 31 2E 30 30  $GPGGA,154231.00
0010  2C 34 38 34 37 2E 33 35 31 39 30 2C 4E 2C 30 30  ,4847.35190,N,00
0020  32 31 36 2E 33 30 34 31 38 2C 45 2C 31 2C 30 39  216.30418,E,1,09
0030  2C 30 2E 39 31 2C 31 38 39 2E 33 2C 4D 2C 34 36  ,0.91,189.3,M,46
0040  2E 32 2C 4D 2C 2C 2A 35 34 0D 0A                .2,M,,54
15:42:31  0000  24 47 50 47 53 41 2C 41 2C 33 2C 32 36 2C 32 31  $GPGSA,A,3,26,21
0010  2C 30 35 2C 32 37 2C 31 36 2C 32 39 2C 32 35 2C  ,05,27,16,29,25,
0020  33 31 2C 32 30 2C 2C 2C 2C 31 2E 36 34 2C 30 2E  31,20,,,,1.64,0.
0030  39 31 2C 31 2E 33 36 2A 30 31 0D 0A              91,1.3601
15:42:31  0000  24 47 50 47 53 56 2C 34 2C 31 2C 31 33 2C 30 34  $GPGSV,4,1,13,04
0010  2C 38 35 2C 32 39 39 2C 33 33 2C 30 35 2C 31 35  ,85,299,33,05,15
0020  2C 30 34 36 2C 33 38 2C 30 39 2C 30 34 2C 33 32  ,046,38,09,04,32
0030  39 2C 2C 31 36 2C 33 35 2C 33 30 32 2C 33 37 2A  9,,16,35,302,37
0040  37 43 0D 0A                                      7C
15:42:31  0000  24 47 50 47 53 56 2C 34 2C 32 2C 31 33 2C 31 38  $GPGSV,4,2,13,18
0010  2C 30 36 2C 31 34 35 2C 31 34 2C 32 30 2C 32 33  ,06,145,14,20,23
0020  2C 30 39 33 2C 31 37 2C 32 31 2C 36 33 2C 31 35  ,093,17,21,63,15
0030  34 2C 32 30 2C 32 33 2C 30 34 2C 33 30 33 2C 2A  4,20,23,04,303,*
0040  37 39 0D 0A                                      79
15:42:31  0000  24 47 50 47 53 56 2C 34 2C 33 2C 31 33 2C 32 35  $GPGSV,4,3,13,25
0010  2C 31 35 2C 31 32 34 2C 31 35 2C 32 36 2C 36 36  ,15,124,15,26,66
0020  2C 32 39 37 2C 34 34 2C 32 37 2C 31 32 2C 32 35  ,297,44,27,12,25
0030  38 2C 31 34 2C 32 39 2C 33 37 2C 30 36 37 2C 33  8,14,29,37,067,3
0040  39 2A 37 43 0D 0A                                97C
15:42:31  0000  24 47 50 47 53 56 2C 34 2C 34 2C 31 33 2C 33 31  $GPGSV,4,4,13,31
0010  2C 33 39 2C 32 30 38 2C 32 30 2A 34 42 0D 0A    ,39,208,204B
15:42:31  0000  24 47 50 47 4C 4C 2C 34 38 34 37 2E 33 35 31 39  $GPGLL,4847.3519
0010  30 2C 4E 2C 30 30 32 31 36 2E 33 30 34 31 38 2C  0,N,00216.30418,
0020  45 2C 31 35 34 32 33 31 2E 30 30 2C 41 2C 41 2A  E,154231.00,A,A*
0030  36 33 0D 0A                                      63

Now the NAV-TIMEGPS ublox binary message

15:42:31 0000  B5 62 01 20 10 00 A8 40 D2 12 5A FD 01 00 6B 07
0010  11 07 19 00 00 00 F8 D1

This decodes:  integers are little endian
Header B5 62
ID 01 20
Length 10 00 16bit  (16)
iTOW A8 40 D2 12 GPS TOW milliseconds  (315769000)
fTOW 5A FD 01 00 Fractional nanoseconds remainder of rounded ms
above range -500000-500000
week 6B 07 GPS week (GPS Time) cycle 1 week 875  (875 is 0x036B)?
leapS 11 leap seconds (17)
flags 07 utc,week,tow bits set
tAcc 19 00 00 00
CK_A F8
CK_B D1

Converting iTOW = wed 15h 42m 49s : the time of the next second
plus the leap value???
Are my sums wrong? GPS time is not supposed to have leap seconds included.

15:42:32  0000  24 47 50 52 4D 43 2C 31 35 34 32 33 32 2E 30 30  $GPRMC,154232.00
0010  2C 41 2C 34 38 34 37 2E 33 35 31 39 35 2C 4E 2C  ,A,4847.35195,N,
0020  30 30 32 31 36 2E 33 30 34 32 30 2C 45 2C 30 2E  00216.30420,E,0.
0030  30 35 37 2C 2C 30 31 30 36 31 36 2C 2C 2C 41 2A  057,,010616,,,A*
0040  37 35 0D 0A

So it looks like ublox are not keeping to their protocol standard.

Despite re-checking I am still doubtful that my sums are right. I’ll do a few more packets.
Is this what you are seeing Mark?

Regards,
Mike

"The power of accurate observation is commonly called cynicism by those who have not got it. »
George Bernard Shaw