"David Lord" <sn...@lordynet.org> wrote in message
news:7t55hufjj...@mid.individual.net...
David J Taylor wrote:
"David Lord" <sn...@lordynet.org> wrote in message
news:7t53vhfb3...@mid.individual.net...
[]
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
David,
You're confusing me even more here! Is a summary:
1 - PPS connected to DCD (serial) - low offset
2 - PPS connected to DCD (serial) and NACK (parallel) - low offset
3 - GPS to serial, PPS to parallel alone, PPS loses sync.
4 - GPS to serial with 650ms fudge, PPS to parallel alone - low offset
I'm sure that Dave Hart was also looking at a hybrid "network" time and
DCD/NACK PPS, but quite how far he got I can't recall. I think he got it
working. Again, from memory, I recall that the serial alone from the GPS
is poorer than "network" time, and might even be better disconnected. I
think the low baud rate didn't help, so perhaps making the GPS work as
fats as it and the NTP software will allow would reduce the perceived
jitter from the GPS, and allow the NACK/PPS to keep on working, and
perhaps with a much lower GPS fudge? Just some thoughts .....
Cheers,
David
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
