CRC and FEC for PEGASUS (QB50, AT03) demodulated beacons

[OE3ALA]

Hello together,

as part of my Master thesis I am working on the implementation of an UHF and S-Band ground station using SatNOGS + PlutoSDR for our PEGASUS satellite (UHF) at the University of Applied Sciences Wiener Neustadt. In the future this ground station should serve for our new satellite CLIMB (UHF, S-Band).

A research question of my thesis is to compare the "quality" of demodulated beacons using software (SatNOGS + PlutoSDR) and hardware (Space Tech Group Austria STACIE). As a measure of quality the CRC and FEC will be used for comparison. These error checks are part of the PEGASUS beacons.

Unfortunately, the CRC and FEC are not part of the demodulated beacons uploaded to the SatNOGS Network. Exists there a possibility to implement these error checks into gr-satellites for PEGASUS?

I am not not a software engineer and first time digging into SatNOGS. Therefore, I would appreciate any help. :)

Many thanks!

Cheers,
Alex, oe3ala

PEGASUS specific information

CRC

• CRC16
• Operation of the CRC (PHP code)

function crc_calc($data, $length)
{
 $checksum = 0;
 
# while ($length > 0)
 for ($i = 0; $i < $length; $i++)
 {
 $checksum = crc_update($data[$i], $checksum);
 }
 return $checksum;
}

function crc_update($data, $checksum)
{
 $checksum = $checksum ^ ord($data);
 for ($i= 0; $i < 8; $i++) {
 if ($checksum & 1) {
 $checksum = ($checksum >> 1) ^ 0xA001;
 }
 else {
 $checksum = ($checksum >> 1);
 }
 }
 return($checksum);
}

FEC

• Reed Solomon (n=64, k=48)
• Generator-polynominal-coefficients: 79 44 81 100 49 183 56 17 232 187 126 104 31 103 52 118

Manual for Radio Amateurs

• Link to PDF document
• GFSK9k6 modulation
• TT-64 framing

Useful links I have found

• PEGASUS Decoder
• Forum Discussion about PEGASUS decoder, framing, ...

[daniestevez]

Hello @OE3ALA, thanks for getting in touch.

I've moved this to a discussion under the "Satellite Teams" category, as it fits better here.

gr-satellites supports PEGASUS by using the TT-64 deframer. This supports checking the CRC-16ARC by using the check_tt64_crc block (now that I see this code again I realize that it should be ported to use the new CRC Check block, but that's another story). As such, the frames output by gr-satellites are only those with correct CRC. I don't know what other decoders can submit PEGASUS frames to SatNOGS DB, but I guess that's the case for all of them. They would drop frames with bad CRC.

Second, a comment on the approach of your project. Probably it's not so good idea to do a comparison of correct CRCs versus wrong CRCs output by a particular decoder. Depending on the threshold and mechanism used for syncword detection, a certain decoder might produce more false frame detections. That is okay, because all those are rejected by wrong CRC (increasing the wrong CRC count), so the only drawback is increased processing, but we raise the sensitivity somewhat by doing this. Also, a CRC-16 is somewhat too weak (it is prone to some false frames getting through with a good CRC just by random chance), so I wouldn't trust it for this kind of study. What in my opinion makes sense to compare decoders is, under the same conditions, to count the number of successfully decoded frames, where we determine if a frame is successfully decoded by looking at whether all of its contents are correct, not just by checking a CRC-16 (if you stuff a CRC-32 into the frame payload that might be an effective and cleveer way of "cheating" to simplify the problem of checking all the frame).

[daniestevez]

Is it also possible to have the FEC not striped from the PDU?

You can either skip the Reed-Solomon decoder (in the same way you've done with the CRC), or modify the Reed-Solomon decoder to also output the parity check bytes (somewhere around here).

(This is the second file in this folder, there already exists one called grc.conf with some settings. Should I add it there?)

That's correct. In principle it should work. No need to install GNU Radio again, though the setting only applies to processes you've launched after doing the change.

[OE3ALA]

I already tried to skip the Reed-Solomon decoder by

• Deleting Line 49
• Changing Line 53 to self.msg_connect((self.deframer, 'out'), (self, 'out')) (Line 54 and 55 were already deleted from skipping the CRC decoder.)

Changing this I have ended up in getting up to 1500 packages decoded per observation, e.g. you can see it here. Normally, there are around 0 to 20 beacons per observation. Even for the sample recording I have ended up getting 6 decoded packages, but there is only one real signal in it. This signal was decoded sucessfully with the CRC and FEC attached to it, beside 5 more packages with none useable data.

Is this behaviour expected, when I skip the RS decoder?

Maybe it is the better solution to modify the decoder in order to just print the parity check bytes. Looking at the code, we were not quite sure on how to change it correctly. Maybe any fast solution for it? I do not want to consume to much time from you. :)

Many thanks!

[daniestevez]

Yes. This is expected. I already mentioned this initially:

Probably it's not so good idea to do a comparison of correct CRCs versus wrong CRCs output by a particular decoder. Depending on the threshold and mechanism used for syncword detection, a certain decoder might produce more false frame detections. That is okay, because all those are rejected by wrong CRC (increasing the wrong CRC count), so the only drawback is increased processing, but we raise the sensitivity somewhat by doing this.

Here not only the CRC check, but also Reed-Solomon decoder failures contribute to filter out false syncword detections. You can reduce the number of false syncword detections by reducing the --syncword_threshold parameter, but by doing so you're making the decoder less sensitive too.

Can you be more precise about what you intend to implement? Do you want to throw away frames that fail Reed-Solomon decoding or not? Do you want to print the parity check bytes after decoding (those can be computed from the frame contents at any time) or before decoding, where there are potentially byte errors in them (in that case it would also be good to print the rest of the frame before decoding, since it has potentially byte errors too?)?

As I first mentioned, I don't see how any of this contributes to your initial goal of testing the sensitivity of different decoders.

[OE3ALA]

Hi Daniel, again thank you very much for your fast reply!

I didn't believe, that it is as extrem as it turned out. Therefore, the question if this behaviour is expected. It shows very strongly, that is not compareable in that way. A litte sidenote on how I am planing to compare the solutions. I am going to send beacons every 30 seconds with an original PEGASUS STACIE communication board, the signal is than received by an antenne with a splitter attached to it. The splitter splits this signal and tranfers it to the STACIE ground station (H/W) and to the PlutoSDR (S/W). During the test, different parameters are varied (db level, doppler shift, frequencie offset, ...) to evaluate the different limits of each system. The results should surve for optimization of the SDR solution and for a comparison of both solutions. Our hardware developer wants the CRC and FEC for there internal review, it is no longer planed to compare the solutions on this two parameters.

The STACIE demodulates/decodes the received signals using a hardware chip together with a RPi which uploads the beacons to a network. As an output I am getting already corrected beacons with the CRC and FEC attached to it, which looks like this (PID, CALL, DATA, CRC, FEC): 56 4F 4E 30 33 41 54 D7 52 FD 5D 00 00 00 00 00 00 00 00 00 00 06 01 00 D1 FF FF F7 FC CF F0 7F 80 74 00 00 00 00 00 00 68 68 00 00 04 00 37 DF D7 8A 6A D8 3F 62 E8 99 92 4A 4B 58 D6 C5 1E 04.

That is exactly what I want to have. Currently, I am getting following output from my SDR solution (PID, CALL, DATA, CRC): 56 4F 4E 30 33 41 54 D7 52 FD 5D 00 00 00 00 00 00 00 00 00 00 06 01 00 D1 FF FF F7 FC CF F0 7F 80 74 00 00 00 00 00 00 68 68 00 00 04 00 37 DF + the information that the RS decoder corrected 7 bytes. It is identically to the above shown beacon, but the parity check bytes of the FEC are missing. For this I need help on how to modify the RS decoder in order to output the FEC.

Furthermore, if it was possible to decode the signal succesfully (only than!) the raw beacon should be in addition saved in a local file. This beacon should again include the full length of 64 bytes (PID, CALL, DATA, CRC, FEC). With raw beacon I mean, that there shouldn'd be any error correction of the RS, it should be as it comes from the satellite with potential byte errors. That is the second thing, where I need help on how to get to this data and print it into a txt-file for further internal processing.

Your questions answered in short:

Do you want to throw away frames that fail Reed-Solomon decoding or not?

Yes, I don't need beacons where the RS decoding was not sucessful. Otherwise, I would again end up with 1500 packages.

Do you want to print the parity check bytes after decoding (those can be computed from the frame contents at any time) or before decoding, where there are potentially byte errors in them (in that case it would also be good to print the rest of the frame before decoding, since it has potentially byte errors too?)

(I hope I unterstood the question correctly) It depends. For the corrected beacons and uploaded beacons the parity check bytes (FEC) should be printed after decoding as it can be seen in the beacon of the STACIE. For the raw beacons the shoud be printed before decoding, well knowing that there may be potential byte errors. (But I guess, if the FEC contains wrong bytes the whole correction won't work out?)

I hope this answer clarified some things. :) Thank you very much in advance!

[daniestevez]

Then I think that what you should do is:

1. In the Reed-Solomon decoder, put the input frame (potentially with byte errors) into the PDU metadata, because only when you reach the CRC you will know if the frame will be discarded or not.
2. You can also put in the metadata the decoded RS codeword (including parity check bytes), so as not to have to modify the behaviour of the CRC check.
3. Then you'd make sure that the CRC check passes the PDU metadata intact (I'm not sure of this, but it's easy to do).
4. So in the end, for those frames that pass Reed-Solomon decoding and CRC checking you have in the output a PDU that contains the frame without CRC nor parity check bytes (you don't need this) and as metadata the original RS codeword (potentially with byte errors) and the decoded RS codeword (with no byte errors).
5. You can have a custom block write this output to a file (or two files) in the format you need, or perhaps the output of the Hexdump Sink (which is the Message Debug block, actually) will be sufficient.

[OE3ALA]

Many thanks for the support! I am very sorry about the late reply ... I had to shift my focus on other more important tasks. In the meantime I was able to print the FEC and CRC bytes wihtin the PDU message for those beacons that passed the checks. That is needed, because beacons without those bytes won't be uploaded and saved within our database for PEGASUS (It's a requirement for "external data", because SatNOGS and the gr-satellites plugin is not officially supported.)

I am not quite sure, if I am able to do some further modification in the near future. Therefore, I would l like to close the discussion. As you already stated, it isn't necessary because the checks are performed correctly! MANY MANY THANKS for all your excellent work! :)

[daniestevez]

Great! Thank you for the update.