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.