Clarifications on the GNSS time bases in use

[pavel-kirienko]

See this discussion for background: https://groups.google.com/forum/#!topic/uavcan/D5ZcsvirrbI

This pull request does not introduce any changes to the actual data type definitions. It only affects the comments.

Paging @olliw42 @glennib @WickedShell.

[olliw42]

Hey Pavel

I very much like the changes, they are definitely a big step forward.

The main problem I still have is that it is not clear what the time stamp means or what the behavior should be in case the correct number of UTC leap seconds is not known. I think this must be transparent to the user of the message. Since the leap seconds may not be known even at a fix, programmers may be tempted to derive that number from other sources, which may be however "best guesses", "approximate", dependent on user attention, and so. I think such practices should either be clearly ruled out, or the behavior be specified. The latter can probably not be accommodated without more substantial changes to the dsdl message.

EDIT: The BIPM, which is responsible for the UTC leap seconds, announces them in reference to TAI (http://www.bipm.org/en/bipm-services/timescales/leap-second.html). I think one should follow that, and I thus changed the text.

Thus, maybe something like this:

# 
# Time solution.
#
# The method and number of leap seconds which were in use for deriving the timestamp are 
# defined in the fields below. This data type relies on the following definitions:
#
#   TAI timestamp - the number of microseconds between the current TAI time and
#                   UTC 1970-01-01T00:00:00.
#
#   GPS timestamp - relates to the TAI timestamp as follows: GPS = TAI - 19 secs.
#
#   UTC timestamp - the number of microseconds between the current UTC time and
#                   UTC 1970-01-01T00:00:00.
#                   Relates to the TAI timestamp as follows: UTC = TAI - leap_seconds.
#
#   Leap seconds  - accumulated one-second adjustments applied to UTC in reference to TAI.
#                   For reference, on May 2017, the number of leap seconds was equal 37.
#                   Refer to https://en.wikipedia.org/wiki/Leap_second for a general overview.
#                   The number of leap seconds must be accurate. If this cannot be garanteed, 
#                   a value of zero must be used, and the field num_leap_seconds must be set
#                   to NUM_LEAP_SECONDS_UNKNOWN.
#
uavcan.Timestamp gnss_timestamp
 
#
# Method used for deriving the GNSS timestamp field.
#
uint3 GNSS_TIME_STANDARD_NONE = 0  # Time is unknown
uint3 GNSS_TIME_STANDARD_TAI  = 1
uint3 GNSS_TIME_STANDARD_UTC  = 2
uint3 GNSS_TIME_STANDARD_GPS  = 3
uint3 gnss_time_standard

#
# Accumulated one-second adjustments applied to UTC in reference to TAI.
# The number must agree with the currently correct number of UTC leap seconds. If this cannot
# be garanteed, the field must be set to NUM_LEAP_SECONDS_UNKNOWN.
#
uint8 NUM_LEAP_SECONDS_UNKNOWN = 0
uint8 num_leap_seconds

It might be helpful to also add a formula for how to derive the GPS time stamp from gps week and gps TOW

[pavel-kirienko]

Thanks Olli, the definition has been updated again.

Note that I chose to not change the definition of leap seconds from the currently established one to your proposed TAI - UTC, because that would break the existing nodes. There is not enough benefit to be gained from that change to accept this.

Please review the updated definitions and let me know what you think.

[olliw42]

Hey Pavel

I'm fine with keeping the previous definition of leap seconds, one should certainly not break code, I missed that implication.

As regards the other suggestions, I did the reshuffling however on purpose. I consider it most unfortunate, and somewhat weird, that those time bases which are unaffected by the leap seconds have leap seconds in their definition, while those that is affected does not. I know, it subtracts out, but that's nevertheless taking the most roundabout way. That's why I streamlined that, making the situation, and the impact of the field leap seconds, clear at one glimpse. So, I would continue to vote for that rearrangement of equations.

:)

[pavel-kirienko]

That makes sense. I have updated the definition to express GPS and UTC via TAI.

[olliw42]

ah, you want to have it in the same sequence as the enum :), that's fair. Btw, for a similar aesthetic feeling I've put the "Leap seconds - ..." text last, but that's really personal taste LOL.

More relevant, I've just noted this, which I missed before: In the time-stamp formulas one should use num_leap_seconds instead of leap_seconds, since this is what is used. I thus would also append the "Leap seconds - ..." text by a sentence such as "The number of leap seconds is taken from the field num_leap_seconds.".

Are there any comments by @glennib @WickedShell, or they are just happy?

[glennib]

I don't have any comments regarding this. I've moved away from the UAV-field for the time being. Thanks for updating me!

[pavel-kirienko]

Thanks everyone. @olliw42 your latest suggestions have been incorporated.