On 1/15/19 6:34 PM, Rob Seaman wrote:
Hi Jim,
The use case is this - I have a satellite in orbit which does
everything internally in terms of GPS week and millisecond of week.
Folks on the ground work in UTC, since that's what the plethora of PCs
are using.
Just to verify. The satellite does use GPS as its reference clock, not
some manual upload (in a similar way as you describe) from ground
stations? The routines you're talking about aren't (directly) affecting
the state of the clock on the spacecraft?
Ground processing only - for user convenience
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.
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)
Sometimes cross checked for consistency by, say, the page at
http://leapsecond.com/java/gpsclock.htm
It would be much easier for the operators if they could just *enter*
the UTC time, and have the software calculate the GPS Week:millisecond
(or vice versa)
Leap Seconds, should they occur, would be handled by "don't do
anything around or across the leap second".
Or could you simply forbid activities during a few hours of June 30 /
December 31? If the operators are at JPL this would be late afternoon on
whatever day of the week. That is, just assume there's always a leap
second at each opportunity.
As it happens the ops aren't at JPL for this spacecraft.
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"
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.
And, we could rebaseline the conversion
i.e. the calculation would be
SecondsAfterBaseDate = Seconds(UserEnteredDate) - Seconds(BaseDate)
DesiredTime = Seconds(6 Jan 1980) + SecondsAfterBaseDate
GPSWeek = Floor(DesiredTime/(86400*7))
GPSMilliseconds = (DesiredTime - GPSWeek*86400*7) * 1000
Which works quite nicely as long as the interval between BaseDate and
UserEnteredDate does not include a leap second.
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".
Note that if your use cases include retroactive requirements then even
if leap seconds cease you will need to maintain the leap seconds table
(perhaps compiled into the source through some date). (For leap second
warriors, redefining UTC makes it more complicated, not less, when all
use cases are considered.)
Not really - for those kinds of use cases there's already issues and
solutions with reconciling local observations of clocks against outside
time scales.
the "don't operate during the leap" and "keep track" work just fine.
_______________________________________________
LEAPSECS mailing list
LEAPSECS@leapsecond.com
https://pairlist6.pair.net/mailman/listinfo/leapsecs
