Hi, 
Guest
Pic
Sign In

time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

GPS receiver time message offsets to 1PPS (updated)

MS
Mark Sims
Thu, Jul 28, 2016 2:13 AM

I found what was causing the apparent ramps in the message offset time for the Motorola mode receivers and the Z38xx receivers.  Here is the updated and corrected info.  Note that a couple of receivers do have some minor ramp sawtooths in their message timing.  They are less than +/- 10 msecs from nominal.

Here are the results of measuring the difference between the time code in a GPS receiver time message and the arrival time of the last byte of the message.  Negative values mean that the receiver sends the timing message after the 1PPS pulse that it describes. The table also shows the standard deviation of the message arrival times.

The test configuration was a Compaq N610C laptop (2 GHz Pentium, hardware serial port) running Linux Ubuntu Mate 15.10).  The time of the messagearrival was from the system clock synced to NTP.  The receivers were tested in native binary protocol and, if supported, NMEA.  The com port was runningat the default value for the receiver.  If not specified that was 9600:8:N:1Data was collected after the receiver had been tracking satellites for at least 1 hour and averaged over 4 hours.  The timings were also checked andagree with those on a Raspberry PI 3 and a quad-core 3 GHz box.

Although measuring the arrival time of the first byte of the timing messagemakes more technical sense (less variation due to timing message length and baud rate) these measurements are of the last byte of the message.  This was chosen to assist people trying to sync a clock to a GPS receiver without relying on the 1PPS pulse.  They are also useful to people that want to knowhow long they have to process a timing message (like to set a sawtooth compensation delay line) before the next 1PPS pulse comes out.

A few receivers appear to not fully sync their timing message to some referenceclock.  This causes the timing message arrival time to follow a ramp curve.The ramp size is fairly small (+/- 5 to 10 msecs) in most receivers.

Device        Protocol      Firmware      (msg-arrival)  sdev
(msecs)
=============  ============  ================  ========    =====
Thunderbolt    TSIP        App:3.0 GPS:10.2    -52.9      6.2  (gold box)
Thunderbolt    TSIP        App:2.22 GPS:10.2    -67.2    10.2  (red box)
Resolution-T    TSIP        GPS:1.26            -140.0      5.4
Res-T SMT      TSIP        GPS 2.7            -475.0    63.7
Starloc II      TSIP        App:1.10 GPS:1.2    -267.5      7.2
Trimble NTWx?  TSIP        GPS 10.4            -44.9      1.2
Nortel NTPx    TSIP        GPS 10.1            -61.8      1.4
Nortel NTGx    TSIP        GPS 10.5            -57.2      2.4

Ublox LEA-6T    binary        6.02 (36023)      -242.7      4.4
Ublox LEA-6T    NMEA          6.02 (36023)      -198.7    11.1
Ublox Neo6M    binary        7.03 (45969)      -211.6      9.3
Ublox Neo6M    NMEA          7.03 (45969)      -149.0      8.4
Ublox 7        binary        1.00 (59842)      -186.9      2.6
Ublox 7        NMEA          1.00 (59842)      -152.9      7.9
Ublox NEO-8M    binary        2.01 (75350)      -192.7      9.1
Ublox NEO-8M    NMEA          2.01 (75250)      -182.4      8.0

V.KEL SIRFIII  binary        GSW3.2.5          -432.8      6.1
V.KEL SIRFIII  NMEA          GSW3.2.5          -427.6      5.0

Navspark Mini  Venus8        1.7.27 15.8.18    -139.3      7.1

Adafruit Ultimate  NMEA                          -428.2    39.8

Skylab SKM53    NMEA                            -492.0    37.8  (has short jumps to usually -180)

Jupiter-T      Zodiac        93.07            -1263.6      3.3
Juptier-T      Motorola      93.07              -287.9      3.2
Jupiter Pico    Zodiac        14.00 11/28/05    -1235.5      0.4  (ramps -1225 .. -1245 over 130 minutes)
Jupiter Pico    Motorola      14.00 11/28/05    -298.0      1.8

Motorola UT+    Motorola      R5122U1112        -258.2      3.7
Synergy M12+    Motorola      P273T12T11        -194.8      1.4

Z3812A          SCPI          X98-4-A            949.5      0.8  (ramps 945 .. 955 over 16 seconds)
Z3801A          SCPI 19.2K    3543A              973.0      2.0
Symmetricom    UCCM-P 57.6K  1.0.0.2-01        -115.5      3.6  (ramps -109 .. -119 over 10 seconds)
Trimble        UCCM 57.6K    3.0.0.11-0        -278.5      3.1

I found what was causing the apparent ramps in the message offset time for the Motorola mode receivers and the Z38xx receivers. Here is the updated and corrected info. Note that a couple of receivers do have some minor ramp sawtooths in their message timing. They are less than +/- 10 msecs from nominal. ------------------------------------------- Here are the results of measuring the difference between the time code in a GPS receiver time message and the arrival time of the last byte of the message. Negative values mean that the receiver sends the timing message after the 1PPS pulse that it describes. The table also shows the standard deviation of the message arrival times. The test configuration was a Compaq N610C laptop (2 GHz Pentium, hardware serial port) running Linux Ubuntu Mate 15.10). The time of the messagearrival was from the system clock synced to NTP. The receivers were tested in native binary protocol and, if supported, NMEA. The com port was runningat the default value for the receiver. If not specified that was 9600:8:N:1Data was collected after the receiver had been tracking satellites for at least 1 hour and averaged over 4 hours. The timings were also checked andagree with those on a Raspberry PI 3 and a quad-core 3 GHz box. Although measuring the arrival time of the first byte of the timing messagemakes more technical sense (less variation due to timing message length and baud rate) these measurements are of the last byte of the message. This was chosen to assist people trying to sync a clock to a GPS receiver without relying on the 1PPS pulse. They are also useful to people that want to knowhow long they have to process a timing message (like to set a sawtooth compensation delay line) before the next 1PPS pulse comes out. A few receivers appear to not fully sync their timing message to some referenceclock. This causes the timing message arrival time to follow a ramp curve.The ramp size is fairly small (+/- 5 to 10 msecs) in most receivers. Device Protocol Firmware (msg-arrival) sdev (msecs) ============= ============ ================ ======== ===== Thunderbolt TSIP App:3.0 GPS:10.2 -52.9 6.2 (gold box) Thunderbolt TSIP App:2.22 GPS:10.2 -67.2 10.2 (red box) Resolution-T TSIP GPS:1.26 -140.0 5.4 Res-T SMT TSIP GPS 2.7 -475.0 63.7 Starloc II TSIP App:1.10 GPS:1.2 -267.5 7.2 Trimble NTWx? TSIP GPS 10.4 -44.9 1.2 Nortel NTPx TSIP GPS 10.1 -61.8 1.4 Nortel NTGx TSIP GPS 10.5 -57.2 2.4 Ublox LEA-6T binary 6.02 (36023) -242.7 4.4 Ublox LEA-6T NMEA 6.02 (36023) -198.7 11.1 Ublox Neo6M binary 7.03 (45969) -211.6 9.3 Ublox Neo6M NMEA 7.03 (45969) -149.0 8.4 Ublox 7 binary 1.00 (59842) -186.9 2.6 Ublox 7 NMEA 1.00 (59842) -152.9 7.9 Ublox NEO-8M binary 2.01 (75350) -192.7 9.1 Ublox NEO-8M NMEA 2.01 (75250) -182.4 8.0 V.KEL SIRFIII binary GSW3.2.5 -432.8 6.1 V.KEL SIRFIII NMEA GSW3.2.5 -427.6 5.0 Navspark Mini Venus8 1.7.27 15.8.18 -139.3 7.1 Adafruit Ultimate NMEA -428.2 39.8 Skylab SKM53 NMEA -492.0 37.8 (has short jumps to usually -180) Jupiter-T Zodiac 93.07 -1263.6 3.3 Juptier-T Motorola 93.07 -287.9 3.2 Jupiter Pico Zodiac 14.00 11/28/05 -1235.5 0.4 (ramps -1225 .. -1245 over 130 minutes) Jupiter Pico Motorola 14.00 11/28/05 -298.0 1.8 Motorola UT+ Motorola R5122U1112 -258.2 3.7 Synergy M12+ Motorola P273T12T11 -194.8 1.4 Z3812A SCPI X98-4-A 949.5 0.8 (ramps 945 .. 955 over 16 seconds) Z3801A SCPI 19.2K 3543A 973.0 2.0 Symmetricom UCCM-P 57.6K 1.0.0.2-01 -115.5 3.6 (ramps -109 .. -119 over 10 seconds) Trimble UCCM 57.6K 3.0.0.11-0 -278.5 3.1
GE
Gary E. Miller
Thu, Jul 28, 2016 6:33 AM

Yo Mark!

On Thu, 28 Jul 2016 02:13:09 +0000
Mark Sims holrum@hotmail.com wrote:

I found what was causing the apparent ramps in the message offset
time for the Motorola mode receivers and the Z38xx receivers.

And the problem was?

RGDS
GARY

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

Yo Mark! On Thu, 28 Jul 2016 02:13:09 +0000 Mark Sims <holrum@hotmail.com> wrote: > I found what was causing the apparent ramps in the message offset > time for the Motorola mode receivers and the Z38xx receivers. And the problem was? RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703 gem@rellim.com Tel:+1 541 382 8588
attachment.sig (473 bytes)
BC
Bob Camp
Thu, Jul 28, 2016 11:07 AM

Hi

So everything is inside a 10 ms sdev except:

UBLOX LEA-6T NMEA at 11.1 ms (Binary is much better)
Adafruit Ultimate at 39.8 ms

Neither one of those are really surprising. NMEA is not the best thing on uBlox.
The specs on the Adafruit part have never made much sense for timing. Somebody
was a bit confused when they did (or at least spec’d)  that part.

There is the Skylab SKM53 at 37.8 ms. I’ve never seen one of those, so no guess
about that one.

The surprise in the crowd is the Res-T SMT at 63.7 ms. I wonder what they messed
up?

Bob

On Jul 27, 2016, at 10:13 PM, Mark Sims holrum@hotmail.com wrote:

I found what was causing the apparent ramps in the message offset time for the Motorola mode receivers and the Z38xx receivers.  Here is the updated and corrected info.  Note that a couple of receivers do have some minor ramp sawtooths in their message timing.  They are less than +/- 10 msecs from nominal.

Here are the results of measuring the difference between the time code in a GPS receiver time message and the arrival time of the last byte of the message.  Negative values mean that the receiver sends the timing message after the 1PPS pulse that it describes. The table also shows the standard deviation of the message arrival times.

The test configuration was a Compaq N610C laptop (2 GHz Pentium, hardware serial port) running Linux Ubuntu Mate 15.10).  The time of the messagearrival was from the system clock synced to NTP.  The receivers were tested in native binary protocol and, if supported, NMEA.  The com port was runningat the default value for the receiver.  If not specified that was 9600:8:N:1Data was collected after the receiver had been tracking satellites for at least 1 hour and averaged over 4 hours.  The timings were also checked andagree with those on a Raspberry PI 3 and a quad-core 3 GHz box.

Although measuring the arrival time of the first byte of the timing messagemakes more technical sense (less variation due to timing message length and baud rate) these measurements are of the last byte of the message.  This was chosen to assist people trying to sync a clock to a GPS receiver without relying on the 1PPS pulse.  They are also useful to people that want to knowhow long they have to process a timing message (like to set a sawtooth compensation delay line) before the next 1PPS pulse comes out.

A few receivers appear to not fully sync their timing message to some referenceclock.  This causes the timing message arrival time to follow a ramp curve.The ramp size is fairly small (+/- 5 to 10 msecs) in most receivers.

Device        Protocol      Firmware      (msg-arrival)  sdev
(msecs)
=============  ============  ================  ========    =====
Thunderbolt    TSIP        App:3.0 GPS:10.2    -52.9      6.2  (gold box)
Thunderbolt    TSIP        App:2.22 GPS:10.2    -67.2    10.2  (red box)
Resolution-T    TSIP        GPS:1.26            -140.0      5.4
Res-T SMT      TSIP        GPS 2.7            -475.0    63.7
Starloc II      TSIP        App:1.10 GPS:1.2    -267.5      7.2
Trimble NTWx?  TSIP        GPS 10.4            -44.9      1.2
Nortel NTPx    TSIP        GPS 10.1            -61.8      1.4
Nortel NTGx    TSIP        GPS 10.5            -57.2      2.4

Ublox LEA-6T    binary        6.02 (36023)      -242.7      4.4
Ublox LEA-6T    NMEA          6.02 (36023)      -198.7    11.1
Ublox Neo6M    binary        7.03 (45969)      -211.6      9.3
Ublox Neo6M    NMEA          7.03 (45969)      -149.0      8.4
Ublox 7        binary        1.00 (59842)      -186.9      2.6
Ublox 7        NMEA          1.00 (59842)      -152.9      7.9
Ublox NEO-8M    binary        2.01 (75350)      -192.7      9.1
Ublox NEO-8M    NMEA          2.01 (75250)      -182.4      8.0

V.KEL SIRFIII  binary        GSW3.2.5          -432.8      6.1
V.KEL SIRFIII  NMEA          GSW3.2.5          -427.6      5.0

Navspark Mini  Venus8        1.7.27 15.8.18    -139.3      7.1

Adafruit Ultimate  NMEA                          -428.2    39.8

Skylab SKM53    NMEA                            -492.0    37.8  (has short jumps to usually -180)

Jupiter-T      Zodiac        93.07            -1263.6      3.3
Juptier-T      Motorola      93.07              -287.9      3.2
Jupiter Pico    Zodiac        14.00 11/28/05    -1235.5      0.4  (ramps -1225 .. -1245 over 130 minutes)
Jupiter Pico    Motorola      14.00 11/28/05    -298.0      1.8

Motorola UT+    Motorola      R5122U1112        -258.2      3.7
Synergy M12+    Motorola      P273T12T11        -194.8      1.4

Z3812A          SCPI          X98-4-A            949.5      0.8  (ramps 945 .. 955 over 16 seconds)
Z3801A          SCPI 19.2K    3543A              973.0      2.0
Symmetricom    UCCM-P 57.6K  1.0.0.2-01        -115.5      3.6  (ramps -109 .. -119 over 10 seconds)
Trimble        UCCM 57.6K    3.0.0.11-0        -278.5      3.1

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 So everything is inside a 10 ms sdev except: UBLOX LEA-6T NMEA at 11.1 ms (Binary is much better) Adafruit Ultimate at 39.8 ms Neither one of those are really surprising. NMEA is not the best thing on uBlox. The specs on the Adafruit part have never made much sense for timing. Somebody was a bit confused when they did (or at least spec’d) that part. There is the Skylab SKM53 at 37.8 ms. I’ve never seen one of those, so no guess about that one. The surprise in the crowd is the Res-T SMT at 63.7 ms. I wonder what they messed up? Bob > On Jul 27, 2016, at 10:13 PM, Mark Sims <holrum@hotmail.com> wrote: > > I found what was causing the apparent ramps in the message offset time for the Motorola mode receivers and the Z38xx receivers. Here is the updated and corrected info. Note that a couple of receivers do have some minor ramp sawtooths in their message timing. They are less than +/- 10 msecs from nominal. > > ------------------------------------------- > > Here are the results of measuring the difference between the time code in a GPS receiver time message and the arrival time of the last byte of the message. Negative values mean that the receiver sends the timing message after the 1PPS pulse that it describes. The table also shows the standard deviation of the message arrival times. > > > The test configuration was a Compaq N610C laptop (2 GHz Pentium, hardware serial port) running Linux Ubuntu Mate 15.10). The time of the messagearrival was from the system clock synced to NTP. The receivers were tested in native binary protocol and, if supported, NMEA. The com port was runningat the default value for the receiver. If not specified that was 9600:8:N:1Data was collected after the receiver had been tracking satellites for at least 1 hour and averaged over 4 hours. The timings were also checked andagree with those on a Raspberry PI 3 and a quad-core 3 GHz box. > > > Although measuring the arrival time of the first byte of the timing messagemakes more technical sense (less variation due to timing message length and baud rate) these measurements are of the last byte of the message. This was chosen to assist people trying to sync a clock to a GPS receiver without relying on the 1PPS pulse. They are also useful to people that want to knowhow long they have to process a timing message (like to set a sawtooth compensation delay line) before the next 1PPS pulse comes out. > > > A few receivers appear to not fully sync their timing message to some referenceclock. This causes the timing message arrival time to follow a ramp curve.The ramp size is fairly small (+/- 5 to 10 msecs) in most receivers. > > > Device Protocol Firmware (msg-arrival) sdev > (msecs) > ============= ============ ================ ======== ===== > Thunderbolt TSIP App:3.0 GPS:10.2 -52.9 6.2 (gold box) > Thunderbolt TSIP App:2.22 GPS:10.2 -67.2 10.2 (red box) > Resolution-T TSIP GPS:1.26 -140.0 5.4 > Res-T SMT TSIP GPS 2.7 -475.0 63.7 > Starloc II TSIP App:1.10 GPS:1.2 -267.5 7.2 > Trimble NTWx? TSIP GPS 10.4 -44.9 1.2 > Nortel NTPx TSIP GPS 10.1 -61.8 1.4 > Nortel NTGx TSIP GPS 10.5 -57.2 2.4 > > > Ublox LEA-6T binary 6.02 (36023) -242.7 4.4 > Ublox LEA-6T NMEA 6.02 (36023) -198.7 11.1 > Ublox Neo6M binary 7.03 (45969) -211.6 9.3 > Ublox Neo6M NMEA 7.03 (45969) -149.0 8.4 > Ublox 7 binary 1.00 (59842) -186.9 2.6 > Ublox 7 NMEA 1.00 (59842) -152.9 7.9 > Ublox NEO-8M binary 2.01 (75350) -192.7 9.1 > Ublox NEO-8M NMEA 2.01 (75250) -182.4 8.0 > > V.KEL SIRFIII binary GSW3.2.5 -432.8 6.1 > V.KEL SIRFIII NMEA GSW3.2.5 -427.6 5.0 > > Navspark Mini Venus8 1.7.27 15.8.18 -139.3 7.1 > > Adafruit Ultimate NMEA -428.2 39.8 > > Skylab SKM53 NMEA -492.0 37.8 (has short jumps to usually -180) > > Jupiter-T Zodiac 93.07 -1263.6 3.3 > Juptier-T Motorola 93.07 -287.9 3.2 > Jupiter Pico Zodiac 14.00 11/28/05 -1235.5 0.4 (ramps -1225 .. -1245 over 130 minutes) > Jupiter Pico Motorola 14.00 11/28/05 -298.0 1.8 > > Motorola UT+ Motorola R5122U1112 -258.2 3.7 > Synergy M12+ Motorola P273T12T11 -194.8 1.4 > > Z3812A SCPI X98-4-A 949.5 0.8 (ramps 945 .. 955 over 16 seconds) > Z3801A SCPI 19.2K 3543A 973.0 2.0 > Symmetricom UCCM-P 57.6K 1.0.0.2-01 -115.5 3.6 (ramps -109 .. -119 over 10 seconds) > Trimble UCCM 57.6K 3.0.0.11-0 -278.5 3.1 > > > _______________________________________________ > 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.
Empathy v1.0   2025 ©emwd.com
Documentation