Time correlation CHRIS WATSON ESAC

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

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.

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.

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.

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

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: 0.0625s / 0.0078s in burst RPW: 0.0625s (*)/ 0.0039s in burst (*) snapshots at higher freq. EPD: 1s / 1s (TBC) in burst SWA: 4s / 0.0156s 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

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