Re: UTC Time from NMEA receiver one second behind DCF?

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
.

Relevant Pages

  • Re: UTC Time from NMEA receiver one second behind DCF?
    ... Its fine if the jitter is within few milliseconds. ... The issue is not with the length of the messages and the baud rate. ... 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. ...
    (comp.protocols.time.ntp)
  • Re: Variations on XTAL clock AND time synchronization
    ... You can buy a GPS receiver that produces 1 PPS with hardly ... The 1-PPS output was very low jitter on one ... special-purpose hardware, not just a digital input pin on a PC, so I ...
    (comp.arch.embedded)
  • Re: Variations on XTAL clock AND time synchronization
    ... You can buy a GPS receiver that produces 1 PPS with hardly ... The 1-PPS output was very low jitter on one ... special-purpose hardware, not just a digital input pin on a PC, so I ...
    (sci.electronics.misc)
  • Re: Variations on XTAL clock AND time synchronization
    ... You can buy a GPS receiver that produces 1 PPS with hardly ... The 1-PPS output was very low jitter on one ... special-purpose hardware, not just a digital input pin on a PC, so I ...
    (sci.electronics.components)
  • Re: UTC Time from NMEA receiver one second behind DCF?
    ... Its fine if the jitter is within few milliseconds. ... the total message time as short as possible. ... The issue is not with the length of the messages and the baud rate. ... I have not made any measurements showing jitter versus sentence ...
    (comp.protocols.time.ntp)