[ntp:questions] fudge time1 for gps-18x-LVC?
snews at lordynet.org
Sat Feb 6 18:05:13 UTC 2010
David J Taylor wrote:
> "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
That's why I ran the network cable upstairs so I could confirm
fudge was in right direction so I was not a second out one way
I wasn't expecting such a large fudge time being needed.
> 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