Author Topic: CRC vs FEC  (Read 31889 times)

ziplockk

  • NewMember
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #30 on: December 16, 2016, 07:15:25 AM »
I've been making some progress on verifying a new radio configuration ready for testing this concept.

Hope to have a configuration which will allow me to determine whether preamble and sync detection behaviour will support the concept, and if so how bit errors manifest themselves on the margin of range.

The FEC part is simple.

Have been having some general unreliability issues at low bitrates which I also wanted to understand, which has been consuming my time.

Seem to have found an interesting bug in the system (radio misbehaviour - not sure why or how it can happen) which is only apparent when you look at the RF traffic on a spectrum analyser . . . (radio transmits crazy long transmission (10x the length of what it's being asked to transmit) every now and again, problem disappears if you put the radio to sleep after every transmission) . . . repeatable. Causes the receiver to not receive anything (not surprisingly). Without a spectrum analyser you would assume it's a simple dropped packet . . .

Fd

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #31 on: December 16, 2016, 08:16:32 AM »
Interesting, I wonder if it's related to the behaviour I found when transitioning from STANDBY to RX didn't fully reset the receiver (causing it to not receive) but going from SLEEP to RX did...
Mark.

ziplockk

  • NewMember
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #32 on: December 16, 2016, 08:24:10 AM »
Dunno, but this is completely repeatable and seems to be apparent in higher bitrate configurations also, just more difficult to see.

The correct SPI sequence (so far as I can understand) is being used to feed the radio, but the radio itself is going bonkers . . . very occasionally.

Could be a coding issue with corrupt data in a variable I suppose, but it doesn't square up at the moment.

Certainly the 25 quid SDR I bought is proving very useful as it's difficult to argue with the facts on the screen . . .


perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #33 on: December 16, 2016, 08:57:29 AM »
Could it be a corrupted packet length byte? Do you have the correct SPI mode selected?
Mark.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #34 on: December 16, 2016, 09:10:06 AM »
Quote
Seem to have found an interesting bug in the system (radio misbehaviour - not sure why or how it can happen) which is only apparent when you look at the RF traffic on a spectrum analyser . . . (radio transmits crazy long transmission (10x the length of what it's being asked to transmit) every now and again, problem disappears if you put the radio to sleep after every transmission) . . . repeatable. Causes the receiver to not receive anything (not surprisingly). Without a spectrum analyser you would assume it's a simple dropped packet . . .

What surprised me initially is that the radio just keeps sending preamble after the packet is transmitted unless you actively set it to rx, standby or sleep. Do you have a code path that doesn't do that?

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: CRC vs FEC
« Reply #35 on: December 16, 2016, 10:08:27 AM »
Do you have the sequencer enabled?  Sounds like it's in "manual" mode.

[Edit: From the DS: "By default, when switching from a mode to another one, the sub-blocks are woken up according to a pre-defined and optimized sequence. Alternatively, these operating modes can be selected directly by disabling the automatic sequencer (SequencerOff in RegOpMode = 1). " ]
« Last Edit: December 16, 2016, 06:04:43 PM by WhiteHare »

ziplockk

  • NewMember
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #36 on: December 20, 2016, 06:47:09 AM »
Logic error on my part, interestingly the radio behaviour is quite inconsistent and somewhat random, hence the confusion.

Anyway, I have a build running without any CRC protection in the radio, low bitrate, 5 dropped packets per 1000 transmissions reliability.

Now need to profile the way in which the link fails as rssi drops which means a walk test to get some range effect.

I'll get round to it and update.

Fd


joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #37 on: December 20, 2016, 06:58:54 AM »
Quote
which means a walk test to get some range effect

Enjoy it! These are times when we all get some exercise  ;)

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: CRC vs FEC
« Reply #38 on: December 20, 2016, 11:01:40 AM »
There's also another way you could probably squeeze out some extra range/reliability if you wanted to.  It assumes the sender and receiver have closely synchronized RTC's--maybe using Joe's method or another one--and there are pre-defined time blocks when the receiver can expect a transmission from the sender (if there is one, that is).  Basically, record all the high-low and low-high transitions, along with time stamps, into an array during that time internval.  Then, afterward, you have the MCU inspect the array and purge problems that might have caused the radio's PHY to either miss or reject the packet (mainly because it can't approach the problem in as leisurely a way).  It would be the ghetto version of "cognitive radio."

ziplockk

  • NewMember
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #39 on: December 26, 2016, 12:10:01 PM »
Got a little time to progress things, still refining the basic radio configuration, no point in building on something that doesn't work perfectly. or isn't perfectly understood.

Low bitrates should produce better range (my objective), but rc osc accuracy causes poor performance with stock library settings . . . generally because at low bitrates it seems to be common to reduce the receiver bandwidth (per the data sheets), making the rc osc accuracy even more critical. So if you increase the receiver bandwidth you can get low bitrate transmission to be as reliable as the stock library settings (actually better in my testing) . . . rather than tweaking the tx/rx frequencies to compensate. Penalty is you may be more susceptible to noise . . . however the radio is fairly noise resilient for packet detection if correctly configured.

I've gone from a few percent packet error rate to zero percent after a number of hours running with this new configuration, all without CRC protection at the radio level (but at the application level).

RF comms are only unreliable if there's a good reason for that to be the case . . . some of the stock radio configurations are not reliable under optimal conditions . . . I'll share some settings to see if they produce reproducible reliability once I'm happy . . . and that will be with very low failure rates under optimal conditions . . .

The FEC side of things is the icing on the cake given my testing so far . . .

Fd

ziplockk

  • NewMember
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #40 on: December 27, 2016, 07:42:31 AM »
Ran overnight with 10's of thousands of transmissions, zero failures.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #41 on: December 27, 2016, 08:19:50 AM »
Which of the stock settings did you find problematic? Sounds like you got an improvement from increasing the rxbw. I also do that at very low bitrates where the frequency offset is large relative to fdev. Did you get a benefit at 55kbit? Were the nodes at dramatically different temperatures? Anything else?

The nice part about a highly redundant Fec scheme is that you can run at high bitrates so the freq offset won't matter much. Narrow-band transmission is kind of the opposite of what I thought was your original plan.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #42 on: December 27, 2016, 11:31:13 AM »
@ziplockk As a matter of interest, which CRC algorithm did you use? Was it CRC16_CCITT?
Mark.
« Last Edit: December 27, 2016, 11:33:30 AM by perky »

ziplockk

  • NewMember
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #43 on: December 28, 2016, 09:49:54 AM »
Which of the stock settings did you find problematic? Sounds like you got an improvement from increasing the rxbw. I also do that at very low bitrates where the frequency offset is large relative to fdev. Did you get a benefit at 55kbit? Were the nodes at dramatically different temperatures? Anything else?

I suspect that the rxbw 'stock' settings are a little tight across the board, I've had general minor unreliability issues which, like many others, I've been assuming were RF interference issues. I'm now largely convinced that this is not the case . . . increasing rxbw has made a dramatic difference to reliability. To be clear I'm talking 0.5-2% errors . . . but that is symptomatic of an issue . . . increasing rxbw seems to remove the errors.

Secondly, I was trying to use a cluster if RFM69HW's at low OTA bitrate and ran into random issues with one node being able to receive from its peers but its peers not being able to receive it's response . . . this is the classic frequency mismatch issue I think - but all nodes were at the 'same' temp in the 'same' environment, but that environment changed temp during the day . . . in the afternoons when it was warm, problems appeared, when cooler, everything worked. So I think 'different' temps is not the only issue . . . this change has solved that problem (so far) also. I've also incorporated reasonably frequent RC osc calibration into the general scheme of things at both ends . . .

The nice part about a highly redundant Fec scheme is that you can run at high bitrates so the freq offset won't matter much. Narrow-band transmission is kind of the opposite of what I thought was your original plan.

It seems that the issue is most prevalant at low OTA bitrates, I'm looking at low bitrates for range, and FEC for additional range, my application doesn't have large payloads, trying to squeeze everything into 16bytes so it can be AES256 encrypted in one block . . .

I think minimising the rxbw is a good thing, but not so much as it causes problems . . . I have a feeling that the data sheet figures are optimal and the real world needs a little more slop ;-)

ziplockk

  • NewMember
  • *
  • Posts: 28
  • Country: gb
Re: CRC vs FEC
« Reply #44 on: December 28, 2016, 09:57:58 AM »
@ziplockk As a matter of interest, which CRC algorithm did you use? Was it CRC16_CCITT?
Mark.

Something reliable I have in my code toolkit . . . I'm sending known (or calculatable) payloads so I know precisely what the error pattern looks like . . . so I don't technically need the CRC . . .

Fd