1. Time correlation
CHRIS WATSON
ESAC

2. Motivation Be aware of side-effects that can occur in-flight
We think one possible problem
And two non-issues

3. Basics Fundamentally SC operates according to OBT
Resides in the OBC. This is an counter, more than a clock. It drifts, it is not resynchronised in flight.
The OBT is distributed on-board, such that instruments, OBC and AOCS are synchronised relative to each other (to the precision of the SpW sync scheme, plus the internal sync precision of each instrument).
Fundamentally the ground operates in UTC
Time-correlation is about establishing the relationship Spacecraft-Ground (i.e. OBT to UTC)
Done by MOC, as described,
During passes
Taking account of one-way light time
Generally speaking the absolute drift rate of the clock (1E-6 typ. spec) isn’t a problem, it is the variation in this drift rate.

4. Basics part-2 Packet times
Are converted to UTC automatically (present in the SCOS-header)
“Embedded” times (e.g. if you have acquisition times inside the data-content of a packet) the instrument-team will need to do the conversion according to the time-correlation tables established by MOC.
For the special case of the low-latency pipelines located at SOC we said we (SOC) will do the conversion as part of the post-processing of the pipeline output.
TC times (the time that the TC will execute from the Spacecraft MTL)
Are converted to UTC->OBT at the MOC at the time of uplink to the Spacecraft
SOLO-HI: watch out for this maybe. All the SOC planning products will work in UTC. I wonder what your internal timeline runs in, if not OBT.

5. Implications on SGS
Everybody shall use the same correlation tables to ensure consistent time-stamping of science, HK etc.
Since Solar Orbiter has very long latencies, care shall be taken to apply the correlation relationship applicable for the OBT in question, and not simply the most recent correlation.
We can only use time-tags in filenames if we are sure that the time will never be updated.

6. Analogy PC clocks drift
Typically synchronised on a network using e.g. NTP
Different ways of doing the resynchronisation
Infrequent sync => few discontinuities with larger magnitude
Frequent synchronisation means more discontinuities but typically smaller magnitude
Some systems implement a “smoothing” of the way the resynchronisation is applied locally to try to minimise the impact of discontinuities
Analogy is imperfect
Onboard clock is never resynced. Equivalent action is the new time-correlation established on-ground.
We don’t “smooth” the application of a new correlation

7. Potential problem
Discontinuities observable in periodic sampling (in UTC)
We suppose, especially, that a discontinuity that changes the apparent sampling order is a problem. There are some high cadences on SOLO
MAG: s / s in burst
RPW: s (*)/ s in burst (*) snapshots at higher freq.
EPD: 1s / 1s (TBC) in burst
SWA: 4s / s in burst
EUI: 0.1 s in Discovery
If we maintain the error (between the fit and the actual observed) < 3 mS then presumably
Perhaps having the new synchronisation enter only at pre-determined times helps?
For frequency domain work, possible work-around is to work in OBT. This removes the discrete discontinuities, but retains the 1 ppm error on the frequency.
Point at which new correlation became applicable
UTC

8. Things thought to be non-problems
TM not perfectly aligned with corresponding TC
TC “upconverted” according to a correlation that (sometimes) predates the subsequent “downconversion” of TM
Instruments probably don’t produce TM-packets exactly at the OBT of the corresponding TC anyway
Delta of a few millisecs due to correlation changes seems completely acceptable
VSTP commanding
Possible delta of the correlation between pass where STP was uploaded and later pass where VSTP additions are inserted => slight relative misalignment of the commanding in OBT in the MTL.
Solution: 1 second (TBC) dead-time between STP commands and subsequently inserted VSTP commands