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

unruh unruh at wormhole.physics.ubc.ca
Sat Feb 6 19:26:51 UTC 2010


On 2010-02-06, David J Taylor <david-taylor at blueyonder.delete-this-bit.and-this-part.co.uk.invalid> wrote:
>
> "David Lord" <snews at lordynet.org> wrote in message 
> news:7t5papF3b1U1 at mid.individual.net...
>> David J Taylor wrote:
> []
>>> 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.
>>
>>
>> David
>
> OK, how long does the GPS sentence take to send at the baud rate you are 
> using?  69 characters at 4800 baud - 480 chars/sec.  About 143 msec. 
> Could it be that the NMEA driver is recognising the end of the character 
> string and not the start?  What is the guaranteed delay time (if any) 
> between PPS and the start of the string on the GPS 18?  I recall some 
> scope plots:

He said that he had left the GPS18 in its default mode, where much more
than a single sentence is sent out ( about 4 of them if I remember
correctly). He shold probably set it so just the single required
sentence is sent out. 

>
>   http://www.dangl.at/ausruest/gps18lvc_e.htm
>
> and your 650ms is almost exactly the delay between the start of the PPS 
> signal and the end of the transmitted serial data as shown here:
>
>   http://www.dangl.at/ausruest/gps_osz21.gif
>
> The delay before the /start/ of the serial data is 350ms, and he is 
> sending two sentences....
>
> An interesting page - my thanks to Gerhard Dangl.

Basically you need to read the nmea and the system time, to calculate
the difference between them. Then on the PPS read the system time, and
calculate the difference between the seconds that the NMEA indicates and
the PPS system time, to caluculate the seconds time for the PPS. (The
NMEA comes about .5 sec before the next PPS, and is 1 second before that
next PPS.  Thus (int)(PPS system time -NMEA system time)+NMEAseconds +1
should be the correct "seconds" corresponding to a given PPS occurance. 
Now, if the system time is reset between the two by more than a second,
this could make the PPS seconds wrong for one single measurement. That
should be eliminated by the ntp "filter" anyway. 




More information about the questions mailing list