Michael Eder wrote:
Again we are talking effectively what happens. There is a good deal of
logic what to do if the NMEA and/or pps does not come in and if the system
clock is significantly different from either the NMEA or pps. A whole day
on the lab bench with a scope on both the pps and the NMEA these never
happen. The pps comes in and by definition it must be represent the second
+ 1 of the previous NMEA string. This is exactly the same logic that gpsd
uses and is why we tell NTP that the NMEA has an offset.
We scope the oscillator also and it is a very expensive oceanographic device
that adjusts for temperature automatically.
Sounds like a common problem and I note when we add an additional network
clock the problem seems to go away.
I note there are multiple SHM segments in NTP. Anyone tried writing the pps
time into two locations to fix this problem?
Did you try my suggestion of marking the NMEA as prefer rather
than the PPS?
server 127.127.28.0 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.0 time1 0.680 refid NMEA
server 127.127.28.1 minpoll 4 maxpoll 4
fudge 127.127.28.1 refid PPS
instead of:
server 127.127.28.0 minpoll 4 maxpoll 4
fudge 127.127.28.0 time1 0.680 refid NMEA
server 127.127.28.1 minpoll 4 maxpoll 4 prefer
fudge 127.127.28.1 refid PPS
David
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of unruh
Sent: Thursday, July 14, 2011 5:50 PM
To: [email protected]
Subject: Re: Single GPS/PPS time source gets marked as a
falseticker
On 2011-07-14, Michael Eder <[email protected]> wrote:
Not using gpsd, just writing the NMEA time and receive time into SHM
(0) like gpsd does. The pps does the same to SHM (1). Effectively
the pps code
sounds like a bad procedure. You want to make sure that the nmea actually
gets associated with the second marker that the interupt marks.
Your nmea time will be off by 600ms from the true time, and could well
confuse ntpd.
just increments the second from the NMEA string and writes it to SHM.
We need certain values from the NMEA string so have not looked into
anything but the ASCII strings. PPS comes in on a high priority
interrupt so it gets serviced very quickly. Actually the PPS
conditions an oscillator that we
So when the pps comes in, you can read the system clock and you know how
many usec the clock is out from true time-- you just do not know how many
seconds. Then you can read the system time when the nmea comes in and
determine how many seconds the system time is out from the true time (but
not how many usec.) But combining the two, you can zero in on how many
seconds and usec your system clock is out.
interrupt-> read system time nnnn.uuuuuu
nmea ---- rrrr at system time mmmm.vvvvvv
d=(mmmm.vvvvvv-nnnn.uuuuuu)*1000000)/1000000
(d should be 0, since it should be within a second of interrupt)
Then in the shm ntp packet, the sent and received times are nnnn.uuuuuu, and
the remote received and sent are (rrrr+d).000000 where I am assuming that
the time between the nmea packet and the pps interrupt is under a second--
ie the nmea sentence designates the time of the interrupt that is less than
one second in the past. One could always throw the item away if d is not
equal to 0. If, like in the Garmin 18x, the time of the nmea is close to a
second late, then you could always put in a shift in defining d.
d=int(mmmm.vvvvvv-nnnn.uuuuuu)*1000000.-500000.)/1000000
Ie, you want whatever writes into the shm to associate the nmea time with
the pps time, and since (except for unusual circumstances) the system clock
is assumed to keep reasonably good time (eg be out by not more than say
10000 PPM) you can use it as the flywheel to enable you to do that
association.
use to keep time in the event we lose the GPS (out in the ocean on a
buoy).
The tests I am running are in the lab so we are always getting the
NMEA and PPS.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Rob
Sent: Thursday, July 14, 2011 4:13 AM
To: [email protected]
Subject: Re: Single GPS/PPS time source gets marked as a falseticker
Michael Eder <[email protected]> wrote:
We have looked at our GPS on a scope, the PPS it is dead on and the
NMEA (just one sentence) is also reliable with about a 680 ms latency
and 10 ms jitter.
Again, are you using gpsd?
If so, you may want to try removing the (huge) 680ms offset inside
gpsd instead of in ntpd.
There is a place in the code where a fixed offset is added to time
obtained using NMEA (because the gpsd author does not want
configurable items) and it cannot be correct for every possible receiver.
Again, it is better to switch from NMEA to the native binary protocol
of the receiver.
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
