UCAnFly .- CSP with Small Fragmentation Protocol errors

[MembrilloAmarillo]

Hello everyone,

We are developing a cubesat and using gr satellites for the gnu radio v3.10. We are using GOMSPACE AX100 transceiver and for the GS testing a adalm pluto sdr and the gnu radio mentioned above. In this case, we are using the CSP (cubesat space protocol) to establish connection between the transceiver and our GS. We successfully make ping commands to the transceiver but anything else apart from that gives us errors (time out, and I/O error, mostly). Now to add actual information about the gnu radio flow:

That is for TX from the ground station, modulation is meant to mean GMSK Modulation. For RX from the ground station we would use the symmetrical blocks.

Given that setup (please ask us if you need any more information about the flow we use) we can successfully ping the transceiver or the on board computer. However when trying to command some data download that cannot be stored in a single CSP Packet it activates the Small Fragmentation Protocol which sadly fails every time displaying an error, "csp: SFP missing X bytes".
We are wondering if maybe the problem comes from not having into account something that the gnu radio blocks needs in order to satisfy said communication.

We are a bit lost on why this could happen, we tried to send the same commands through CAN and KISS and there where no problems, so we kind of discarded that it is a problem outside the gnu radio configuration. We also tried changing and simplifying the blocks and processes we had but it ended up in not even having successful pings to the transceiver.
We would very much appreciate your help, thank you in advance.

//////////////////////////////////////////////////////////////////////
The first PDU is our command and the other three are the response, which ended up giving the error SFP missing X bytes

***** VERBOSE PDU DEBUG PRINT ******
((lenght_tag . 19))
pdu length =         22 bytes
pdu vector contents =
0000: 54 51 fe 01 44 00 00 00 0b b0 00 00 00 00 53 2d
0010: e2 63 12 5c fc 74
************************************
Ucrc_check :info: CRC OK
***** VERBOSE PDU DEBUG PRINT ******
((rs_errors . 0))
pdu length =        201 bytes
pdu vector contents =
0000: 0a 11 87 af 4a 00 00 04 01 00 00 72 73 73 69 5f
0010: 6f 66 66 73 65 74 00 00 00 00 02 05 02 00 00 6d
0020: 61 78 5f 74 65 6d 70 00 00 00 00 00 00 00 04 0d
0030: 04 00 00 62 67 6e 64 72 73 73 69 5f 65 6d 61 00
0040: 00 00 08 00 01 00 00 63 73 70 5f 6e 6f 64 65 00
0050: 00 00 00 00 00 00 09 10 01 00 00 69 32 63 5f 65
0060: 6e 00 00 00 00 00 00 00 00 00 0b 10 01 00 00 63
0070: 61 6e 5f 65 6e 00 00 00 00 00 00 00 00 00 0c 10
0080: 01 00 00 65 78 74 70 74 74 5f 65 6e 00 00 00 00
0090: 00 00 0d 10 01 00 00 6c 65 64 5f 65 6e 00 00 00
00a0: 00 00 00 00 00 00 0e 04 01 00 00 6b 69 73 73 5f
00b0: 75 73 61 72 74 00 00 00 00 00 00 00 00 00 00 01
00c0: b8 16 04 70 a3 3c 8b cd d6
************************************
Ucrc_check :info: CRC OK
***** VERBOSE PDU DEBUG PRINT ******
((rs_errors . 0))
pdu length =        201 bytes
pdu vector contents =
0000: 0a 11 87 af 4a 00 0f 04 01 00 00 67 6f 73 68 5f
0010: 75 73 61 72 74 00 00 00 00 00 10 00 01 00 00 69
0020: 32 63 5f 61 64 64 72 00 00 00 00 00 00 00 12 01
0030: 02 00 00 69 32 63 5f 6b 68 7a 00 00 00 00 00 00
0040: 00 00 14 01 02 00 00 63 61 6e 5f 6b 68 7a 00 00
0050: 00 00 00 00 00 00 18 01 02 00 00 72 65 62 6f 6f
0060: 74 5f 69 6e 00 00 00 00 00 00 1c 02 04 00 01 74
0070: 78 5f 69 6e 68 69 62 69 74 00 00 00 00 00 20 00
0080: 01 00 00 6c 6f 67 5f 73 74 6f 72 65 00 00 00 00
0090: 00 00 21 00 01 00 00 74 78 5f 70 77 72 00 00 00
00a0: 00 00 00 00 00 00 2c 01 02 00 00 6d 61 78 5f 74
00b0: 78 5f 74 69 6d 65 00 00 00 00 00 00 b4 00 00 01
00c0: b8 62 65 9c 6a be 62 d8 e0
************************************
crc_check :info: CRC OK
***** VERBOSE PDU DEBUG PRINT ******
((rs_errors . 0))
pdu length =        101 bytes
pdu vector contents =
0000: 0a 11 87 af 4a 00 2e 01 02 00 00 6d 61 78 5f 69
0010: 64 6c 65 5f 74 69 6d 65 00 00 30 0e 60 00 00 63
0020: 73 70 5f 72 74 61 62 6c 65 00 00 00 00 00 90 10
0030: 01 00 00 6c 65 67 61 63 79 5f 68 6d 61 63 00 00
0040: 00 00 94 02 04 00 00 6b 69 73 73 5f 62 61 75 64
0050: 00 00 00 00 00 00 00 01 68 00 00 01 b8 5d 38 95
0060: a9 ed 2f 16 2e
************************************

[daniestevez]

However when trying to command some data download that cannot be stored in a single CSP Packet it activates the Small Fragmentation Protocol which sadly fails every time displaying an error, "csp: SFP missing X bytes".

What produces this error? I don't think this error comes from gr-satellites.

[JFSR00]

Hi!

I'm a project mate of @MembrilloAmarillo.

To isolate problems, I first tested communication between the TX and RX flowgraphs without the radio section, using TCP Sink and Source blocks. In this setup, digital frame encoding and decoding worked correctly. So the problems mentioned in this thread have been solved.

However, after adding the radio section using the PlutoSDR Sink and Source blocks, the communication between the flowgraphs no longer worked. To isolate the issue, I stored the modulated GMSK signal to a file (via a File Sink block) instead of transmitting it over the air, and then read it in the RX flowgraph using a File Source block. In this case, the demodulation and frame decoding were successful.

Despite not achieving communication between the flowgraphs using the PlutoSDR, I attempted to test communication with the AX100 transceiver, but—unsurprisingly—neither TX nor RX worked.

Since both directions failed, I focused on the RX side. I recorded several transmissions from the AX100 using the PlutoSDR, but none could be decoded. I repeated the test with an RTL-SDR RTL2832U, with similar results. Although I adjusted for the frequency offset on each device (as it was a bit different for each one), the outcome remained unchanged.

I attempted to debug the RX flowgraph by graphically inspecting the demodulated signal after quadrature demodulation. The signal from the AX100 appears to contain a significant amount of noise, but seems readable. For comparison, the demodulated wave from the GNU Radio TX flowgraph appears cleaner and closely resembles the AX100 signal, though with less noise.

I’m reaching out because I’m not sure whether the issue lies in incorrect parameter usage, a flaw in the flowgraph design, or a potential hardware problem.

For reference, the flowgraph design is heavily based on the OPS-SAT project, which also used the AX100 transceiver and the same protocols.

You can find the GR files into the attached ZIP file.

The ZIP file contains three flowgraphs. The first one is CF32_Read_test, which contains a flowgraph made to see the demodulated signal using a QT GUI Time Sink block. The other two are ZMQ_Test_TX and ZMQ_Test_RX, which are the final flowgraphs for each case, TX and RX.

Thanks in advance.

P.S.: While checking the AX.25 headers, you can find that the address used in the recordings may be different from the expected ones by the flowgraph.

grc_files.zip
ucanfly_transmissions.zip
grc_generated_transmissions.zip
opssat_transmission.zip

[daniestevez]

Just to say that I've read through your comment and that I the moment I don't have the time to support this detailed debugging in my spare time. However, I took a quick look at the first file in ucanfly_transmissions.zip and found that there are glitches, possibly caused by dropped samples, as evidenced by this Inspectrum screenshot.

[JFSR00]

Thanks for your answer!

How could I solve that problem? With a higher sample rate or may be caused by a hardware problem?

[JFSR00]

I have been doing more recordings, and found that there is a noise pattern at 58 Hz approximately. This noise shouldn't be a problem, as it has a level around -109 dB, but each time I transmit something generates this strong signal that can be seen in the picture you shared.

I even tried connecting the AX100 transceiver directly to the Pluto SDR, but the noise pattern could be barely seen. I isolated the transceiver from other electronics, and I used a low noise power supply. My laptop was using it's battery, and all the surrounding machines were off (at least in our laboratory), so I think I removed every possible noise source.

Yesterday I used an RTL-SDR instead of the Pluto SDR, and the noise seems to be uniform, but anyways there is some strong signals which breaks the package. By the way this strong signals seen in the RTL-SDR, doesn't seem to resemble any pattern, as seen with the Pluto SDR.

I add new samples that I took.

noise_2025_05_08_1553_transceiver_on.zip
noise_2025_05_08_1546_transceiver_off.zip
pluto_recv_2025_05_08_atenuator.zip
rtlsdr_recv_2025_05_07.zip

[JFSR00]

Hi @daniestevez,

After reducing the sample rate of the SDR, the artifacts disappeared, so I could demodulate without problems the signal.

Then I could fix some minor problems with the decoding, and everything started working.

Now I have a proper communication with the transceiver.

Thank you very much for your help. This discussion can be marked as solved.

Best regards.