Author Topic: CRC vs FEC  (Read 31839 times)

ziplockk

  • NewMember
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #15 on: December 11, 2016, 12:53:10 PM »
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.

It is on LORA, it isn't in 69's . . . doesn't really matter either way. LORA builds FEC into it's bit spreading, which is fundamentally part of a different way of transmitting the data. That doesn't stop you doing it elsewhere . . . or make it any less effective.

Fd

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #16 on: December 11, 2016, 01:22:01 PM »
Just to continue to wet appetites:

Quote
Additionally, coding gain could improve drastically the budget link. For example as low BR application, a 1024 bits coding could improve the budget link by 30 dB if BR is decreased by the same factor. The Semtech XE1203F incorporates an 11-bit Barker Encoder / Decoder, which provides for 10 dB of processing gain under the above conditions.

This is from http://www.semtech.com/images/datasheet/fcc_digital_modulation_systems_semtech.pdf which also helps understand why this helps from a compliance perspective as well.

joe

ziplockk

  • NewMember
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #17 on: December 11, 2016, 01:22:39 PM »
layers - layering approach.
triples - childishly simply FEC.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #18 on: December 11, 2016, 02:31:17 PM »
Yes, but sync word detection relies on the bit synchronizer working properly too, we have no idea how tolerant that is to noise. It may need a complete noise-free preamble to trigger the reception process.
Mark.

ziplockk

  • NewMember
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #19 on: December 11, 2016, 04:17:44 PM »
Why would the sync be error tolerant in that case ?

Fd

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #20 on: December 11, 2016, 04:46:13 PM »
We don't know. Certainly the sync word comparison logic can be programmed to trigger with multiple bit errors which is decoded from output from the bit synchronizer, but the bit syncronizer will be key in decoding bits. If that doesn't work it's likely to have so many bit errors as to make it useless.
Mark.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: CRC vs FEC
« Reply #21 on: December 11, 2016, 07:25:10 PM »
Just to continue to wet appetites:

This is from http://www.semtech.com/images/datasheet/fcc_digital_modulation_systems_semtech.pdf which also helps understand why this helps from a compliance perspective as well.

joe
Thanks!  So, from that, I can possibly answer my own question:  the improvement in link budget from Ziplockk's 3 bit FEC would be 4.8db.  Meh, not worth the bother.

However, that 30db improvement from the 1024bit coding.  Yeah, that's pretty compelling.   ;D

ziplockk

  • NewMember
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #22 on: December 11, 2016, 08:17:34 PM »
Oh dear . . .


joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #23 on: December 12, 2016, 03:09:24 AM »
I've found a good overview presentation on the subject: atlantarf.com/Error_Control.php

A couple of insights:

  • You have to specify the coding gain at a fixed BER rate. Coding gain increases as BER decreases.
  • At BER's typical in home automation (say 10^-2) only few FEC schemes actually have a positive coding gain. The best achieve around 4 dB coding gain at 10^-2.
  • ACK / Retransmits are actually a very effective form of improvement. Consider a BER of 10^-2 with two retransmits. That gets you down to a BER of 10^-6 with a traffic increase of ~1%. Not bad at all compared to FEC.
  • The most interesting applications for FEC are where you need very low BER and don't have a back channel to ACK or large latency. Like sending from a space mission.

All this argues against FEC's for home automation. However on the plus side:

  • With FEC's you can use a wide-band high bitrate signal to transmit low bitrate information. This allows you to be FCC compliant with higher TX power settings and without frequency hopping (see quoted semtech paper in earlier post).
  • Since you'd use a wider bandwidth you don't need to do AFC to compensate for poor XTALS.
  • You could use multiple coding schemes depending on link quality on top of the same radio settings, effectively using different bitrates depending on link quality per client without TDMA.


And some more implementation thoughts:

  • If you use packet mode you'd have to use fixed packet length since the length field might get corrupted in transmission.
  • Your maximum payload length per packet goes way down with code overhead. Eg if you do use 1024 bits per bit you'd get half a byte into a 64 byte packet  :o.
  • So realistically speaking you'd probably want to do this in continuous mode.

Quote
Thanks!  So, from that, I can possibly answer my own question:  the improvement in link budget from Ziplockk's 3 bit FEC would be 4.8db.  Meh, not worth the bother.

However, that 30db improvement from the 1024bit coding.  Yeah, that's pretty compelling.   ;D

Well it's a 30db (1000x) improvement since you use 1024 bit per bit. That's not the net coding gain. In reality if this was one of those very advanced codes you might get 33db for a net coding gain of 3db.

But still this shows the beauty of it: at 300kbit you can legally transmit at 12dBm or so. Now using 1024 bit per bit you get a bitrate of 300 baud without temp compensation of AFC. And another closer client might transmit to the same gw at ~300kbit net.

Of course now you have to implement encryption and coding in software. A hearty ARM processor would be better at this than our poor little 328p  ;)

Joe

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #24 on: December 12, 2016, 03:46:53 AM »
Quote
Yes, but sync word detection relies on the bit synchronizer working properly too, we have no idea how tolerant that is to noise. It may need a complete noise-free preamble to trigger the reception process.
Mark.

From the datasheet:

Quote
To ensure correct operation of the Bit Synchronizer, the following conditions have to be satisfied:
  A preamble (0x55 or 0xAA) of 12 bits is required for synchronization (from the RxReady interrupt)
  The subsequent payload bit stream must have at least one transition form '0' to '1' or '1' to '0 every 16 bits during data transmission
  The bit rate matching between the transmitter and the receiver must be better than 6.5 %.
Notes
- If the Bit Rates of transmitter and receiver are known to be the same, the RFM69HW will be able to receive an infinite unbalanced sequence (all ā€œ0sā€ or all ā€1sā€) with no restriction.

But yeah I agree this is the weak spot. The synchronizer needs to get in phase to work properly even if it's not used to align bitrates. That likely means the signal needs to be at least a bit higher than the noise floor.

Joe

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #25 on: December 12, 2016, 03:58:12 AM »
It depends how clever they have been with the bit synchronizer. If it's like a PLL it might be tolerant to noise, if it's more like a DLL then maybe not ;-)
Mark.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: CRC vs FEC
« Reply #26 on: December 12, 2016, 07:30:44 AM »
@joe
I guess by "net coding gain," you are discounting that part of the gain which comes from concurrently using the much lower bitrate?  i.e. compared to if you had already reduced your bitrate by 1000x, and then from there added the 1000x bits of coding, the coding part only brings you an extra 3db?  Wow.  Considering the really high overhead (1000x more bits), that's not much to get excited about.

Anyhow, as far as home automation goes, if there's a range issue, it seems you're better off keeping the high bitrate (to maintain high battery life on the mote) and just deploying another mains powered, wi-fi+rfm69 gateway node in the vicinity.  Am I right?
« Last Edit: December 12, 2016, 08:10:19 AM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #27 on: December 12, 2016, 08:28:31 AM »
It all depends on how the BER changes with S/N ratio in the radio. The lower the S/N the higher the BER. What coding gain does is introduce error correcting codes so that the overall BER in the decoded data, i.e. after error correcting, is lower than the BER of the encoded data before the error correction is applied, hence the S/N ratio can be lower to achieve a certain overall BER.The actual net gain is going to be highly dependent on how the BER is related to S/N.
Mark.

ziplockk

  • NewMember
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #28 on: December 13, 2016, 08:58:35 PM »
Anyhow, as far as home automation goes, if there's a range issue, it seems you're better off keeping the high bitrate (to maintain high battery life on the mote) and just deploying another mains powered, wi-fi+rfm69 gateway node in the vicinity.  Am I right?

Somewhat misses the point . . . why not just run cables . . . or move your garage closer to your living room . . . use pushrods . . .


WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: CRC vs FEC
« Reply #29 on: December 14, 2016, 06:36:45 AM »
Somewhat misses the point . . . why not just run cables . . . or move your garage closer to your living room . . . use pushrods . . .

You're right.  I'll retract what I said.