mmecina
commented
4 months ago The error seems to occur because of how the PUS timestamp format is defined in packet_config_COMETINTERCEPTOR.py:
timepack = [ptt(9, 17), 6, 2**16, 0]
In its current version CCS can properly handle only time parameters (i.e. those with PTC=9 in the MIB) which are of the same PTC/PFC type as defined in that line. As the HK parameters in question are CUC918 (vs CUC917 in the packet_config) the condition that usually catches time parameters does not apply and the else clause is entered which subsequently fails due to the illegal format string:
To solve the present problem, I would propose changing the definition of timepack to timepack = [ptt(9, 18), 7, 2**16, 0] to be consistent with the time parameters used in the CoCa project (this won't affect the timestamp in the PUS header).
For compatibility, the timecal function has to be redefined as well - it must handle the exact number of bytes present in the packet payload for the corresponding CUC type (7 for CUC918 parameters) as input. In particular coarse and fine time must be modified to:
coarse = data >> 24
fine = ((data >> 8) & 0xffff) / timepack[2]Moreover, in https://github.com/mmecina/CCS/blob/5f286b495b25f936edd9bdaee8826c18ab797626/Ccs/packet_config_COMETINTERCEPTOR.py#L145 an additional byte needs to be added:
return ctime.to_bytes(4, 'big') + ftime.to_bytes(2, 'big') + b'\x00'
This is used when TCs containing time parameters are created.
Finally, on a general note, this issue shows that implementing a time parameter decoding scheme that is independent of the particular PUS timestamp definition should be considered.
pasetti
In the poolviewer, I can see HK packets being correctly displayed in raw format but, when I try to decode them, I get the error:
Packet data decoding failed: CUC918. Debugging indicates that the error is an exception arising at line 1055:The exception seems to be triggered by the 'CUC918' format in `fmts'. The full content of 'fmts' is:
['H', 'B', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'uint1', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'CUC918', 'B', 'H', 'H', 'CUC918', 'B', 'H', 'H', 'CUC918', 'B', 'H', 'H', 'CUC918', 'B', 'H', 'CUC918', 'B', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'I', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'B', 'B', 'B', 'B', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'H', 'CUC918', 'B', 'I', 'H', 'H', 'H', 'I', 'I', 'CUC918', 'B']If needed, I can provide the full tmpool by e-mail.
The problem seems to be that the 'CUC918' format is not recognized. This format is intended to represent an absolute time made up of 4 bytes for the coarse time and 3 bytes for the fine time. There are indeed several parameters in my HK packets which are of this type.
What can I do to get rid of the error?