ERMINAZ: Add support for new framing

[kerel-fs]

The ERMINAZ team modified their downlink protocol to better follow the CCSDS standards.

FSK demodulation & Deframing

Changes (non-exhaustive list, I might be missing items):

• Fixed preamble
• Fixed syncword
• Flipped FEC & Scrambling
• Changed framing to "CCSDS TM Frames (128 octets including FEC) with encapsulated Space Packets of variable size (0 to 65535 octets)", see ERMINAZ Data Formats

A modified SatYAML (see #771) as well as an IQ recording was shared (285MB, recording_435775000Hz_20-43-13_20-09-2025.sigmf-data/meta / todo: add URLs to IQ files once published on a suitable webserver).

I was able to decode up to 684 Frames from this recording, with 47 / 5 / 2 / 2 lost frames identified by checking the master_channel_frame_count in the TM Transfer Frame Primary Header, using a relative clock recovery bandwidth of 0.06 (default) / 0.1 / 0.15 / 0.2. Given the high SNR of this recording, I would expect no frame loss at all, so something still seems slightly off.

To investigate further, I created SigMF annotations based on the timestamps in the output KISS file. This allows us to identify with inspectrum when frames are not decoded. One of those missing frames begins at t=44.73 s:

The previous and following frames are decoded, only this single frame is missing. I dumped & plotted some internal signals for this segment:

Dumped internal signals

For me there is no obvious hint to any error in those graphs, except maybe a slightly higher peak at the beginning of the second frame around 44.76 s in clock_recovery_T_avg.

Which next steps could be followed to investigate the root cause for those lost frames?

---

SSDV decoder

Off-Topic: Packet Extraction / SSDV decoder

The SSDV packets (now 256 bytes) are transmitted in Space Packets (APID: 500) inside a virtual channel (VCID 1). According to CCSDS TM SDLP, after virtual channel demultiplexing some "virtual channel reception function" should extract packets from the Data Field of Transfer Frames. I have implemented this function in two small Python classes `VirtualChannelReceiver` with a `receive_frame` method and a `PacketExtractionHandler` class with `work(octets)` and `reset()`.

I'll open a separate issue in the future to track the upstreaming efforts regarding topic to keep this issue well-scoped.

Helper Tools

Off-Topic: Helper Tools

PS: I've written or extended the following small helper tools while investigating this issue: * `kiss_info` - Display information of a given KISS file, e.g. number of frames, maximum frame length. * `kiss2sigmf` - Generate SigMF annotations from timestamps in KISS files. Requires some manual tuning (provide time offset, frame duration and bandwidth). * `waveform_plot` - Plot the internal signals dumped by gr-satellites at a given selection (elapsed time and start and duration)).

Is there an interest to add such tools to gr-satellites too?

[daniestevez]

Which next steps could be followed to investigate the root cause for those lost frames?

The clock recovery output looks pretty bad. There are probably some bit errors, and the SNR seems high enough that there shouldn't be any.

The way to debug decoding thoroughly is to go through each of the decoding chain steps for the frames that fail and check where things go wrong. For instance:

• What are the soft symbols for this particular frame? Are there bit errors?
• What is FEC decoding doing? Is it correcting all the errors?
• Are there any other problems, such as the frame boundaries not being detected correctly or the frame not being to spec?

[daniestevez]

Is there an interest to add such tools to gr-satellites too?

Definitely it possible to put these scripts into tools/. This is where waveform_ploy.py currently is. There is no possible harm by putting things there, since they can only be run manually by someone who has a checkout of the repository.

There is also apps/, but there is more friction for adding things there. They get installed to the $PATH when gr-satellites is installed (either with make install or by installing something like a Debian or Conda package). Therefore they need to have manpages (this is a Debian requirement), have globally unique names that make sense as UNIX command names, and generally have the kind of interface and polish that one would expect from command line tools that get installed system-wide.

Additionally, dependencies of things in apps/ become dependencies of gr-satellites, so we need to be somewhat careful about what dependencies to add. For a script in tools/ it's probably okay if it depends on something else.