Solar Orbiter SWA coarse time issue
===================================
== Description
It appears that after last DPU reboot on 2020-20-27T03:09, SWA TM packets have an uncorrect coarse_time value.
The coarse_time is part of CCSDS H2 header, as an unsigned 32 bits value.
For some reasons, after the DPU reboot, the MSB of coarse_time was set to 1, that conducts to compute erroneous timestamps > 2088
Inside the SolarOrbiter MCS (Mission Control System) all TM packets in such case are detected, and their generation_time
are recomputed function of their storage time (depending on reception_time and OWLT)
So currently, when we make some EDDS TM requests with generation_time > 2020-10-27T03:09, we can miss some packets,
as there are timetagged with their storage_time, that can be on 2020-10-28 or 2020-10-30, depending on the pass when they were dumped to ground.
== Detection of such packets
We could make 2 TM requests for data dumped on 2020/10/28 and 2020/10/30 (last 2 passes).
First for storage_time in "2020-10-28T00:00/P1D":
* link:/documents/EDDS/EDDS_coarse_time_issue/20201028_000000_20201029_000000.swa-batch-tm.xml[]
And the same for storage_time in "2020-10-30T00:00/P1D":
* link:/documents/EDDS/EDDS_coarse_time_issue/20201030_000000_20201031_000000.swa-batch-tm.xml[]
We wrote a short script to parse these 2 files and try to detect and correct these uncorrect timetags.
See the corresponding script and logfiles :
* link:/documents/EDDS/EDDS_coarse_time_issue/check_MSB_issue.py[]
* link:/documents/EDDS/EDDS_coarse_time_issue/20201028_000000_20201029_000000.log[]
* link:/documents/EDDS/EDDS_coarse_time_issue/20201030_000000_20201031_000000.log[]
We could see, in XML TM report files, that those packets are already detected by MCS.
They have all a TimeQuality flag = "NA" raher than "GOOD" usually.
So it could be possible to recompute the erroneous generation_time, with a simple bitwise instruction :
coarse_time = coarse_time & 0x7FFFFFFF
