time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

View all threads

Re: [time-nuts] Adafruit Ultimate GPS timing message arrival times

HM
Hal Murray
Mon, Aug 1, 2016 7:01 AM

From your data and my own measurements, I feel that using the serial NMEA
stream would, today, be a last resort, as an Internet sync would be
considerably better.  Would you agree with that?

Depends on your internet connection and/or the specific GPS module you are
using.

I don't know of any good GPS modules that use NMEA.  I do know of really
crappy internet connections.  Bufferbloat is the buzzword.

--
These are my opinions.  I hate spam.

david-taylor@blueyonder.co.uk said: > From your data and my own measurements, I feel that using the serial NMEA > stream would, today, be a last resort, as an Internet sync would be > considerably better. Would you agree with that? Depends on your internet connection and/or the specific GPS module you are using. I don't know of any good GPS modules that use NMEA. I do know of really crappy internet connections. Bufferbloat is the buzzword. -- These are my opinions. I hate spam.
P
Paul
Mon, Aug 1, 2016 1:52 PM

On Mon, Aug 1, 2016 at 3:01 AM, Hal Murray hmurray@megapathdsl.net wrote:

Depends on your internet connection and/or the specific GPS module you are
using.

I don't know of any good GPS modules that use NMEA.  I do know of really
crappy internet connections.  Bufferbloat is the buzzword.

Bufferbloat is an issue but the NTP problem is unknown assymetric delays.

If you're a bit flexible regarding "module" you can do quite well using
NMEA.  Both points are shown in the output below (sent using a constant
width font).  FURY is a Fury, offset and jitter in milliseconds.

$ ntpq -p
remote          refid      st t when poll reach  delay  offset
jitter


---============
oPPS(0)          .GPPS.          0 l    3    8  377    0.000  -0.002
0.003
*GPS_NMEA(0)    .FURY.          0 l    2    8  377    0.000  -0.010
0.018
time-d.nist.gov .ACTS.          1 u  264  512  353  105.770  29.742
0.348
+nub            .GPPS.          1 s    4  16  377    0.151  -0.025
0.022

Compared to the MTK3xxx in the Adafruit UGPS circa 2-3 years ago.

 remote           refid      st t when poll reach   delay   offset

jitter


---============
oPPS(0)          .GPPS.          0 l    4    8  377    0.000    0.002
0.004
*GPS_NMEA(0)    .ADAU.          0 l    3    8  377    0.000  -78.472
25.623

On Mon, Aug 1, 2016 at 3:01 AM, Hal Murray <hmurray@megapathdsl.net> wrote: > Depends on your internet connection and/or the specific GPS module you are > using. > > I don't know of any good GPS modules that use NMEA. I do know of really > crappy internet connections. Bufferbloat is the buzzword. > Bufferbloat is an issue but the NTP problem is unknown assymetric delays. If you're a bit flexible regarding "module" you can do quite well using NMEA. Both points are shown in the output below (sent using a constant width font). FURY is a Fury, offset and jitter in milliseconds. $ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== oPPS(0) .GPPS. 0 l 3 8 377 0.000 -0.002 0.003 *GPS_NMEA(0) .FURY. 0 l 2 8 377 0.000 -0.010 0.018 time-d.nist.gov .ACTS. 1 u 264 512 353 105.770 29.742 0.348 +nub .GPPS. 1 s 4 16 377 0.151 -0.025 0.022 Compared to the MTK3xxx in the Adafruit UGPS circa 2-3 years ago. remote refid st t when poll reach delay offset jitter ============================================================================== oPPS(0) .GPPS. 0 l 4 8 377 0.000 0.002 0.004 *GPS_NMEA(0) .ADAU. 0 l 3 8 377 0.000 -78.472 25.623
CA
Chris Albertson
Mon, Aug 1, 2016 4:33 PM

You are right.  NTP, even over a poor internet connection can
typically do better then the tens milliseconds we see with some NEMA
GPS'.

But you eyes and human perfection is still even worse.  You can't
notice 40mS of error.

In fact that would be a good experiment:  Put two clocks up on a large
computer monitor and make one always tick some random number of
milliseconds away from system time and the other always thick on the
system time.  Then you click on the one you think is correct.  Can you
do better than a 50/50 guess. Keep incl=reasing the error until the
guesses are about 90% correct.  I bet you find you eyes are really
bad.  You ears are a little better and you might notice 40 mS by
listening to the "tick" sound

Another thought experiment is to show that the randomness of NMEA
jitter does not matter would be to try and build a GPSDO that uses
NMEA data.  If you averaged over a long enough time it would work.
Might be a way to set a Rb oscillator?

One reason NTP works so well even over poor Internet connections is
that it can use 5, 7 or even more other NTP servers to get the time
and all it needs is that a few of them are good.  I typically use
five pool servers when I set up NTP

On Mon, Aug 1, 2016 at 12:01 AM, Hal Murray hmurray@megapathdsl.net wrote:

From your data and my own measurements, I feel that using the serial NMEA
stream would, today, be a last resort, as an Internet sync would be
considerably better.  Would you agree with that?

Depends on your internet connection and/or the specific GPS module you are
using.

I don't know of any good GPS modules that use NMEA.  I do know of really
crappy internet connections.  Bufferbloat is the buzzword.

--
These are my opinions.  I hate spam.


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.

--

Chris Albertson
Redondo Beach, California

You are right. NTP, even over a poor internet connection can typically do better then the tens milliseconds we see with some NEMA GPS'. But you eyes and human perfection is still even worse. You can't notice 40mS of error. In fact that would be a good experiment: Put two clocks up on a large computer monitor and make one always tick some random number of milliseconds away from system time and the other always thick on the system time. Then you click on the one you think is correct. Can you do better than a 50/50 guess. Keep incl=reasing the error until the guesses are about 90% correct. I bet you find you eyes are really bad. You ears are a little better and you might notice 40 mS by listening to the "tick" sound Another thought experiment is to show that the randomness of NMEA jitter does not matter would be to try and build a GPSDO that uses NMEA data. If you averaged over a long enough time it would work. Might be a way to set a Rb oscillator? One reason NTP works so well even over poor Internet connections is that it can use 5, 7 or even more other NTP servers to get the time and all it needs is that a few of them are good. I typically use five pool servers when I set up NTP On Mon, Aug 1, 2016 at 12:01 AM, Hal Murray <hmurray@megapathdsl.net> wrote: > > david-taylor@blueyonder.co.uk said: >> From your data and my own measurements, I feel that using the serial NMEA >> stream would, today, be a last resort, as an Internet sync would be >> considerably better. Would you agree with that? > > Depends on your internet connection and/or the specific GPS module you are > using. > > I don't know of any good GPS modules that use NMEA. I do know of really > crappy internet connections. Bufferbloat is the buzzword. > > > > -- > These are my opinions. I hate spam. > > > > _______________________________________________ > 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. -- Chris Albertson Redondo Beach, California
BC
Bob Camp
Mon, Aug 1, 2016 4:48 PM

Hi

The issue with any of these approaches is how long it will take to converge.

If I start with a pps that is good to 10 ns and my goal is 10 ns or 10 ppb, I’m there in a second.

If I start with a serial string that is good to 10ms and my goal is 10 ppb, I’m waiting for a
million seconds per sample.

If I want to get an Rb to 1x10^-12, I need to wait for 10,000 seconds per sample with the pps.
To do the same thing with the serial string is 10 billion seconds for each independent sample.

The serial string is fine for an "eyeball clock". It’s not so fine for a GPSDO.

Bob

On Aug 1, 2016, at 12:33 PM, Chris Albertson albertson.chris@gmail.com wrote:

You are right.  NTP, even over a poor internet connection can
typically do better then the tens milliseconds we see with some NEMA
GPS'.

But you eyes and human perfection is still even worse.  You can't
notice 40mS of error.

In fact that would be a good experiment:  Put two clocks up on a large
computer monitor and make one always tick some random number of
milliseconds away from system time and the other always thick on the
system time.  Then you click on the one you think is correct.  Can you
do better than a 50/50 guess. Keep incl=reasing the error until the
guesses are about 90% correct.  I bet you find you eyes are really
bad.  You ears are a little better and you might notice 40 mS by
listening to the "tick" sound

Another thought experiment is to show that the randomness of NMEA
jitter does not matter would be to try and build a GPSDO that uses
NMEA data.  If you averaged over a long enough time it would work.
Might be a way to set a Rb oscillator?

One reason NTP works so well even over poor Internet connections is
that it can use 5, 7 or even more other NTP servers to get the time
and all it needs is that a few of them are good.  I typically use
five pool servers when I set up NTP

On Mon, Aug 1, 2016 at 12:01 AM, Hal Murray hmurray@megapathdsl.net wrote:

From your data and my own measurements, I feel that using the serial NMEA
stream would, today, be a last resort, as an Internet sync would be
considerably better.  Would you agree with that?

Depends on your internet connection and/or the specific GPS module you are
using.

I don't know of any good GPS modules that use NMEA.  I do know of really
crappy internet connections.  Bufferbloat is the buzzword.

--
These are my opinions.  I hate spam.


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.

--

Chris Albertson
Redondo Beach, California


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 The issue with any of these approaches is how long it will take to converge. If I start with a pps that is good to 10 ns and my goal is 10 ns or 10 ppb, I’m there in a second. If I start with a serial string that is good to 10ms and my goal is 10 ppb, I’m waiting for a million seconds per sample. If I want to get an Rb to 1x10^-12, I need to wait for 10,000 seconds per sample with the pps. To do the same thing with the serial string is 10 billion seconds for each independent sample. The serial string is fine for an "eyeball clock". It’s not so fine for a GPSDO. Bob > On Aug 1, 2016, at 12:33 PM, Chris Albertson <albertson.chris@gmail.com> wrote: > > You are right. NTP, even over a poor internet connection can > typically do better then the tens milliseconds we see with some NEMA > GPS'. > > But you eyes and human perfection is still even worse. You can't > notice 40mS of error. > > In fact that would be a good experiment: Put two clocks up on a large > computer monitor and make one always tick some random number of > milliseconds away from system time and the other always thick on the > system time. Then you click on the one you think is correct. Can you > do better than a 50/50 guess. Keep incl=reasing the error until the > guesses are about 90% correct. I bet you find you eyes are really > bad. You ears are a little better and you might notice 40 mS by > listening to the "tick" sound > > Another thought experiment is to show that the randomness of NMEA > jitter does not matter would be to try and build a GPSDO that uses > NMEA data. If you averaged over a long enough time it would work. > Might be a way to set a Rb oscillator? > > One reason NTP works so well even over poor Internet connections is > that it can use 5, 7 or even more other NTP servers to get the time > and all it needs is that a few of them are good. I typically use > five pool servers when I set up NTP > > > > > > On Mon, Aug 1, 2016 at 12:01 AM, Hal Murray <hmurray@megapathdsl.net> wrote: >> >> david-taylor@blueyonder.co.uk said: >>> From your data and my own measurements, I feel that using the serial NMEA >>> stream would, today, be a last resort, as an Internet sync would be >>> considerably better. Would you agree with that? >> >> Depends on your internet connection and/or the specific GPS module you are >> using. >> >> I don't know of any good GPS modules that use NMEA. I do know of really >> crappy internet connections. Bufferbloat is the buzzword. >> >> >> >> -- >> These are my opinions. I hate spam. >> >> >> >> _______________________________________________ >> 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. > > > > -- > > Chris Albertson > Redondo Beach, California > _______________________________________________ > 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.
NS
Nick Sayer
Mon, Aug 1, 2016 10:49 PM

On Aug 1, 2016, at 9:33 AM, Chris Albertson albertson.chris@gmail.com wrote:

In fact that would be a good experiment:  Put two clocks up on a large
computer monitor and make one always tick some random number of
milliseconds away from system time and the other always thick on the
system time.  Then you click on the one you think is correct.  Can you
do better than a 50/50 guess. Keep incl=reasing the error until the
guesses are about 90% correct.  I bet you find you eyes are really
bad.  You ears are a little better and you might notice 40 mS by
listening to the "tick" sound

I’ve done something akin to this with my Crazy Clock movements.

The Vetinari clock works by stealing 100 ms from a fraction of the ticks until it’s gathered up enough to do a “double tick.” I wrote the firmware and I can’t tell which seconds are 100 ms off.

There’s also the “Whacky” firmware. It ticks on a random tenth of a second within each second. In practice, it’s far more subtle than I thought it would be. It’s only really obvious when it picks values far apart from their neighbors.

> On Aug 1, 2016, at 9:33 AM, Chris Albertson <albertson.chris@gmail.com> wrote: > > > > In fact that would be a good experiment: Put two clocks up on a large > computer monitor and make one always tick some random number of > milliseconds away from system time and the other always thick on the > system time. Then you click on the one you think is correct. Can you > do better than a 50/50 guess. Keep incl=reasing the error until the > guesses are about 90% correct. I bet you find you eyes are really > bad. You ears are a little better and you might notice 40 mS by > listening to the "tick" sound > I’ve done something akin to this with my Crazy Clock movements. The Vetinari clock works by stealing 100 ms from a fraction of the ticks until it’s gathered up enough to do a “double tick.” I wrote the firmware and I can’t tell which seconds are 100 ms off. There’s also the “Whacky” firmware. It ticks on a random tenth of a second within each second. In practice, it’s far more subtle than I thought it would be. It’s only really obvious when it picks values far apart from their neighbors.
CA
Chris Albertson
Wed, Aug 3, 2016 1:33 AM

On Mon, Aug 1, 2016 at 9:48 AM, Bob Camp kb8tq@n1k.org wrote:

The serial string is fine for an "eyeball clock". It’s not so fine for a
GPSDO.

That is a good way to say it.  NMEA was designed for marine navigation.
Driving ships and boats across an ocean.    So the NMEA that my water speed
sensor produced was good enough it is output at 1Hz.    The NMEA is that
the "data needs to be valid within a second of when it is written".

On Mon, Aug 1, 2016 at 9:48 AM, Bob Camp <kb8tq@n1k.org> wrote: > > The serial string is fine for an "eyeball clock". It’s not so fine for a > GPSDO. > > That is a good way to say it. NMEA was designed for marine navigation. Driving ships and boats across an ocean. So the NMEA that my water speed sensor produced was good enough it is output at 1Hz. The NMEA is that the "data needs to be valid within a second of when it is written".