Re: [ntp:questions] Garmin GPS18x LVC problem since firmware 3.50
David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: Following my previous message, I can confirm that the NMEA output from the GPS18x LVC with the firmware 3.50 upgrade is coming out something like a second after the PPS signal, and worse, it's very variable so sometimes just before the PPS leading edge, and sometimes after. No wonder NTP is confused! I have contacted Garmin UK via the Web/e-mail form, but as it's almost a two-week holiday here, if someone has a better contact with Garmin US it might be worth alerting them as well. I have requested that the firmware be fixed so that the NMEA output be well under one second delayed, and that the delay be more reproducible (although I haven't made that point strongly enough, so it should be emphasised). Technically, the timestamps in the NMEA messages are the time of fix, not the current time. So a receiver can rightfully keep a calculated fix in memory and send it at some later time, with the timestamp of the original fix included in the message. This makes NMEA unusable for time synchronization. I have seen the behaviour you describe from other receivers, from other manufacturers, as well. For example, I have seen it happen that the offset between PPS and NMEA output varies every time the receiver is restarted, and slowly wanders while the receiver is running. Apparently there is a software timer that sends the messages every second or other interval, but is not locked to the PPS signal. I think by expecting the NMEA to be locked to PPS, you are in fact relying on an implementation detail that often is not covered in the receiver spec, and that can be changed at will (accidentally or for some reason). It is better to switch to the binary protocol, which is manufacturer specific. There usually are messages in the binary protocol to communicate the current time, as opposed to the time of fix, and there are specs that define the relationship between the time and the moment the message is sent. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Garmin GPS18x LVC problem since firmware 3.50
Rob nom...@example.com wrote in message news:slrnihlurn.9vm.nom...@xs8.xs4all.nl... [] Technically, the timestamps in the NMEA messages are the time of fix, not the current time. So a receiver can rightfully keep a calculated fix in memory and send it at some later time, with the timestamp of the original fix included in the message. This makes NMEA unusable for time synchronization. I have seen the behaviour you describe from other receivers, from other manufacturers, as well. For example, I have seen it happen that the offset between PPS and NMEA output varies every time the receiver is restarted, and slowly wanders while the receiver is running. Apparently there is a software timer that sends the messages every second or other interval, but is not locked to the PPS signal. I think by expecting the NMEA to be locked to PPS, you are in fact relying on an implementation detail that often is not covered in the receiver spec, and that can be changed at will (accidentally or for some reason). It is better to switch to the binary protocol, which is manufacturer specific. There usually are messages in the binary protocol to communicate the current time, as opposed to the time of fix, and there are specs that define the relationship between the time and the moment the message is sent. Rob, Thanks for your input. Whilst I understand what you are saying, it seems that this unit /used/ to work as most people expected, with the NMEA output being within the current second rather than outside it, and therefore that /something/ may have changed within the firmware rendering the unit perhaps useless under some circumstances (e.g. stand-alone). Garmin say in the technical specifications for the unit: The NMEA 0183 sentences that follow each rising edge of the PPS signal tell you when you were and where you were at that previous rising edge of the PPS signal, beginning with the GPRMC sentence as the lead sentence in any particular NMEA 0183 record This implies to me that there is a sync-lock between the position determination, the PPS signal, and the data in the NMEA output, and I think it may imply that the GPMRC sentence /must/ be started (or even finished?) /before/ the next PPS rising edge. I would hope that by bringing this problem to Garmin's attention, they may be able to restore the changes in the firmware which have broken this relationship, and has allowed the NMEA data to drift past the /next/ leading edge. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Garmin GPS18x LVC problem since firmware 3.50
David J Taylor david-tay...@blueyonder.co.uk.invalid wrote: Whilst I understand what you are saying, it seems that this unit /used/ to work as most people expected, with the NMEA output being within the current second rather than outside it, and therefore that /something/ may have changed within the firmware rendering the unit perhaps useless under some circumstances (e.g. stand-alone). Garmin say in the technical specifications for the unit: The NMEA 0183 sentences that follow each rising edge of the PPS signal tell you when you were and where you were at that previous rising edge of the PPS signal, beginning with the GPRMC sentence as the lead sentence in any particular NMEA 0183 record This implies to me that there is a sync-lock between the position determination, the PPS signal, and the data in the NMEA output, and I think it may imply that the GPMRC sentence /must/ be started (or even finished?) /before/ the next PPS rising edge. I would hope that by bringing this problem to Garmin's attention, they may be able to restore the changes in the firmware which have broken this relationship, and has allowed the NMEA data to drift past the /next/ leading edge. Yes, it seems that in this case there actually is a spec for the timing and you should be able to make them change the software so it (again) adheres to that spec. The remarks I made were about a receiver (I forget what make and type) where there was no spec like you wrote above. But there was a binary protocol and it contained a specific message for sending the current time, rather than the time-of-fix. Of course the content of that message was no longer valid at the time it was received, but there was a spec that said at which time the content was valid. (like at the start bit of the first byte sent) In gpsd, receivers are switched to their binary protocol when possible, and problems like you have encountered are less likely to occur. But still there are offsets caused by the limited serial bitrate and issues beyond direct control (like the amount of data sent by the receiver, which may vary depending on the number of satellites in view). I never felt completely easy with the derivation of time from the messages received from a GPS. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Garmin GPS18x LVC problem since firmware 3.50
Folks, Following my previous message, I can confirm that the NMEA output from the GPS18x LVC with the firmware 3.50 upgrade is coming out something like a second after the PPS signal, and worse, it's very variable so sometimes just before the PPS leading edge, and sometimes after. No wonder NTP is confused! I have contacted Garmin UK via the Web/e-mail form, but as it's almost a two-week holiday here, if someone has a better contact with Garmin US it might be worth alerting them as well. I have requested that the firmware be fixed so that the NMEA output be well under one second delayed, and that the delay be more reproducible (although I haven't made that point strongly enough, so it should be emphasised). Can NTP even handle an offset of more than one second between PPS and serial? Thanks to Dave Hart for pointing out: http://www.febo.com/pipermail/time-nuts/2010-December/052859.html I felt it best to start a new topic for this problem. Cheers, David ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
