[ntp:questions] fudge time1 for gps-18x-LVC?
David J Taylor
david-taylor at blueyonder.delete-this-bit.and-this-part.co.uk.invalid
Sat Feb 6 13:58:12 UTC 2010
"David Lord" <snews at lordynet.org> wrote in message
news:7t55huFjjbU1 at mid.individual.net...
> David J Taylor wrote:
>> "David Lord" <snews at lordynet.org> wrote in message
>> news:7t53vhFb3mU1 at 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
>> 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.
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 .....
More information about the questions