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: