[ntp:questions] fudge time1 for gps-18x-LVC?

David Lord 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
>>> []
>>>> 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

That's correct.

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
or other.

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 .....
> Cheers,
> David

More information about the questions mailing list