Re: [time-nuts] PPS offset between GPS receivers
Hi everyone,
As Tom suggested, I redid the test with less than 1 ft. of wire from the
PPS output to the GPIO without any logic gates or line receivers. Same result,
the SKG25A1 was 2 microseconds ahead of the 58534A. Without any other way of
testing, I would probably trust the output of the timing receiver more
than the SkyNav module. Anyway the SkyNav board is an inexpensive unit and
I wouldn't mind setting an offset in ntpd.
I don't have a scope yet, and a low jitter PPS GPIO is the closest thing I have
to a TIC.
One more test to try. Connect one PPS signal to both GPIO ports and see
how close to zero offset you get. It would likely be random which gets
read first.
On Wed, Dec 5, 2012 at 5:37 AM, Gabs Ricalde gsricalde@gmail.com wrote:
Hi everyone,
As Tom suggested, I redid the test with less than 1 ft. of wire from the
PPS output to the GPIO without any logic gates or line receivers. Same
result,
the SKG25A1 was 2 microseconds ahead of the 58534A. Without any other way
of
testing, I would probably trust the output of the timing receiver more
than the SkyNav module. Anyway the SkyNav board is an inexpensive unit and
I wouldn't mind setting an offset in ntpd.
I don't have a scope yet, and a low jitter PPS GPIO is the closest thing I
have
to a TIC.
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
A lot depends on exactly what the interrupt structure is. It may also depend on the phase of the cpu clock relative to the pps signal. What's reasonably sure is that there is indeed some offset between the two where the answer is indeed "ft's" random. Another thing to check - how wide is the random region?
Bob
On Dec 7, 2012, at 9:19 PM, Chris Albertson albertson.chris@gmail.com wrote:
One more test to try. Connect one PPS signal to both GPIO ports and see
how close to zero offset you get. It would likely be random which gets
read first.
On Wed, Dec 5, 2012 at 5:37 AM, Gabs Ricalde gsricalde@gmail.com wrote:
Hi everyone,
As Tom suggested, I redid the test with less than 1 ft. of wire from the
PPS output to the GPIO without any logic gates or line receivers. Same
result,
the SKG25A1 was 2 microseconds ahead of the 58534A. Without any other way
of
testing, I would probably trust the output of the timing receiver more
than the SkyNav module. Anyway the SkyNav board is an inexpensive unit and
I wouldn't mind setting an offset in ntpd.
I don't have a scope yet, and a low jitter PPS GPIO is the closest thing I
have
to a TIC.
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.
Yes, this is a good test: to evaluate how your preferred uP can perform as
a time interval counter, you can hook two GPDSOs' PPS to it and see the
result. The best would be to have at hand also a real TIC (HP53132A,
PM6681, SR620 or similar) and compare.
On Sat, Dec 8, 2012 at 4:28 AM, Bob Camp lists@rtty.us wrote:
Hi
A lot depends on exactly what the interrupt structure is. It may also
depend on the phase of the cpu clock relative to the pps signal. What's
reasonably sure is that there is indeed some offset between the two where
the answer is indeed "ft's" random. Another thing to check - how wide is
the random region?
Bob
On Dec 7, 2012, at 9:19 PM, Chris Albertson albertson.chris@gmail.com
wrote:
One more test to try. Connect one PPS signal to both GPIO ports and see
how close to zero offset you get. It would likely be random which gets
read first.
On Wed, Dec 5, 2012 at 5:37 AM, Gabs Ricalde gsricalde@gmail.com
wrote:
Hi everyone,
As Tom suggested, I redid the test with less than 1 ft. of wire from the
PPS output to the GPIO without any logic gates or line receivers. Same
result,
the SKG25A1 was 2 microseconds ahead of the 58534A. Without any other
way
of
testing, I would probably trust the output of the timing receiver more
than the SkyNav module. Anyway the SkyNav board is an inexpensive unit
and
I wouldn't mind setting an offset in ntpd.
I don't have a scope yet, and a low jitter PPS GPIO is the closest
thing I
have
to a TIC.
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
and follow the instructions there.
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.
I use a tee connection and terminated 100 foot (33 m )piece of RG58 coax
for a known delay to the stop pulse.
Don L
Azelio Boriani
Yes, this is a good test: to evaluate how your preferred uP can perform
as
a time interval counter, you can hook two GPDSOs' PPS to it and see the
result. The best would be to have at hand also a real TIC (HP53132A,
PM6681, SR620 or similar) and compare.
On Sat, Dec 8, 2012 at 4:28 AM, Bob Camp lists@rtty.us wrote:
Hi
A lot depends on exactly what the interrupt structure is. It may also
depend on the phase of the cpu clock relative to the pps signal.
What's
reasonably sure is that there is indeed some offset between the two
where
the answer is indeed "ft's" random. Another thing to check - how wide
is
the random region?
Bob
On Dec 7, 2012, at 9:19 PM, Chris Albertson
albertson.chris@gmail.com
wrote:
One more test to try. Connect one PPS signal to both GPIO ports and
see
how close to zero offset you get. It would likely be random which
gets
wrote:
Hi everyone,
As Tom suggested, I redid the test with less than 1 ft. of wire
from the
PPS output to the GPIO without any logic gates or line receivers.
Same
result,
the SKG25A1 was 2 microseconds ahead of the 58534A. Without any
other
way
of
testing, I would probably trust the output of the timing receiver
more
than the SkyNav module. Anyway the SkyNav board is an inexpensive
unit
and
I wouldn't mind setting an offset in ntpd.
I don't have a scope yet, and a low jitter PPS GPIO is the closest
thing I
have
to a TIC.
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
and follow the instructions there.
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.
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.
--
"Neither the voice of authority nor the weight of reason and argument
are as significant as experiment, for thence comes quiet to the mind."
De Erroribus Medicorum, R. Bacon, 13th century.
"If you don't know what it is, don't poke it."
Ghost in the Shell
Dr. Don Latham AJ7LL
Six Mile Systems LLP
17850 Six Mile Road
POB 134
Huson, MT, 59846
VOX 406-626-4304
www.lightningforensics.com
www.sixmilesystems.com
OK, I use the two GPSDOs method because I can set the PPS position but the
cable is useful and only one GPSDO (or any other stable PPS source) is
enough.
On Sat, Dec 8, 2012 at 6:53 PM, Don Latham djl@montana.com wrote:
I use a tee connection and terminated 100 foot (33 m )piece of RG58 coax
for a known delay to the stop pulse.
Don L
Azelio Boriani
Yes, this is a good test: to evaluate how your preferred uP can perform
as
a time interval counter, you can hook two GPDSOs' PPS to it and see the
result. The best would be to have at hand also a real TIC (HP53132A,
PM6681, SR620 or similar) and compare.
On Sat, Dec 8, 2012 at 4:28 AM, Bob Camp lists@rtty.us wrote:
Hi
A lot depends on exactly what the interrupt structure is. It may also
depend on the phase of the cpu clock relative to the pps signal.
What's
reasonably sure is that there is indeed some offset between the two
where
the answer is indeed "ft's" random. Another thing to check - how wide
is
the random region?
Bob
On Dec 7, 2012, at 9:19 PM, Chris Albertson
albertson.chris@gmail.com
wrote:
One more test to try. Connect one PPS signal to both GPIO ports and
see
how close to zero offset you get. It would likely be random which
gets
wrote:
Hi everyone,
As Tom suggested, I redid the test with less than 1 ft. of wire
from the
PPS output to the GPIO without any logic gates or line receivers.
Same
result,
the SKG25A1 was 2 microseconds ahead of the 58534A. Without any
other
way
of
testing, I would probably trust the output of the timing receiver
more
than the SkyNav module. Anyway the SkyNav board is an inexpensive
unit
and
I wouldn't mind setting an offset in ntpd.
I don't have a scope yet, and a low jitter PPS GPIO is the closest
thing I
have
to a TIC.
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
and follow the instructions there.
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.
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.
--
"Neither the voice of authority nor the weight of reason and argument
are as significant as experiment, for thence comes quiet to the mind."
De Erroribus Medicorum, R. Bacon, 13th century.
"If you don't know what it is, don't poke it."
Ghost in the Shell
Dr. Don Latham AJ7LL
Six Mile Systems LLP
17850 Six Mile Road
POB 134
Huson, MT, 59846
VOX 406-626-4304
www.lightningforensics.com
www.sixmilesystems.com
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.
I'm now using the SKG25A1 as a PPS source for an NTP server. Aside from
the offset, I noticed a large offset jump in the NTP loopstats
(attached) occurring about once a day. This is not the server oscillator
drifting since the frequency graph looks good at this point and this
behavior can sometimes be triggered by issuing an NMEA hot start
command.
I saw this report showing large differences between the PPS outputs of
different receivers:
http://www.gmat.unsw.edu.au/snap/publications/mumford_2003a.pdf
I'm planning on getting two receivers for comparison, an iLotus M12M and
a Synergy SSR-6T (preferably with the discount). No replies from both
yet.
I'm now using the SKG25A1 as a PPS source for an NTP server. Aside from
the offset, I noticed a large offset jump in the NTP loopstats
(attached) occurring about once a day. This is not the server oscillator
drifting since the frequency graph looks good at this point and this
behavior can sometimes be triggered by issuing an NMEA hot start
command.
I saw this report showing large differences between the PPS outputs of
different receivers:
http://www.gmat.unsw.edu.au/snap/publications/mumford_2003a.pdf
I'm planning on getting two receivers for comparison, an iLotus M12M and
a Synergy SSR-6T (preferably with the discount). No replies from both
yet.
---========
Gabs,
I've seen similar jumps, and it happens when the GPS/PPS signal drops out
for a while. In my case, the GPS receiver is sitting just in an upstairs
room, not near a window or the root (as I normally have my other receivers).
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#u-blox
Watching a low-current LED connected to the PPS signal (through an
appropriate 680-ohm current-limiting resistor), I sometimes see the PPS stop
flashing. If it stops for long enough, NTP will revert to a different
reference. The hot-start may also result in a re-acquisition, and hence a
break in the PPS pulses.
I now need a 10-channel 'scope, as I have Rapco 1804M, Trimble Resolution
SMT, a couple of Garmin GPS-18/x, Sure Electronics boards, and the u-blox
(navigation) receivers shown above. Comparing the PPS outputs they are all
within about 100 ns, more or less. <G> Quite adequate for running NTP on
my systems.
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
On Tue, Dec 11, 2012 at 5:55 PM, David J Taylor
david-taylor@blueyonder.co.uk wrote:
Gabs,
I've seen similar jumps, and it happens when the GPS/PPS signal drops out
for a while. In my case, the GPS receiver is sitting just in an upstairs
room, not near a window or the root (as I normally have my other receivers).
http://www.satsignal.eu/ntp/Raspberry-Pi-NTP.html#u-blox
Watching a low-current LED connected to the PPS signal (through an
appropriate 680-ohm current-limiting resistor), I sometimes see the PPS stop
flashing. If it stops for long enough, NTP will revert to a different
reference. The hot-start may also result in a re-acquisition, and hence a
break in the PPS pulses.
I now need a 10-channel 'scope, as I have Rapco 1804M, Trimble Resolution
SMT, a couple of Garmin GPS-18/x, Sure Electronics boards, and the u-blox
(navigation) receivers shown above. Comparing the PPS outputs they are all
within about 100 ns, more or less. <G> Quite adequate for running NTP on
my systems.
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
David,
I forgot to thank you for your helpful site and NTP plotter.
I have the antenna outside with a 180 degree view of the sky, outages
should be rare. Looking at the loopstats, the outage during the 4 us
jump is about 12 seconds. This is a test server, I only have the LOCAL
and PPS refclocks configured so during the outage the clock just
flywheels. I agree these cheap GPS receivers are more than enough for a
stratum 1 NTP server.
How about a 10 channel TIC? I'm sure someone could suggest a way to do
it, probably several PICTIC II's?
From: Gabs Ricalde
[]
David,
I forgot to thank you for your helpful site and NTP plotter.
I have the antenna outside with a 180 degree view of the sky, outages
should be rare. Looking at the loopstats, the outage during the 4 us
jump is about 12 seconds. This is a test server, I only have the LOCAL
and PPS refclocks configured so during the outage the clock just
flywheels. I agree these cheap GPS receivers are more than enough for a
stratum 1 NTP server.
How about a 10 channel TIC? I'm sure someone could suggest a way to do
it, probably several PICTIC II's?
---===========
Agreed, that if your antenna has a good view of the sky you should not be
seeing these drop-outs, at least not on a regular basis. There are
atmospheric conditions which will affect the GPS signals, though, but they
should be rare. No chance you get a trucker with a GPS jammer driving by at
the problem times, I suppose?
You say LOCAL and PPS - no "seconds" reference such as GPS/NMEA?
You might also want to check what's happening on the box at the time of the
jump. If it's regular, perhaps some scheduled task is the cause?
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
On Tue, Dec 11, 2012 at 8:00 PM, David J Taylor
david-taylor@blueyonder.co.uk wrote:
From: Gabs Ricalde
[]
David,
I forgot to thank you for your helpful site and NTP plotter.
I have the antenna outside with a 180 degree view of the sky, outages
should be rare. Looking at the loopstats, the outage during the 4 us
jump is about 12 seconds. This is a test server, I only have the LOCAL
and PPS refclocks configured so during the outage the clock just
flywheels. I agree these cheap GPS receivers are more than enough for a
stratum 1 NTP server.
How about a 10 channel TIC? I'm sure someone could suggest a way to do
it, probably several PICTIC II's?
---===========
Agreed, that if your antenna has a good view of the sky you should not be
seeing these drop-outs, at least not on a regular basis. There are
atmospheric conditions which will affect the GPS signals, though, but they
should be rare. No chance you get a trucker with a GPS jammer driving by at
the problem times, I suppose?
You say LOCAL and PPS - no "seconds" reference such as GPS/NMEA?
You might also want to check what's happening on the box at the time of the
jump. If it's regular, perhaps some scheduled task is the cause?
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk
I'm not sure about the jammer but I'm running a timing receiver in
position hold several floors up, I haven't seen dropouts like this.
ntpd is running with a "noselect" NMEA source since I'm having problems
with ntpd marking the PPS and NMEA as falsetickers. The startup sequence
for the server is this:
- run ntpd -g -q with NMEA enabled
- run chronyd for 3 minutes to set the time and frequency offset
- copy the current frequency to ntpd's drift file, then run ntpd with
NMEA disabled
This hack seems to work everytime with ntpd ready in less than 4 minutes
after turning on. I just hope nothing would happen that changes the
time.
I have seen 0.2 us spikes every hour from some unknown task but the
larger spikes are rare. Another device running the same OpenWrt firmware
but with a timing receiver has only the small periodic spikes.
I'm not sure about the jammer but I'm running a timing receiver in
position hold several floors up, I haven't seen dropouts like this.
ntpd is running with a "noselect" NMEA source since I'm having problems
with ntpd marking the PPS and NMEA as falsetickers. The startup sequence
for the server is this:
- run ntpd -g -q with NMEA enabled
- run chronyd for 3 minutes to set the time and frequency offset
- copy the current frequency to ntpd's drift file, then run ntpd with
NMEA disabled
This hack seems to work everytime with ntpd ready in less than 4 minutes
after turning on. I just hope nothing would happen that changes the
time.
I have seen 0.2 us spikes every hour from some unknown task but the
larger spikes are rare. Another device running the same OpenWrt firmware
but with a timing receiver has only the small periodic spikes.
---==============
Gabs,
Sorry, I'm not familiar enough with Linux to be able to help. On my systems
there's just the automated start of ntpd, with no 3rd party software, and
the PPS is a separate kernel-mode driver, not the one integrated into the
NMEA driver. It may be best to ask on the Usenet comp.protocols.time.ntp
group to get NTP working properly.
Cheers,
David
SatSignal Software - Quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@blueyonder.co.uk