How to parse TC acknowledgements
================================
== Get the SWA TCs for a given date
First, make a batch TC request for a given date, with XML output format
That correspond to EDDS batch TC report, with PID in range [95,99] and a daily time range
PID range [95,99] corresponds to APID in range [1520, 1599]
Typically, all SWA TCs corresponds to PID, CATEG = 95,12 => APID 1532
----
$ python EDDS.py batch_TC 2022-01-04T00:00 P1D
----
Returns an .xml file :
----
20220104_000000_20220105_000000.swa-batch-tc.xml
----
This XML can be converted in various output formats
We are using a dedicated python script :
----
$ python -m batch_TC 20220104_000000_20220105_000000.swa-batch-tc.xml
Writing : 20220104_000000_20220105_000000.swa-batch-tc.txt
Writing : 20220104_000000_20220105_000000.swa-batch-tc.hex
Writing : 20220104_000000_20220105_000000.swa-batch-tc.bin
----
* Text file
Extract from XML the ReleaseTime, ExecutionTime, SequenceName, CommandName, Description
----
20220104_000000_20220105_000000.swa-batch-tc.txt
----
It corresponds to "SWA preloaded TCs" on our web site.
See http://solarorbiter.irap.omp.eu/tests/aux/20220104/SWA_TC.preload.txt[]
* CCSDS hexadecimal format
Extract the RawBodyData field from XML.
It's a sequence of CCSDS TCs, in hexadecimal format, one per line.
To be used as input as input of our L1 data processing software
----
20220104_000000_20220105_000000.swa-batch-tc.hex
----
* CCSDS binary data
Same content than hexadecimal file, but in binary format.
----
20220104_000000_20220105_000000.swa-batch-tc.bin
----
Our data processing chain can handle both hexadecmal files (when parsing stream data) or binary files (batch requests data)
=== Parse the TCs CCSDS packets
As mentionned, TCs CCSDS packets have no internal timetags.
So the CCSDS header for those packet is shorter than TM ones:
* a primary header (6 bytes) gives the (PIDi, CATEG) => APID = 1532 for SWA, the sequence counter for such APID, and the CCSDS packet length
* a secondary header (4 bytes) gives the service_type and sub_stype
* the remaining part contains the various parameters sent to the TC (length varying for each TC)
[NOTE]
====
The 4 first bytes of each CCSDS TC packet will be used later as a key to identify the TC
For each TC, the 4 first bytes are enough to extract the apid and sequence_counter, that are unique since the last reboot.
====
=== Identitying the TCs
All TCs for SWA are sent with APID = 1532.
Then service_type and sub_service are used to idenfity the various TCs used by SWA.
The TCs can be uniquely identified with the key (apid, service_type, sub_type) in the MIB file ccf.dat (Command Characteristic File)
In the example, the TC ZIA58064 : SWA_TC_PARS_MON_DIS is identified with 200, 171, 1532 (service_type, sub_service, apid)
----
$ cat /DATA/SOLAR/MIB/latest/ccf.dat | grep ZIA58064
ZIA58064 SWA_TC_PARS_MON_DIS SWA TC disable the monitoring of parameters N NOM_TC 200 171 1532 2 N Y N C 109 N 9 109
----
== Parsing TC acknowledgements
As mentionned before, the CCSDS TC packets have no timetag information.
In order to known when a TC is executed onboard, we have to parse various TM CCSDS packets called TAR[SF] and TEC[SF].
* TAR means Telecommand Acceptation Request : when the TC is received by DPU
* TEC means Telecommand Execution Completion : when the TC execution is completed
For each one, S means Success and F Failure
* TARS : corresponds to service (1,1)
* TARF : corresponds to service (1,2)
* TECS : corresponds to service (1,7)
* TECF : corresponds to service (1,8)
Both TAR[SF] and TEC[SF] data contains a 4 bytes key that must be used to identify the TC that is acknowledged.
That key correspond to the 4 first bytes of a CCSDS TC header, that contains apid = 1532 and increasing sequence_count.
By parsing the TAR[SF] and TEC[SF] and their corresponding timetag, we can know when a TC has been received or executed, and if it was succesful or not.
When receiving TARF and TECF, we can also parse the data content of CCSDS payload to have some error code and explanation of the failure.
