David J Taylor wrote:
"David Lord" <[email protected]> wrote in message
news:[email protected]...
[]
A few us isn't bad from PPS unless I'm supposed to use the -350 ms
from nmea via RxD.
Note that the PPS via serial and parallel are both converging to
same < 10us and it's only when serial DCD is disconnected that
GPS_NMEA shoots off by -350us. PPS via parallel is well within
spread of the servers on network
! after 10 hours
! remote refid st t reach offset jitter
! +GPS_NMEA(0) .GPS. 0 l 377 29.189 21.691
! oPPS(0) .PPS. 0 1 377 -0.009 0.004
! serv1 serv2 2 u 377 1.144 0.526
! serv2 .INIT. 16 u 0 0.000 0.000
! serv3 serv2 2 u 377 -0.018 1.740
[]
David
OK, I mis-read the table. If the 9 microseconds is the true offset,
that's fine (well, it would be for me, anyway). Do the figures say that
with PPS on the parallel port, using the ATOM driver, the GPS is then
just working with serial, and it shows a 29 millisecond offset?
GPS in that table is just using RxD with DCD removed and 650ms
or whatever fudge and mindist increase added (otherwise PPS gets
deselected which might be what I was seeing when attempting to
use just PPS and local servers without refclock).
Just to clarify, though, when above you say "disconnecting the DCD" you
mean leaving the system with no PPS signal, and that's when you see a
350us offset?
TTL pps output from GPS is connected to NACK of parallel port.
Atom driver uses /dev/pps0 which is via ppbus from parallel port.
That's when GPS becomes off by 350ms.
Connecting TTL to both DCD and parallel port gives close agreement
between offset from Atom PPS and GPS_NMEA without fudge or mindist
additions. ie GPS_NMEA seems to use signal on DCD for PPS rather
than from /dev/pps0.
David
_______________________________________________
questions mailing list
[email protected]
http://lists.ntp.org/listinfo/questions
