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