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

Venu Gopal neo.venu at gmail.com
Wed Aug 13 10:52:45 UTC 2008

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.

In fact I had few ideas to solve this problem. But at the end of the day 
    the problem seemed difficult to solve.


More information about the questions mailing list