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

David Lord snews at lordynet.org
Sat Feb 6 12:27:42 UTC 2010

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.


More information about the questions mailing list