Uncomplete TM data on 2022/01/13
================================
== Introduction
On 2022/01/13, we used a new set of PAS configuration parameters.
We tried to improve PAS counting statistics, using K=2 sub-sampling per seconds.
The PAS configuration parameters for Normal mode samplings were set to:
* Full normal mode samplings
+
--
Each 100s (excepted during snapshots), PAS perform full sampling with 92 energies x 9 elevations x 11 CEMS with K=1
These samplings correspond to a TM packet with 92 x 9 x 11 = 9108 counters => 18216 bytes, before compression.
--
* 54 energies x 7 elevations x 11 CEMS with K=2
+
--
In this mode, PAS data are accumulated over K=2 sampling/s, but only transmitted once.
That generate a TM packet with a payload of 54 * 7 * 11 = 4158 int-16 counters => 8316 bytes
This packet is then compressed onboard, and sent to SSMM
--
In normal mode, each 300s, PAS enter in snapshot mode (9s duration):
- full sampling (90 x 9 x 11)
- 7 x K=4 sub-samplings (36 x 5 x 11)
- full sampling (90 x 9 x 11)
*We got another uncontroled DPU reboot at 07:06, during a snapshot period*
=== Problem found: uncomplete uncompressed TM data
We receive 6004 Normal mode packets on 2022/01/13, including 166 full-samplings.
After uncompressing on ground these TM packets, we could notice that:
* All full sampling TM packet were complete
+
--
we received for each FS uncompressd data with 18304 bytes, where only the first 18216 are useful (due to uncompression block size factor)
--
* 1985/6004 TM packets corresponding to K=2 samplings were uncomplete
+
--
After uncompression, we received only 8192/8316 bytes (at least 124 bytes missing)
--
That gives a ratio of 1985 / 6004 = 33% of uncomplete TM packets
We could keep trace of these missing packets in our L1 CDF files, by setting the CDF variable COMPRESSION value to 9,
rather than usual 0/1 value standing for False/True.
==== PAS 3D descriptors
A first plot for 00:00/08:00 show PAS data before DPU reboot.
You can look at the "COMPRESSED" panel (value 9 indicating uncomplete TM data)
image::documents/2022-01-13/20220113.data-descriptor.png[width="100%"]
==== Zoom
More details on compression problems
image::documents/2022-01-13/20220113.zoom.png[width="100%"]
=== PAS configuration
Here is an extract of TM that gives details on PAS configuration
----
APID ( 96, 6) TM (200,250) SEQ (00114,3) Size = 48 2022-01-13T00:00:13.683 : SWA_TM_PARAM_REPORT
0000 : 00 01 30 05 00 2A 00 00 00 00 00 04 00 00 5C 00
0016 : 00 00 00 00 09 00 00 01 00 00 01 00 00 00 00 00
0032 : 1A 00 00 36 00 00 01 00 00 07 00 00 02 00 00 01
Param ID = 3005 : StatNormParId (42 bytes)
Static.P1 = 0
Static.P2 = 4
Static.P3 = 92
Static.P4 = 0
Static.P5 = 9
Static.P6 = 1
Static.P7 = 1
Static.P8 = 0
Static.P9 = 26
Static.P10 = 54
Static.P11 = 1
Static.P12 = 7
Static.P13 = 2
Static.P14 = 1
----
=== Conclusion
It seems there is a problem with that 54 x 7 x 11 PAS configuration.
In 33% of cases, after uncompressing TM data, we couldn't receive the whole expected data.
This "uncomplete data" problem was already encountered, with other configuration parameters, from 2021/06/10 to 2021/06/23.
However, the problem in this case was during snapshot (or burst) full-samplings.
It seems there is a problem with some PAS configuration parameters
