UTC Time from NMEA receiver one second behind DCF? - NTP

This is a discussion on UTC Time from NMEA receiver one second behind DCF? - NTP ; This is my setup: I am using a Navilock NL-320U connected to a small Linux box running ntp 4.2.4p4-44.1 that came with the openSuSE 11.0 distribution. This is supposed to supply a time service to the local network without the ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 21

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

  1. UTC Time from NMEA receiver one second behind DCF?

    This is my setup:

    I am using a Navilock NL-320U connected to a small Linux box running ntp
    4.2.4p4-44.1 that came with the openSuSE 11.0 distribution. This is
    supposed to supply a time service to the local network without the use of
    external network ntp servers purely from the received GPS signal.

    I know that using a USB connection is not optimal, but the achieved accuracy
    is fine for my needs.

    Last Saturday (2008-08-02) I noticed for the first time that the time off
    the GPS unit was one second behind the DCF time, which I monitor on a
    separate radio clock. A reboot of the system did not help. On Sunday
    (2008-08-03) everything was back to normal. I noticed the same effect again
    on Friday evening (2008-08-08) and through yesterday (2008-08-09), but
    everything seems fine today (2008-08-10).

    I added a network server to my ntp configuration to double check the effect.
    This is how the output "ntpq -p" looks like when everything is fine:

    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    LOCAL(0) .LOCL. 10 l 19 64 377 0.000 0.000
    3.906
    *GPS_NMEA(0) .GPS. 3 l 22 64 377 0.000 14.902
    3.906
    xptbtime2.ptb.de .PTB. 1 u 422 1024 377 66.375 -8.106
    5.216

    And this is the output when I observe the one second lag:

    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    LOCAL(0) .LOCL. 10 l 33 64 17 0.000 0.000
    3.906
    *GPS_NMEA(0) .GPS. 3 l 30 64 17 0.000 -978.27
    11.515
    xptbtime2.ptb.de .PTB. 1 u 31 64 17 67.160 1.002
    3.906

    Looking at the raw NMEA output, the UTC info in there also seems to be one
    second slow.

    In all of this I presume the PTB time to be correct.

    My question is, has anyone else observed this and how can I fix this?

    Thanks

    Harald


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

    Harald Brinkmann wrote:
    > This is my setup:
    >
    > I am using a Navilock NL-320U connected to a small Linux box running ntp
    > 4.2.4p4-44.1 that came with the openSuSE 11.0 distribution. This is
    > supposed to supply a time service to the local network without the use of
    > external network ntp servers purely from the received GPS signal.
    >
    > I know that using a USB connection is not optimal, but the achieved accuracy
    > is fine for my needs.
    >
    > Last Saturday (2008-08-02) I noticed for the first time that the time off
    > the GPS unit was one second behind the DCF time, which I monitor on a
    > separate radio clock. A reboot of the system did not help. On Sunday
    > (2008-08-03) everything was back to normal. I noticed the same effect again
    > on Friday evening (2008-08-08) and through yesterday (2008-08-09), but
    > everything seems fine today (2008-08-10).
    >
    > I added a network server to my ntp configuration to double check the effect.
    > This is how the output "ntpq -p" looks like when everything is fine:
    >
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ============================
    > LOCAL(0) .LOCL. 10 l 19 64 377 0.000 0.000
    > 3.906
    > *GPS_NMEA(0) .GPS. 3 l 22 64 377 0.000 14.902
    > 3.906
    > xptbtime2.ptb.de .PTB. 1 u 422 1024 377 66.375 -8.106
    > 5.216
    >
    > And this is the output when I observe the one second lag:
    >
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ============================
    > LOCAL(0) .LOCL. 10 l 33 64 17 0.000 0.000
    > 3.906
    > *GPS_NMEA(0) .GPS. 3 l 30 64 17 0.000 -978.27
    > 11.515
    > xptbtime2.ptb.de .PTB. 1 u 31 64 17 67.160 1.002
    > 3.906
    >
    > Looking at the raw NMEA output, the UTC info in there also seems to be one
    > second slow.
    >
    > In all of this I presume the PTB time to be correct.
    >
    > My question is, has anyone else observed this and how can I fix this?
    >
    > Thanks
    >
    > Harald
    >


    It sounds as if the GPS receiver you have was designed for navigation
    rather than timing!

    Timing receivers typically have a Pulse Per Second (PPS) output and use
    a binary protocol rather than NMEA to transmit the time to a serial port.

    Using the proper tool for the job should solve many of your problems.

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

    Richard B. Gilbert wrote:

    > Harald Brinkmann wrote:
    >> This is my setup:
    >>
    >> I am using a Navilock NL-320U connected to a small Linux box running ntp
    >> 4.2.4p4-44.1 that came with the openSuSE 11.0 distribution. This is
    >> supposed to supply a time service to the local network without the use of
    >> external network ntp servers purely from the received GPS signal.
    >>
    >> I know that using a USB connection is not optimal, but the achieved
    >> accuracy is fine for my needs.
    >>
    >> Last Saturday (2008-08-02) I noticed for the first time that the time off
    >> the GPS unit was one second behind the DCF time, which I monitor on a
    >> separate radio clock. A reboot of the system did not help. On Sunday
    >> (2008-08-03) everything was back to normal. I noticed the same effect
    >> again on Friday evening (2008-08-08) and through yesterday (2008-08-09),
    >> but everything seems fine today (2008-08-10).
    >>
    >> I added a network server to my ntp configuration to double check the
    >> effect. This is how the output "ntpq -p" looks like when everything is
    >> fine:
    >>
    >> remote refid st t when poll reach delay offset
    >> jitter
    >>

    ================================================== ============================
    >> LOCAL(0) .LOCL. 10 l 19 64 377 0.000 0.000
    >> 3.906
    >> *GPS_NMEA(0) .GPS. 3 l 22 64 377 0.000 14.902
    >> 3.906
    >> xptbtime2.ptb.de .PTB. 1 u 422 1024 377 66.375 -8.106
    >> 5.216
    >>
    >> And this is the output when I observe the one second lag:
    >>
    >> remote refid st t when poll reach delay offset
    >> jitter
    >>

    ================================================== ============================
    >> LOCAL(0) .LOCL. 10 l 33 64 17 0.000 0.000
    >> 3.906
    >> *GPS_NMEA(0) .GPS. 3 l 30 64 17 0.000 -978.27
    >> 11.515
    >> xptbtime2.ptb.de .PTB. 1 u 31 64 17 67.160 1.002
    >> 3.906
    >>
    >> Looking at the raw NMEA output, the UTC info in there also seems to be
    >> one second slow.
    >>
    >> In all of this I presume the PTB time to be correct.
    >>
    >> My question is, has anyone else observed this and how can I fix this?
    >>
    >> Thanks
    >>
    >> Harald
    >>

    >
    > It sounds as if the GPS receiver you have was designed for navigation
    > rather than timing!
    >
    > Timing receivers typically have a Pulse Per Second (PPS) output and use
    > a binary protocol rather than NMEA to transmit the time to a serial port.
    >
    > Using the proper tool for the job should solve many of your problems.


    Point taken. Didn't I mention I am a cheapskate? ;-)

    What flummoxes me is that I occasionally (and only in the last couple of
    days) have observed this offset of almost exactly one second. If this would
    happen to a receiver with PPS, the result would then be exactly one second
    off. I was hoping for some educated guesses how this might have happened.
    Maybe a GPS receiver bug in connection with the upcoming leap second?


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

    Harald Brinkmann writes:

    >Richard B. Gilbert wrote:


    >> Harald Brinkmann wrote:
    >>> This is my setup:
    >>>
    >>> I am using a Navilock NL-320U connected to a small Linux box running ntp
    >>> 4.2.4p4-44.1 that came with the openSuSE 11.0 distribution. This is
    >>> supposed to supply a time service to the local network without the use of
    >>> external network ntp servers purely from the received GPS signal.
    >>>
    >>> I know that using a USB connection is not optimal, but the achieved
    >>> accuracy is fine for my needs.
    >>>
    >>> Last Saturday (2008-08-02) I noticed for the first time that the time off
    >>> the GPS unit was one second behind the DCF time, which I monitor on a
    >>> separate radio clock. A reboot of the system did not help. On Sunday
    >>> (2008-08-03) everything was back to normal. I noticed the same effect
    >>> again on Friday evening (2008-08-08) and through yesterday (2008-08-09),
    >>> but everything seems fine today (2008-08-10).
    >>>
    >>> I added a network server to my ntp configuration to double check the
    >>> effect. This is how the output "ntpq -p" looks like when everything is
    >>> fine:
    >>>
    >>> remote refid st t when poll reach delay offset
    >>> jitter
    >>>

    >================================================== ============================
    >>> LOCAL(0) .LOCL. 10 l 19 64 377 0.000 0.000
    >>> 3.906
    >>> *GPS_NMEA(0) .GPS. 3 l 22 64 377 0.000 14.902
    >>> 3.906
    >>> xptbtime2.ptb.de .PTB. 1 u 422 1024 377 66.375 -8.106
    >>> 5.216
    >>>
    >>> And this is the output when I observe the one second lag:
    >>>
    >>> remote refid st t when poll reach delay offset
    >>> jitter
    >>>

    >================================================== ============================
    >>> LOCAL(0) .LOCL. 10 l 33 64 17 0.000 0.000
    >>> 3.906
    >>> *GPS_NMEA(0) .GPS. 3 l 30 64 17 0.000 -978.27
    >>> 11.515
    >>> xptbtime2.ptb.de .PTB. 1 u 31 64 17 67.160 1.002
    >>> 3.906
    >>>
    >>> Looking at the raw NMEA output, the UTC info in there also seems to be
    >>> one second slow.
    >>>
    >>> In all of this I presume the PTB time to be correct.
    >>>
    >>> My question is, has anyone else observed this and how can I fix this?
    >>>
    >>> Thanks
    >>>
    >>> Harald
    >>>

    >>
    >> It sounds as if the GPS receiver you have was designed for navigation
    >> rather than timing!
    >>
    >> Timing receivers typically have a Pulse Per Second (PPS) output and use
    >> a binary protocol rather than NMEA to transmit the time to a serial port.
    >>
    >> Using the proper tool for the job should solve many of your problems.


    >Point taken. Didn't I mention I am a cheapskate? ;-)


    The Garmin 18LVC reveiver is about $60, and has a pps and serial output--
    some wiring is required.

    It is not clear what is happening. what GPS receiver is it? What are you
    running to get the time off of it?





    >What flummoxes me is that I occasionally (and only in the last couple of
    >days) have observed this offset of almost exactly one second. If this would
    >happen to a receiver with PPS, the result would then be exactly one second
    >off. I was hoping for some educated guesses how this might have happened.
    >Maybe a GPS receiver bug in connection with the upcoming leap second?



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

    Unruh wrote:

    > Harald Brinkmann writes:
    >
    >>Richard B. Gilbert wrote:

    >
    >>> It sounds as if the GPS receiver you have was designed for navigation
    >>> rather than timing!
    >>>
    >>> Timing receivers typically have a Pulse Per Second (PPS) output and use
    >>> a binary protocol rather than NMEA to transmit the time to a serial
    >>> port.
    >>>
    >>> Using the proper tool for the job should solve many of your problems.

    >
    >> Point taken. Didn't I mention I am a cheapskate? ;-)

    >
    > The Garmin 18LVC reveiver is about $60, and has a pps and serial output--
    > some wiring is required.


    The only European source for the Garmin 18LVC I found asks for 160 Euro.

    > It is not clear what is happening. what GPS receiver is it? What are you
    > running to get the time off of it?


    >>> Harald Brinkmann wrote:
    >>>> This is my setup:
    >>>>
    >>>> I am using a Navilock NL-302U connected to a small Linux box running
    >>>> ntp 4.2.4p4-44.1 that came with the openSuSE 11.0 distribution.

    (Please note the corrected transposed digits in the receiver type.)

    I think the point I am interested in is still not yet quite clear to those
    to have been kind enough to reply. I have had this setup up and running for
    about 18 months. The achieved accuracy has always been better than 100
    milliseconds, which may sound awful to most of you, but is good enough for
    my needs. Now, all of a sudden, and only on some days, do I get an offset
    of more or less exactly one second. I haven't yet observed any offsets of
    less than one second. I also haven't observed any bigger offsets. It is
    always either this one second offset or normal operation with relatively
    small offsets that I don't worry about. All of this only began to happen in
    the last week or so. Apparently the Navilock uses the Sirf III chipset,
    which seems to be in widespread use. If there is a bug in there, it should
    have happened to someone else as well, right?


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


    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!

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

    Harald Brinkmann wrote:
    []
    > The only European source for the Garmin 18LVC I found asks for 160
    > Euro.


    Look harder, then!

    http://www.gpsw.co.uk/details/prod2402.html

    GBP 66.95 including tax => Euro 85.

    Cheers,
    David



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

    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.

    David



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

    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

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

    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



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


    >I am using a Navilock NL-320U connected to a small Linux box running ntp
    >4.2.4p4-44.1 that came with the openSuSE 11.0 distribution. This is
    >supposed to supply a time service to the local network without the use of
    >external network ntp servers purely from the received GPS signal.
    >
    >I know that using a USB connection is not optimal, but the achieved accuracy
    >is fine for my needs.


    >Last Saturday (2008-08-02) I noticed for the first time that the time off
    >the GPS unit was one second behind the DCF time, which I monitor on a
    >separate radio clock. A reboot of the system did not help. On Sunday
    >(2008-08-03) everything was back to normal. I noticed the same effect again
    >on Friday evening (2008-08-08) and through yesterday (2008-08-09), but
    >everything seems fine today (2008-08-10).


    [big snip]

    >My question is, has anyone else observed this and how can I fix this?


    I've seen similar quirks from GPS units using the SiRF chip set.
    http://www.megapathdsl.net/~hmurray/ntp/leap-gps3.gif

    It started about the time the leap second was announced. (Otherwise,
    they work, but not very well. They have a 100 ms jitter/drift.)

    It looks like a weekly pattern. It will be interesting to see what happens
    during the next week.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


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

    David J Taylor wrote:

    > Harald Brinkmann wrote:
    > []
    >> The only European source for the Garmin 18LVC I found asks for 160
    >> Euro.

    >
    > Look harder, then!
    >
    > http://www.gpsw.co.uk/details/prod2402.html
    >
    > GBP 66.95 including tax => Euro 85.
    >
    > Cheers,
    > David


    Well, I *looked* harder and all German sources I found ask for well in
    excess of 100 Euro. In addition many of them state that the Garmin is out
    of production or out of stock. The Navilock starting at just over 30 Euro
    is pure cheapskate heaven by comparison. But I am tempted by the U.S.
    prices. I will have to sleep over whether I'm a bigger cheapskate or a
    bigger nerd.

    Thanks

    Harald


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

    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


    But even problems caused by a slow data transmission wouldn't explain why
    the observed offset is small compared to one second most of the time (and
    in my case continuously for well over a year) and suddenly and only on
    certain days there is an offset of almost exactly one second, unless the
    messages are suddenly and only on those days extraordinarily long and just
    happen to delay everything by one second. I'll have a lookout for the raw
    NMEA messages the next time this happens. *If* I were using a PPS signal, I
    could understand the system being confused about which NMEA message belongs
    to which PPS pulse, so one would get an offset of (maybe multiples of) one
    second. But that's not the case here.

    Harald


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

    Hal Murray wrote:

    A long time ago I wrote:
    >>Last Saturday (2008-08-02) I noticed for the first time that the time off
    >>the GPS unit was one second behind the DCF time, which I monitor on a
    >>separate radio clock. A reboot of the system did not help. On Sunday
    >>(2008-08-03) everything was back to normal. I noticed the same effect
    >>again on Friday evening (2008-08-08) and through yesterday (2008-08-09),
    >>but everything seems fine today (2008-08-10).

    >
    > [big snip]
    >
    >>My question is, has anyone else observed this and how can I fix this?

    >
    > I've seen similar quirks from GPS units using the SiRF chip set.
    > http://www.megapathdsl.net/~hmurray/ntp/leap-gps3.gif
    >
    > It started about the time the leap second was announced. (Otherwise,
    > they work, but not very well. They have a 100 ms jitter/drift.)
    >
    > It looks like a weekly pattern. It will be interesting to see what
    > happens during the next week.


    Yes, that fits my observations well, including the weekly pattern...so far.
    I suppose you don't know of any workaround for ntp purposes?

    Cheers

    Harald


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

    Harald Brinkmann wrote:
    []
    > But even problems caused by a slow data transmission wouldn't explain
    > why the observed offset is small compared to one second most of the
    > time (and in my case continuously for well over a year) and suddenly
    > and only on certain days there is an offset of almost exactly one
    > second, unless the messages are suddenly and only on those days
    > extraordinarily long and just happen to delay everything by one
    > second. I'll have a lookout for the raw NMEA messages the next time
    > this happens. *If* I were using a PPS signal, I could understand the
    > system being confused about which NMEA message belongs to which PPS
    > pulse, so one would get an offset of (maybe multiples of) one second.
    > But that's not the case here.
    >
    > Harald


    No, indeed. Hal's graph shows it nicely. I have a SiRF III chip set
    equipped GPS (Garmin GPS60 CSx), but it doesn't display the seconds (or is
    there a screen where it does?). One casual check suggested that it
    changed from 06:20 to 06:21 UTC at about the expected instant, using the
    clock on the map display screen, but I've done no systematic checks.

    I do hope you get to the bottom of this.

    Cheers,
    David



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

    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.

    Venu

  17. 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


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


    >> It looks like a weekly pattern. It will be interesting to see what
    >> happens during the next week.

    >
    >Yes, that fits my observations well, including the weekly pattern...so far.
    >I suppose you don't know of any workaround for ntp purposes?


    If it really is a weekly pattern, then it should be possible to
    hack the NMEA driver to "fix" the problem. I doubt if anybody is
    likely to do it.

    --
    These are my opinions, not necessarily my employer's. I hate spam.


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

    hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:


    >>> It looks like a weekly pattern. It will be interesting to see what
    >>> happens during the next week.

    >>
    >>Yes, that fits my observations well, including the weekly pattern...so far.
    >>I suppose you don't know of any workaround for ntp purposes?


    >If it really is a weekly pattern, then it should be possible to
    >hack the NMEA driver to "fix" the problem. I doubt if anybody is
    >likely to do it.


    A much better fix is to throw away that receiver and get a non-broken one.
    for timing purposes a gps receiver that decides on its own to report the
    wrong time is not worth fixing. Your time is worth more than that.



    >--
    >These are my opinions, not necessarily my employer's. I hate spam.



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

    Unruh wrote:

    > hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray) writes:
    >
    >
    >>>> It looks like a weekly pattern. It will be interesting to see what
    >>>> happens during the next week.
    >>>
    >>>Yes, that fits my observations well, including the weekly pattern...so
    >>>far. I suppose you don't know of any workaround for ntp purposes?

    >
    >>If it really is a weekly pattern, then it should be possible to
    >>hack the NMEA driver to "fix" the problem. I doubt if anybody is
    >>likely to do it.

    >
    > A much better fix is to throw away that receiver and get a non-broken one.
    > for timing purposes a gps receiver that decides on its own to report the
    > wrong time is not worth fixing. Your time is worth more than that.


    Just in case anyone is interested: The bug is active again right now
    (2008-08-15T18:27 UTC).

    Here is a sample ntpq -p

    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    LOCAL(0) .LOCL. 10 l 53 64 3 0.000 0.000
    3.906
    GPS_NMEA(0) .GPS. 3 l 51 64 3 0.000 -987.23
    224.958
    ptbtime2.ptb.de .PTB. 1 u 51 64 3 70.359 21.022
    58.591

    Here are a couple of NMEA messages off my Navilock:

    $GPRMC,182711.000,A,5212.1284,N,00833.4496,E,0.51, 173.76,150808,,*07
    $GPVTG,173.76,T,,M,0.51,N,0.9,K*69
    $GPGGA,182712.000,5212.1283,N,00833.4497,E,1,06,1. 1,83.1,M,47.1,M,,0000*67
    $GPGSA,A,3,24,21,30,29,13,31,,,,,,,2.1,1.1,1.7*3A
    $GPRMC,182712.000,A,5212.1283,N,00833.4497,E,0.78, 163.32,150808,,*08
    $GPVTG,163.32,T,,M,0.78,N,1.5,K*6E
    $GPGGA,182713.000,5212.1282,N,00833.4497,E,1,06,1. 1,83.0,M,47.1,M,,0000*66
    $GPGSA,A,3,24,21,30,29,13,31,,,,,,,2.1,1.1,1.7*3A
    $GPRMC,182713.000,A,5212.1282,N,00833.4497,E,0.43, 182.94,150808,,*03
    $GPVTG,182.94,T,,M,0.43,N,0.8,K*69
    $GPGGA,182714.000,5212.1282,N,00833.4497,E,1,05,1. 2,82.9,M,47.1,M,,0000*69

    When talking about a workaround I was thinking about a combination of
    statuses that are found in these messages that only occurs when the bug is
    active. Trying to guess the times at which it will strike is clearly
    pointless.

    Nevertheless the Garmin unit is on order.

    BTW: I didn't know that ordering GPS units from the U.S. would be *that*
    difficult. :-(

    Cheers

    Harald



+ Reply to Thread
Page 1 of 2 1 2 LastLast