feature request: GPS time (seconds since 6 Jan 1980)

[grahamwoan]

Hi - This library looks really excellent. A useful variable would be the GPS time as seconds from GPS-zero (6 Jan 1980) which I guess comes from NAV-TIMEGPS. These values are increasingly used in astronomy (eg LIGO) as convenient data timestamps and are not present in the default NMEA strings (although depending on firmware the GPS time can be extracted from a $PUBX,04 query).

[nseidle]

Hmm, neat request but there's nothing obviously built in to the Ublox protocol that supports that (that I can find).

NAV-TIMEGPS has iTOW but TIMEGPS is really a report of the (see Integration guide 3.5.3) navigation epoch (which I interpret as the time stamp of last location solution). And it's not GPS Epoch, it is milliseconds into this week (GPS time of week).

One could theoretically get yyyy/mm/dd hh:mm:ss.ss UTC then calculate the seconds since GPS epoch. It would be a fun CS exercise for someone but not one I immediately have bandwidth for.

What precision of time does LIGO (googling, wow, binary black holes! oh wow, final parsec problem... Wow that's interesting stuff!) need? Looks like 0.01s is easily achieved but the time pulse could get you down to ~30-60ns.

[grahamwoan]

Hi Nathan -- thanks for getting back. I think it's quite doable (at least for integer seconds) and have managed it using the ublox NMEA query I mentioned, which returns UTC week number, time of week and leap seconds (the sum of which, in seconds, is gps time) to give the equivalent of https://www.gw-openscience.org/gps/. Sadly the leap second part of that NMEA query seems to be firmware dependent so it's a bit unsatisfactory as a general solution.

Advanced LIGO's absolute timing needs are around 1 us right now (see https://dcc.ligo.org/public/0095/T070173/001/T070173-06.pdf, https://iopscience.iop.org/article/10.1088/0264-9381/27/8/084025/meta), largely set by the precision to which one can measure the time delay between two transient and noisy signals, say from coalescing black holes, received at the two LIGO sites. It's this time delay, and the delay to other gravitational wave detectors, notable VIRGO, that gives the sky location of the signal.

This ublox query is just for me though! I should add that NAV-TIMEGPS (0x01 0x20) UBX message seems to have the gps week/tow and leap-second data for a NEO 6. However I appreciate the bandwidth problem!

[nseidle]

Ok neat. So do you still have an issue? Is that a 'yes please add a getEpochSeconds() function' or will integer seconds not really be enough for your applications?

[grahamwoan]

Unfortunately I do still have an issue with some boards. I do just need the integer total GPS time in seconds (eg 1245770907), and thought the NMEA string would suffice. However, moving to a different board (different firmware maybe?) the leap second field in that string contained a replica of the UTC_TOW value rather than the expected value of "18" (see https://www.u-blox.com/sites/default/files/products/documents/u-blox6_ReceiverDescrProtSpec_%28GPS.G6-SW-10018%29_Public.pdf page 75 field 6). NAV-TIMEGPS (page 179) seems to give the necessary data even with earlier firmware, so a getEpochSeconds() would be excellent, but based on the UBX call rather than (or in addition to) an NMEA call.

I should add that I have not checked that this UBX NAV-TIMEGPS call works on this problematic board, so if there is a simple way to check that with existing library calls I can do that.

It does seem unexpectedly difficult to extract GPS time reliably from a GPS receiver!

[tedder]

You must be using some other library for the "different board", @grahamwoan?

This library currently only returns the milliseconds part of iTOW; PR #47 will add getTimeOfWeek() support for supported boards.

[grahamwoan]

I was using this library and a ublox chipset, so my original query was about having the full TOW as an addition. To close the loop on this, in the end I went with no library and a binary UBX call rather than NMEA. That worked fine on all the NEO6 boards I have. Having access to a linear timescale with no leap second discontinuities would be a very useful new feature for the general library though.