Author Topic: CRC vs FEC  (Read 10984 times)

ziplockk

  • Newbie
  • *
  • Posts: 28
  • Country: gb
CRC vs FEC
« on: December 09, 2016, 07:02:31 PM »
Lots of libraries seem to rely on the radio payload CRC verification, meaning that if the CRC fails the packet is discarded, which on the RFM69 that seems to be long before the receiver sensitivity limit (-120dBm).

LORA relies on FEC to improve packet reconstruction before the CRC is applied, so why do people not do this for transceivers like the RFM69 . . . ?

Anybody played in this area ?

Pre-encoding the payload using something like Hamming 7,4 should allow packet recovery with bit errors where a normal CRC would cause the packet to be discarded by the radio . . . transmitting without the radio CRC check should, therefore, increase sensitivity as packets which contain bit corruption should be recoverable . . . penalty is an increase in the number of bits needing transmitted . . . but in many cases that's not the real issue . . .

Or am I missing something ?

Fd


perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #1 on: December 09, 2016, 07:40:10 PM »
Well radio is inherently unreliable, so assuming you have mechanisms to counter that (like retries) there doesn't seem much point IMO in over-engineering an EDC mechanism, just as long as you can reliably detect a corrupted packet (either by no packet being received, or a packet content based CRC if one happens to get through with multiple bit errors). Also data whitening will scramble the transmitted data, so a single bit error in that will result in a multiple cascade of bit errors when de-whitened. People do try to keep the number if bytes transmitted to a minimum though especially in battery operated systems. There's the issue of variable packet lengths too, if you turn CRC off you might get a corrupted packet length byte.

Pesronally I think the combination of sync word filtering, data whitening, CRC16 of the radio and some parameter checking of the content of the packet is sufficient to detect a missed packet or an errored packet, and then the retry mechanism kicks in.

Mark.



ziplockk

  • Newbie
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #2 on: December 09, 2016, 09:18:45 PM »
Nah, retrying doesn't improve range, it may improve reliability, nothing more. If you're at a range which causes bit errors in the RF datastream then the CRC will always fail and that is the end of the game. If, however, you can reconstruct packets which would otherwise fail the radio CRC you can increase range and reliability . . . and effectively receiver sensitivity.

I work with some RF experts who I have been learning from . . .

Will produce some sample code in the next few weeks . . . it's not too complex . . . but needs some maths . . .

Fd


ziplockk

  • Newbie
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #3 on: December 09, 2016, 09:37:32 PM »
Also . . .

You're thinking about the wrong layer.

I'm thinking about a layer above the RF transport. where the payload length is also encoded in a redundant manner.

This is how people get extreme performance from RF systems . . . specifically radios like the RF69 . . .

the LORA/RF95 system relies heavily on FEC to give the increased range (and probably I would not buy another RF69 having played with RP95's) . . . but I think we can do much better with RF69's . . .

Fd

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Re: CRC vs FEC
« Reply #4 on: December 09, 2016, 11:18:42 PM »
Nah, retrying doesn't improve range, it may improve reliability, nothing more. If you're at a range which causes bit errors in the RF datastream then the CRC will always fail and that is the end of the game.

That doesn't ring true.  As you approach the limit of the transmission range, some packets may still get through, even if a lot of them don't or get corrupted and filtered out because they fail the CRC check.
« Last Edit: December 10, 2016, 03:54:22 AM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: CRC vs FEC
« Reply #5 on: December 10, 2016, 03:27:11 AM »
Quote
LORA relies on FEC to improve packet reconstruction before the CRC is applied, so why do people not do this for transceivers like the RFM69 . . . ?

This is a good idea. I have thought about it but haven't tried it yet. I see two issues:

1. Sync word detection starts the packet rx process. You can set the number of tolerated bit errors at the rfm69 though so the chip allows unreliable connections at that stage. I think it's also possible to receive with sync word length of 0 but haven't tried it.

2. The radio uses a bit synchronizer when receiving to generate a clean sequence of 1's and 0's. It'll be interesting to see how good of a signal one needs for that to work. LoRa is at an advantage here because it can use the known chip sequence to find a signal in the noise.

My take is that you can't get quite to the level of LoRa but you should be able to get a very significant improvement. Can't wait to see what you come up with!

Joe

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: CRC vs FEC
« Reply #6 on: December 10, 2016, 03:31:30 AM »
Quote
Nah, retrying doesn't improve range, it may improve reliability, nothing more. If you're at a range which causes bit errors in the RF datastream then the CRC will always fail and that is the end of the game.

Retrying helps you cope when you have bit errors just as coding does. So it's also a mechanism to increase range but much less effective than what you're trying to do: with retries you need at least one error free transmission which coding doesn't require.

joe

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: CRC vs FEC
« Reply #7 on: December 10, 2016, 03:36:31 AM »
Forgot a third issue:

Since you'll be receiving close to the noise floor you need to set rssithresh to 255 so the radio continuously looks for the sync word instead of waiting for rssi detection to trigger reception.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Re: CRC vs FEC
« Reply #8 on: December 10, 2016, 08:16:48 AM »
Retrying helps you cope when you have bit errors just as coding does. So it's also a mechanism to increase range but much less effective than what you're trying to do: with retries you need at least one error free transmission which coding doesn't require.

joe

Good point.  Sounds worthwhile.  I hear that LDPC is pretty good.
« Last Edit: December 10, 2016, 08:19:54 AM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #9 on: December 10, 2016, 09:12:27 AM »
OK, I see. Use coding gain by sending EDC codes to lower the S/N needed to achieve a certain overall BER. I'm not sure how RFM69 devices would work in this scenario, how for example AGC and AFC would be used, unless it demands wideband operation so these aren't used which would reduce range but compensated by coding gain. How does frequency offset of the transmitter to the receiver actually affect BER? The sync words can accept bit errors so can be tolerant to a higher BER, but the bit synchronizer might require a decent BER to work in the first place. It would be interesting for people to have a go at this though in case it actually is possible.

Mark.
« Last Edit: December 10, 2016, 02:58:37 PM by perky »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Re: CRC vs FEC
« Reply #10 on: December 10, 2016, 01:34:59 PM »
Seems like there should already be a library somewhere where you just hand it a string and some parameters and it hands you back a string with all the FEC built in.  Then you just Tx that as usual.  Likewise, on the receiving end, you hand it a string of what you received and it hands you back the error corrected string.

If there is such a library (I haven't looked), then this might be fairly easy to try.   ;D

ziplockk

  • Newbie
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #11 on: December 10, 2016, 02:02:57 PM »
There are implementations, from simple and inefficient to complex and more efficient. In this case the efficiency is the number of extra bits required to allow reconstruction.

You're correct to mention preamble and sync, which is critical to starting packet detection . . . something else I'm researching.

At its simplest a simple bit tripler allows 2/3 bit voting FEC which allows a 1 OTA bit corruption out of every 3 and still allows full packet reconstruction . . . penalty is it triples the OTA payload, inefficient but robust, but trivial to implement.

If that can be shown to work then you can use something more clever, Hamming 7/4 for example . . . I found the basis of an implementation kicking about on the net somewhere which could be adapted.

This is a very old idea, ADSL/VDSL/DVD/CD all use FEC, and so do serious radio people . . . ;-)

Fd


WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Re: CRC vs FEC
« Reply #12 on: December 10, 2016, 06:08:23 PM »
I've heard it's fairly typical for a particular coding scheme to be expressed as equivalent to "x db improvement" in link budget.  Anyone know how much improvement in link budget the triple bit FEC scheme would be equivalent to?

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Re: CRC vs FEC
« Reply #13 on: December 11, 2016, 09:41:00 AM »
Forgot a third issue:

Since you'll be receiving close to the noise floor you need to set rssithresh to 255 so the radio continuously looks for the sync word instead of waiting for rssi detection to trigger reception.

I've always thought of FEC as being implemented in the PHY layer, and maybe your comment explains why.  Maybe an MCU just isn't fast enough to detect and lock the signal as often as you might possibly want.  In fact, maybe that's why the bitrate is relatively low on the LoRa radios, since that problem would seem to become even more slippery at faster bitrates.


ziplockk

  • Newbie
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #14 on: December 11, 2016, 12:50:58 PM »
So, sync detection on the 69 is bit error tolerant (up to 7 bit errors in 8 to 64 bits of sync), and there are operating modes where a preamble and sync followed by an unprocessed payload is possible, no CRC required or checked on reception. So it should be possible to move all the packet encoding, decoding and validation into the micro and out of the radio. What this means is that the radio detects packets which would not pass a CRC and provides them to the micro, the micro then performs error recovery on the data then verifies a post error recovery CRC check in software . . . any addressing/application level data in the payload can only be interpreted after this is done . . . if after error recovery the CRC still fails - it's beyond recovery . . .

It may also be worthwhile using manchester encoding for the OTA transmission . . . 1/2 the effective bitrate but more robust.

That the sync detection can deal with bit errors is a clue as to another way of using the radio ;-)