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?
Or more simply, how accurate are the satellite's GPS week and millisecond values? > 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? > 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. > 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? 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.) On the other hand, if your "plethora of PCs" keep good time (via NTP or SNTP), and you don't care to better than a second (which your current 18s offset suggests might be the case), and there are no after-the-fact use cases, do you need anything other than a procedural rule about avoiding such activities at the end of June and December? That is, put your effort into making your NTP installation as reliable as possible. Rob Seaman, University of Arizona _______________________________________________ LEAPSECS mailing list [email protected] https://pairlist6.pair.net/mailman/listinfo/leapsecs
