[ntp:questions] UTC Time from NMEA receiver one second behind DCF?

Venu Gopal neo.venu at gmail.com
Wed Aug 13 12:33:06 UTC 2008


Venu Gopal wrote:
> David J Taylor wrote:
>> Venu Gopal wrote:
>>> David J Taylor wrote:
>>>> Venu Gopal wrote:
>>>>> I have a couple of similar experiences !
>>>>> I observed that the NMEA sentences are not generated in sync with
>>>>> PPS. Theres lot of jitter in these sentences resulting in 1 second
>>>>> offsets. Its fine if the jitter is within few milliseconds. But
>>>>> sometimes it exceeds a second and thats really painful.
>>>>>
>>>>> This observation was discussed earlier and the solution is to go for
>>>>> a better GPS receiver!
>>>> Use the shortest GPS sentences, and the highest baud rate, to keep
>>>> the total message time as short as possible.
>>>>
>>> The issue is not with the length of the messages and the baud rate.
>>>
>>> Venu
>>
>> Well, I found that if you had a bad configuration (sentences too long 
>> or baud rate too low), the sentences could exceed one second, and 
>> therefore be useless for NTP.
>>
>> However, I have not made any measurements showing jitter versus 
>> sentence length, so I would appreciate any pointers to measurements 
>> you have made or know about.
>>
>> Cheers,
>> David
>>
> I almost scratched my head for a week on this issue.
> I tested with multiple sentences, single sentences with baud rate of 
> 4800 and 9600. Ultimately I understood that the problem is not with the 
> sentence length and baud rate. The problem is with the scheduling 
> process/techniques used within the receiver that generate the sentences.
> 
> For example, we use Accord GPS clock which generates GPGGA, GPGLL, 
> GPZDA, GPZGD(custom sentence). Only GPZDA and GPZDG are generated in 
> sync with PPS and the rest are unusable as they result in 1 second offset.
> 
> I also had a chance to experiment with u-blox GPS receiver. Tried all
> possible combinations but the problem occurred frequently. It was worse 
> than Accord.
> 
> I modified the NMEA driver to log the sentences(all of them) with 
> timestamps. Then wrote scripts/programs to parse these huge logs to 
> check for time offsets. It was decided not to use it with NTP.
'it' here means "u-blox" receiver!
> 
> In fact I had few ideas to solve this problem. But at the end of the day 
>    the problem seemed difficult to solve.
> 
> Venu




More information about the questions mailing list