Bug PAS compressed snapshots
============================
== Reminder
PAS 3D compressed snapshot are composed of a sequence of TM packets with SID = 202, 203, 204 :
* SID = 202 : +
give number of PAS snapshots saamples
* SID = 203 : +
PAS 3D data descriptor (nb_energy x nb_elevation x nb_cem x nb_K) +
=> used to compute 3D umpcompressed data original size
* SID = 204 : +
contains the compressed data
Normally, we must start with a SID 202 packet giving number of samples (typically 9)
Then a sequence of 9 snapshot that can be composed of:
- One SID 203 desciptor followed by unique SID 204 compressed data
- One SID 202 descripor folowwed by a sequence of SID = 204 compressed data
To hold that possible sequence of SID 204, we should have to use the CCSDS sequence_flag (SF) with:
* SF = 3 : in case of unsegmenteg data (unique packet)
* SF = 1 : first of sequence
* SF = 0 : continuation packet(s)
* SF = 2 : last of sequence
Typically we should find for SID = 204 :
* SF = [3] +
if unique packet
* SF = [1, 2] +
if 2 compressed data packets
* SF = [1, 0, 0, ....., 2] +
if more than 2 packets
=== Problem in DPU software with compressed products
These scheme works for PAS uncompressed products, but due to a problem in DPU software (I think we already discussed in the past with Gennaro),
for PAS 3D compressed products (and probably also for HIS and EAS ones) all SID = 204 packet have SF = 3.
So, it's not clearly possible to identify if those SID = 204 packets are unique, of part of a sequence.
=== Bug in PAS software
Previously, when receiving such packets, I was concantenating compressed data payload in an unique buffer,
and when finding the last packet (SF = 2 or 3), uncompressing the final buffer.
I had a test like:
----
if (packet.seq_flag == 2 || packet.seq_flag == 3) {
// uncompress buffer
// write CDF record
}
----
Trying to hold this SF=3 problem, I made some tries, and suppressed the previous test, trying to concatenate compressed data from a sequence of SID 204 packets and uncompressing
the final buffer.
However, I introduced a new bug : when receiving a sequence like [203, 204, 204]
* 203 : parsing data descriptor and allocating a buffer to hold final uncompressed data
* first 204 packet: copy compressed data in final buffer, uncompress from this buffer and put result in same buffer
* second 204 packet:
