[LEAPSECS] leapseconds, converting between GPS time (week, second) and UTC

[Rob Seaman]

On 1/15/19 9:14 PM, jimlux wrote:

> Ground processing only - for user convenience

I see somebody else mentioned SPICE, which I assumed you knew all about.


>>
>> Or more simply, how accurate are the satellite's GPS week and
>> millisecond values?
>
> Time is set by the messages from the OEM-6xx series GPS receiver and
> its 1pps - It's GPS time, not UTC.
>
> if there's a GPS outage, time propagates forward on the onboard
> oscillator which isn't great.  When GPS resumes, time jumps.

Copacetic. Just like holdover specs on rackmount units.


>>> We want to synchronize an event on the ground with an event on the
>>> spacecraft, so, given that someone on the ground is going to do
>>> something on 21 January 2019 at 12:34:56Z, we need to be able to
>>> command the spacecraft to do that at the corresponding Week:Second.
>>>
>>> Right now, they use a website
>>>
>>> For example: https://www.labsat.co.uk/index.php/en/gps-time-calculator
>>>
>>> which, by the way, doesn't use leap seconds, so it's off by some 18
>>> seconds
>>>
>> Do they ignore the 18 seconds? What precision is required for this
>> application?
>
> I think the folks at the labsat website just coded a naive
> implementation.
>
>
> For this application, <1 second uncertainty is needed (technically,
> one can set events to occur to within 1 microsecond, but that's
> counted down from the 1pps using the internal clock, with the
> "correct" 1pps done by knowing it's week:second)

Ok, so you set a trigger onboard and want to synchronize a state change
at the ground station to some tolerance significantly under a second? If
those are PC clocks their native imprecision will presumably leave a
significant likelihood of ending up in the wrong second whatever the
software does, but you should be able to minimize this relative to
current practice.

Do you have an example use case for what the operators might be doing
that requires synchronization? How bad is it to be off by one or more
seconds at one end or the other? Is this something like resetting both
ends of a telemetry channel to different frequency or bit rate or some such?


> And that's exactly how we can deal with it - it's perfectly reasonable
> to say "folks, there's a leap second a'coming, run for the hills til
> it gets here"
Or even, "there might be a leap second, take a coffee break" since these
can only happen twice a year. Or lockout such commands for the first and
last UTC hour of each month if you want to be really sure without having
to keep track of the file. This assumes your NTP installation will
handle leap seconds correctly. We rely on Meinberg to get it right for
us via both NTP and IRIG. (Same would apply to PTP.)
>
> For spacecraft flying via JPL ops, we work in TAI (or also, MET -
> Mission Elapsed Time or SCLK - spacecraft clock), since all the nav is
> done that way.. we also have to deal with relativistic effects and
> light time - the whole "what do you do with time" on that scale has
> seen 40 years of development.

Right. The presumption is that JPL will get it right :-) Mostly we're
interested in hearing about your cool systems.


>> This conversion is so simple it seems unnecessary to rely on somebody
>> else's library. What you might need is to arrange for a local, reliable,
>> vetted copy of the leap seconds table. So perhaps folks here could
>> comment on their best practices for retrieving same in an operational
>> environment?
>
> or just set up an operational procedure that defines some file or
> something under configuration control that has the "GPS time" and the
> "Week:seconds" for the same time that is "after the last leap second".

I think this is operationally equivalent. There is an operational
advantage in leveraging the standard file.

ROb