Skytraq Venus 6 leap seconds added about gpsbabel

[robertlipe]

ISTR there's a hardcoded constant in skytraq.cc because future changes are difficult to predict. We could fetch that from a server somewhere (trivially hosted on gpsbabel.org) so it'd be at least somewhat self-updating so we don't have to go fiddle with a number and wait for a release. You may be one of the very few users of IGC. We just don't hear a lot from that space.

…

On Sun, Apr 16, 2017 at 2:34 AM, Mobius ***@***.***> wrote: Hello I downloaded my GPS Canmore GT750FL-S with GPSBabel, format IGC The time have an offset of 3 to 4 seconds with UTC time The chip Venus 6 have a GPS time and the software must add the leap seconds since the launching of the first satellite. GPS time start at 1980, Jan. 5/6 mid-night, actually (April 2017) GPS time is ahead of UTC by 18 seconds. The lead seconds seen to be incorrectly corrected, what is the value take account by the software ? Mobius — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#70>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIUh76XpXofjipQc8-Lez0pSTXwXU67aks5rweC-gaJpZM4M-ldt> .

[GPSBabelDeveloper]

Actually, it's kind of dumb that we have to do anything at all here. The GPS SVs (space vehicles) actually transmit the offset between UTC and GPS and they announce the change a few months in advance. http://www.insidegnss.com/node/4551 Of all our formats, Skytraq is the only one where I can recall having to fiddle with this. Are we just reading a gps time field instead of a utc time field from these devices? Does thier protocol expose UTC or at least the offset to UTC anywhere? The receiver knows these things and this seems like either a bug in their implementation (exposing GPS instead of UTC time) or us not querying for an offset or reading the "right" field. Any Skytraq//Venus experts? Heck, any dedicated researchers to help track this down would be welcome. I looked at half a dozen implementations and there are all like "// TODO(deal with GPS->UTC conversion)" On Sun, Apr 16, 2017 at 10:18 AM, Robert Lipe <[email protected]> wrote:

…

ISTR there's a hardcoded constant in skytraq.cc because future changes are difficult to predict. We could fetch that from a server somewhere (trivially hosted on gpsbabel.org) so it'd be at least somewhat self-updating so we don't have to go fiddle with a number and wait for a release. You may be one of the very few users of IGC. We just don't hear a lot from that space. On Sun, Apr 16, 2017 at 2:34 AM, Mobius ***@***.***> wrote: > Hello > I downloaded my GPS Canmore GT750FL-S with GPSBabel, format IGC > The time have an offset of 3 to 4 seconds with UTC time > The chip Venus 6 have a GPS time and the software must add the leap > seconds since the launching of the first satellite. > GPS time start at 1980, Jan. 5/6 mid-night, actually (April 2017) GPS time > is ahead of UTC by 18 seconds. > > The lead seconds seen to be incorrectly corrected, what is the value take > account by the software ? > > Mobius > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#70>, or mute the thread > <https://github.com/notifications/unsubscribe-auth/AIUh76XpXofjipQc8- Lez0pSTXwXU67aks5rweC-gaJpZM4M-ldt> > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#70 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALdQD0DU8aT-8-8hAVa5TJ7cSwpDweLiks5rwk12gaJpZM4M-ldt> .

[tsteven4]

My interpretation of the spec is that the time recorded in a IGC file should be in UTC with any necessary correction already applied. This is consistent with the gpsbabel IGC format support. http://carrier.csi.cam.ac.uk/forsterlewis/soaring/igc_file_format/igc_format_2008.html

*2.4 UNITS.* Data in the IGC file shall use the following unit system: Time - UTC, obtained from the same GNSS data package from which the recorded lat/long and GPS altitude are also obtained, or, if GPS is not locked on, from the Real-Time Clock in the recorder. Note that UTC is not the same as GPS internal system time that is different by 14 seconds in 2006 due to the addition of 'leap seconds' since the GPS system first became operational in January 1980. The correction to UTC available within the GPS system must be applied to time recorded in IGC files.(AL9 <http://www.fai.org/gliding/system/files/tech_spec_gnss_al9.pdf>)

http://www.fai.org/component/phocadownload/category/855-technicalspecifications?download=11005:igc-fr-spec-with-al4a-2016-4-10

…

3.4 Time. The time datum is UTC. For fixes in the IGC file the UTC time must be derived from the same data package inwhich the lat/long and other material in the fixwas derived, or, if GPS is not locked on, fromthe Real-Time Clock (RTC) in the recorder. The IGC data file requirement (Appendix A) requires times in data files to be in UTC. On 4/16/2017 12:14 PM, GPSBabel wrote: Actually, it's kind of dumb that we have to do anything at all here. The GPS SVs (space vehicles) actually transmit the offset between UTC and GPS and they announce the change a few months in advance. http://www.insidegnss.com/node/4551 Of all our formats, Skytraq is the only one where I can recall having to fiddle with this. Are we just reading a gps time field instead of a utc time field from these devices? Does thier protocol expose UTC or at least the offset to UTC anywhere? The receiver knows these things and this seems like either a bug in their implementation (exposing GPS instead of UTC time) or us not querying for an offset or reading the "right" field. Any Skytraq//Venus experts? Heck, any dedicated researchers to help track this down would be welcome. I looked at half a dozen implementations and there are all like "// TODO(deal with GPS->UTC conversion)" On Sun, Apr 16, 2017 at 10:18 AM, Robert Lipe ***@***.***> wrote: > ISTR there's a hardcoded constant in skytraq.cc because future changes are > difficult to predict. > > We could fetch that from a server somewhere (trivially hosted on > gpsbabel.org) so it'd be at least somewhat self-updating so we don't have > to go fiddle with a number and wait for a release. > > You may be one of the very few users of IGC. We just don't hear a lot from > that space. > > > > On Sun, Apr 16, 2017 at 2:34 AM, Mobius ***@***.***> wrote: > > > Hello > > I downloaded my GPS Canmore GT750FL-S with GPSBabel, format IGC > > The time have an offset of 3 to 4 seconds with UTC time > > The chip Venus 6 have a GPS time and the software must add the leap > > seconds since the launching of the first satellite. > > GPS time start at 1980, Jan. 5/6 mid-night, actually (April 2017) GPS > time > > is ahead of UTC by 18 seconds. > > > > The lead seconds seen to be incorrectly corrected, what is the value take > > account by the software ? > > > > Mobius > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > <#70>, or mute the thread > > <https://github.com/notifications/unsubscribe-auth/AIUh76XpXofjipQc8- > Lez0pSTXwXU67aks5rweC-gaJpZM4M-ldt> > > . > > > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#70 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ALdQD0DU8aT-8-8hAVa5TJ7cSwpDweLiks5rwk12gaJpZM4M-ldt> > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#70 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AM92MW38nY5pkL2VWgTGjMHfON5lzOn0ks5rwlp4gaJpZM4M-ldt>.

[robertlipe]

Right idea, wrong end. (That's easy to do in GPSBabel-land.) The problem is the stupid Venus chipset. see gpstime_to_timet in skytraq.cc The satellites transmit the gps time and the offset to utc, but we're only getting gps time. I can't tell if the device exposes the offset down to the protocol. IMO, the GPS should be exposing UTC like every other device, but they didn't ask me.

…

On Mon, Apr 17, 2017 at 7:23 AM, tsteven4 ***@***.***> wrote: My interpretation of the spec is that the time recorded in a IGC file should be in UTC with any necessary correction already applied. This is consistent with the gpsbabel IGC format support. http://carrier.csi.cam.ac.uk/forsterlewis/soaring/igc_file_ format/igc_format_2008.html > *2.4 UNITS.* > > Data in the IGC file shall use the following unit system: > > Time - UTC, obtained from the same GNSS data package from which the > recorded lat/long and GPS altitude are also obtained, or, if GPS is > not locked on, from the Real-Time Clock in the recorder. Note that UTC > is not the same as GPS internal system time that is different by 14 > seconds in 2006 due to the addition of 'leap seconds' since the GPS > system first became operational in January 1980. The correction to UTC > available within the GPS system must be applied to time recorded in > IGC files.(AL9 > <http://www.fai.org/gliding/system/files/tech_spec_gnss_al9.pdf>) http://www.fai.org/component/phocadownload/category/855- technicalspecifications?download=11005:igc-fr-spec-with-al4a-2016-4-10 > 3.4 Time. The time datum is UTC. For fixes in the IGC file the UTC > time must be derived from the same data package > inwhich the lat/long and other material in the fixwas derived, or, if > GPS is not locked on, fromthe Real-Time Clock (RTC) > in the recorder. > The IGC data file requirement (Appendix A) requires times in data > files to be in > UTC. On 4/16/2017 12:14 PM, GPSBabel wrote: > Actually, it's kind of dumb that we have to do anything at all here. The > GPS SVs (space vehicles) actually transmit the offset between UTC and GPS > and they announce the change a few months in advance. > > http://www.insidegnss.com/node/4551 > > Of all our formats, Skytraq is the only one where I can recall having to > fiddle with this. Are we just reading a gps time field instead of a utc > time field from these devices? Does thier protocol expose UTC or at least > the offset to UTC anywhere? The receiver knows these things and this seems > like either a bug in their implementation (exposing GPS instead of UTC > time) or us not querying for an offset or reading the "right" field. > > Any Skytraq//Venus experts? Heck, any dedicated researchers to help track > this down would be welcome. I looked at half a dozen implementations and > there are all like "// TODO(deal with GPS->UTC conversion)" > > > > On Sun, Apr 16, 2017 at 10:18 AM, Robert Lipe ***@***.***> > wrote: > > > ISTR there's a hardcoded constant in skytraq.cc because future > changes are > > difficult to predict. > > > > We could fetch that from a server somewhere (trivially hosted on > > gpsbabel.org) so it'd be at least somewhat self-updating so we don't > have > > to go fiddle with a number and wait for a release. > > > > You may be one of the very few users of IGC. We just don't hear a > lot from > > that space. > > > > > > > > On Sun, Apr 16, 2017 at 2:34 AM, Mobius ***@***.***> > wrote: > > > > > Hello > > > I downloaded my GPS Canmore GT750FL-S with GPSBabel, format IGC > > > The time have an offset of 3 to 4 seconds with UTC time > > > The chip Venus 6 have a GPS time and the software must add the leap > > > seconds since the launching of the first satellite. > > > GPS time start at 1980, Jan. 5/6 mid-night, actually (April 2017) GPS > > time > > > is ahead of UTC by 18 seconds. > > > > > > The lead seconds seen to be incorrectly corrected, what is the > value take > > > account by the software ? > > > > > > Mobius > > > > > > — > > > You are receiving this because you are subscribed to this thread. > > > Reply to this email directly, view it on GitHub > > > <#70>, or mute the thread > > > <https://github.com/notifications/unsubscribe- auth/AIUh76XpXofjipQc8- > > Lez0pSTXwXU67aks5rweC-gaJpZM4M-ldt> > > > . > > > > > > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > <#70 (comment) >, > > or mute the thread > > > <https://github.com/notifications/unsubscribe-auth/ALdQD0DU8aT-8- 8hAVa5TJ7cSwpDweLiks5rwk12gaJpZM4M-ldt> > > . > > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#70 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ AM92MW38nY5pkL2VWgTGjMHfON5lzOn0ks5rwlp4gaJpZM4M-ldt>. > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#70 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIUh7xSTfhnDhMcnpsqd2p9I_Lfgm08Oks5rw3X1gaJpZM4M-ldt> .

[mobiusrpi]

Thanks for yours answers

You right Robert, UTC offset is provide by GPS signal but the storage in the chipset Venus6 is done in the raw format : Week number and Time of week.
Description is in the Appendix A of the Application Note AN0008 ver. 1.4.11 Jan. 05, 2009. So the leap seconds must be subtract by software to have the right UTC time

Actually official offset is 18 sec,
I did my tests with my car and to determine the right UTC time on a known position, But I have plenty of inaccuracy : coordinate, clock synchronization, top chrono, GPS uncertainty,...
I compared the different time provided by the following software but none of then give the correct time

• Canway 1.1.09 : 3,5 sec
• GPSBabel 1.5.4 : 2,5 sec
• GPSViewer 2.0.253 : 2,5 sec

I can't determine if the offset is 3 or 4 seconds
Can you check your code to confirm which offset is take account in you software to known how muck I need to correct

[mobiusrpi]

Sorry, I missed the skytraq.cc file information in your message
I went to see the code and your offset is 16 seconds so I need to add 2 to have UTC time

Thanks

[robertlipe]

So all the software is broken at various times because Skytraq doesn't use the data that's in the very GPS frames it's decoding and this is our problem because Skytraq doesn't expose that data to the hose. Awesome. I'm not sure I care to solve this much better than the current "fix on fail" method - wait for someone to notice and then fix it. Better yet, if someone that cares wants to monitor, say, http://tycho.usno.navy.mil/leapsec.html and submit pull requests with the "obvious" copy-paste change to skytraq, that'd work. Until then, there's the 'move' option to the track filter for those that care about timestamps at that resolution.

…

On Mon, Apr 17, 2017 at 10:33 AM, Mobius ***@***.***> wrote: Sorry, I missed the skytraq.cc file information in your message I went to see the code and your offset is 16 seconds so I need to add 2 to have UTC time Thanks — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#70 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIUh714fpPew6ZSYti08pER0uXIdsli1ks5rw6JwgaJpZM4M-ldt> .

[GPSBabelDeveloper]

Fixed in ce052fe

Added a command line flag to override our builtin table.