1
$\begingroup$

I'm currently working with a satellite that has AX.25 + Reed Solomon code (truncated RS(255,223)) in GNU Radio. Since there is no frame synchronization pattern, the 0x7e flags are used for frame delimiting followed by the bit de-stuffing. To make sure that the Reed-Solomon code is utilized properly, CRC is not used. So far the frames can be decoded perfectly.

I haven't performed BER tests (I will probably do this and compare results with any framing that doesn't do stuffing like CCSDS) on the implementation but I received a claim (and probably a right one) that the Reed-Solomon code can completely fail to properly correct errors in case there is error occurrence in stuffed bits. There were suggestions of putting provisions to detect any errors that may arise in bit stuffing before RS decoding. How would I accomplish this?

Improve this question
$\endgroup$
4
  • 1
    $\begingroup$ Can you further explain what you mean by "To make sure that the Reed-Solomon code is utilized properly, CRC is not used."? $\endgroup$
    – Glenn W9IQ
    Commented May 10, 2018 at 1:30
  • $\begingroup$ Since there is no FEC in traditional AX.25, a CRC is used for error detection. Traditionally, packets which fail CRC test are dropped. Now that there is RS code, dropping packets based on CRC wouldn't take advantage of RS FEC because the errors detected by CRC can be corrected by RS. The solution is, therefore, removing the CRC bytes and let RS take care of error detection and correction. I hope the explanation is clear enough. $\endgroup$
    – Moses Browne Mwakyanjala
    Commented May 10, 2018 at 16:07
  • $\begingroup$ It would make logical sense to me to keep the CRC, but use FEC to attempt to correct any errors in the entire packet (including CRC). If the attempt succeeded, the CRC would still allow you to detect that - without the CRC you are assuming that the FEC is always successful $\endgroup$
    – Scott Earle ♦
    Commented Jul 6, 2018 at 8:08
  • $\begingroup$ @ScottEarle The RS code used is capable of correcting up to 16 bytes and it is also able to detect uncorrectable errors as well (in case there are more than 16 bytes of errors). Therefore, using the CRC check is redundant. $\endgroup$
    – Moses Browne Mwakyanjala
    Commented Jul 13, 2018 at 15:48

1 Answer 1

Reset to default
1
$\begingroup$

I'm quite confused by your question. I suspect you are talking about a satellite which is using the FX.25 protocol (on Wikipedia), which is an extension of the original AX.25 protocol.

FX.25 is a compatible extension, as such the AX.25 packet is encapsulated inside the extra information of FX.25. The AX.25 is still decodable by a normal TNC, so it's format is still complete, with CRC and all (note that they are called Frame Check Sequence - FCS).

The frame synchronization pattern you mention is probably the 'correlation tag', which is a pattern with implicit redundancy (called a Gold code).

The Wikipedia article mentions a very basic on-the-air test, which shows an approx 30% improvement (the article doesn't mention which RS code was used).

I can imagine that erronous bit stuff-decoding could wreak havoc on reception. On 'talk' links (mainly ASCII), bit stuffing rarely happens. But transferring binary data would probably suffer a lot more. This probably accounts for the relatively high number of remaining errors in the test.

Don't confuse me for an expert. I only recently learned about FX.25 myself, but was reading up.

Improve this answer
$\endgroup$

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .