2021/12/15 FSW 3.4.0. patch

We got some problem to receive some SWA_TM_FSW_STARTUP_REPORT TM packets.

These packets are available with 2 different definitions in latest MIB (MIB__20211215M34921PFMS001_SOL).

In the MIB pid.dat file, the 2 definitions are:

$ cat /DATA/SOLAR/MIB/latest/pid.dat | grep FSW
200     252     1542    0       0       58902   SWA_TM_FSW_STARTUP_REPORT               -1      16      Y               Y       0       N
200     252     1593    0       0       58194   SWA_TM_FSW_STARTUP_REPORT               -1      16      Y               Y       0       N

APID 1552 ⇒ PID,CATEG (96,6)

APID 1593 ⇒ PID,CATEG (99,6)

Data extracted from EDDS batch request, using generation_time

Running a batch request (TM report) with generation_time = "2021-12-15T00:00/2021-12-16T00:00"

$ python -m CCSDS 20211215_000000_20211216_000000.swa-batch-tm.bin  | grep FSW

APID( 99, 9) TM(200,252) #    0 Size =   120 2021-12-15T16:27:53.325       0 58194 SWA_TM_FSW_STARTUP_REPORT
APID( 99, 9) TM(200,252) #    0 Size =   120 2021-12-15T17:47:16.939       0 58194 SWA_TM_FSW_STARTUP_REPORT
APID( 99, 9) TM(200,252) #    0 Size =   120 2021-12-15T17:53:02.422       0 58194 SWA_TM_FSW_STARTUP_REPORT

Data extracted from batch request, using storage_time

Running a batch request (TM report) with storage_time = "2021-12-15T12:00/2021-12-16T00:00"

$ python -m CCSDS 20211215_120000_20211216_000000.storage-time.bin | grep FSW

APID( 99, 9) TM(200,252) #    0 Size =   120 2021-12-15T16:27:53.325       0 58194 SWA_TM_FSW_STARTUP_REPORT
APID( 99, 9) TM(200,252) #    0 Size =   120 2021-12-15T17:47:16.939       0 58194 SWA_TM_FSW_STARTUP_REPORT
APID( 99, 9) TM(200,252) #    0 Size =   120 2021-12-15T17:53:02.422       0 58194 SWA_TM_FSW_STARTUP_REPORT

Using storage_time rather than generation_time can allow to recover some TM packet that have an uncomplete generation_time.

Problem identified (MSbit issue) due to onboard time synchronisation problem.

Data received from stream on 2021-12-15

Running a stream request StreamRequest.PktTmStream.SOL.0.2021.349.15.45.40.369.dMTW

$ python -m CCSDS StreamRequest.PktTmStream.SOL.0.2021.349.15.45.40.369.dMTW.chunk01.hex | grep FSW

APID( 96, 6) TM(200,252) #    0 Size =   120 2021-12-15T16:22:06.662       0 58902 SWA_TM_FSW_STARTUP_REPORT
APID( 99, 9) TM(200,252) #    0 Size =   120 2021-12-15T16:27:53.325       0 58194 SWA_TM_FSW_STARTUP_REPORT
APID( 99, 9) TM(200,252) #    0 Size =   120 2021-12-15T17:47:16.939       0 58194 SWA_TM_FSW_STARTUP_REPORT
APID( 99, 9) TM(200,252) #    0 Size =   120 2021-12-15T17:53:02.422       0 58194 SWA_TM_FSW_STARTUP_REPORT
APID( 96, 6) TM(200,252) #    0 Size =   120 2021-12-15T18:01:52.219       0 58902 SWA_TM_FSW_STARTUP_REPORT

We could receive 2 packets (96,6) that are no more available from EDDS batch requests.

Conclusion

It seems that SWA_TM_FSW_STARTUP_REPORT packets for APID 1542 or (96,6) were received in real-time from EDDS stream request, while there are no more available in batch request (using both storage_time or generation_time).