Timeline for How are Spacecraft Event Times (SETs) managed; to what timescales are they linked?
Current License: CC BY-SA 4.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 25, 2021 at 16:40 | comment | added | Mefitico | @honeste_vivere : For "mission data", such as payload measurements, to each their timing requirement, and thus for each the chosen time base, no obligation to use UTC there in general. As you've noted, I'm mostly talking about housekeeping and ground controller commands. | |
| Feb 25, 2021 at 16:09 | comment | added | honeste_vivere | Lots of spacecraft measurements require nanosecond precision and the time stamps associated with measurements are rarely given in UTC from the spacecraft. They usually are given in some sort of tick relative to a frame or a "known" time stamp from the spacecraft clock. Sometimes the instrument has its own time stamp system (e.g., Ulysses used UR8 times) which the user is left to convert the times to something like UTC. SC house keeping stuff, I agree, usually doesn't require nanosecond precision. | |
| Feb 25, 2021 at 16:05 | comment | added | Mefitico | @honeste_vivere : Satellite tasking should normally not require a precision of nanoseconds. I'd guess no operations in the onboard software would require a full time-stamp accurate like this. But another practice I've seen is to use different variables for counting integer seconds and sub-second time (and here, I've mostly seen milliseconds, not nano). Unix time in spacecraft is novelty, It mostly been done with low-cost satellites until recently and not so long ago was a prohibitively bad idea to use a linux OS in a spacecraft computer. | |
| Feb 25, 2021 at 15:59 | history | edited | Mefitico | CC BY-SA 4.0 |
added 7 characters in body
|
| Feb 24, 2021 at 14:18 | comment | added | honeste_vivere | The use of UTC is politically motivated, not practically motivated. UTC is a nightmarish time system (e.g., try converting to Unix or TAI times and be accurate to nanoseconds). | |
| Mar 27, 2020 at 20:55 | vote | accept | uhoh | ||
| S Mar 2, 2020 at 23:58 | history | suggested | Martin Schröder | CC BY-SA 4.0 |
fix markup
|
| Mar 2, 2020 at 23:49 | review | Suggested edits | |||
| S Mar 2, 2020 at 23:58 | |||||
| Mar 2, 2020 at 22:08 | comment | added | Mefitico | @uhoh : There are pretty good answers in the question you've mentioned. I know people who work in launch sites, and maybe I'll ask them about it. But notice that Kourou only makes around 12 launches per year, normally during the day so avoiding a leap second window is easy (just don't pick the wrong card in a deck of 182, so actually it is hard to bump into it). And in all honesty, I'd totally vote on favor of never launching on leap second addition day. | |
| Mar 2, 2020 at 21:44 | comment | added | uhoh | @Mefitico excellent, I always appreciate your answers, thanks! And since you mentioned the hassle of discontinuous time; How do launches avoid leap seconds? Why? | |
| Mar 2, 2020 at 20:04 | comment | added | Mefitico | @JanDorniak : I don't know enough about linux to answer your comment. But I think it may also depend on which linux distro you chose. | |
| Mar 2, 2020 at 19:43 | comment | added | jaskij | Isn't point two basically how Linux handles wall time? Grab the motherboard RTC on boot and add the time since boot to that for wall clock later on? That's simplified of course. | |
| Mar 2, 2020 at 18:58 | history | edited | Mefitico | CC BY-SA 4.0 |
added 91 characters in body
|
| Mar 2, 2020 at 18:35 | history | answered | Mefitico | CC BY-SA 4.0 |