Author Topic: CRC vs FEC  (Read 32082 times)

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #45 on: December 28, 2016, 10:38:27 AM »
I assume you've seen this thread, it gives a set of rules you need to follow that relate Fdev, BR and RxBw. There are a couple of default configurations which I don't believe meet these rules:
https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/definition-of-rxbw-with-rfm69/

Also, frequency offset of transmitter to receiver is a real killer with sensistivity and AFC is therefore a very good idea to use, here's a really useful app note from Freescale on AFC for their MC12311 and MKW01 sub-GHz transceivers which are actually based on the same silicon as the sx1231. Note Figure 8 (in section 12):
www.nxp.com/assets/documents/data/en/application-notes/AN4983.pdf

Mark.

Edit: This app note also neatly explains what low beta offset is all about. Basically with low beta (i.e. low modultation index) most of the signal energy is concentrated at the centre frequency, but this is exactly where the inherent notch on the receiver bandwidth is. So you need to offset the signal slightly so it is out of that notch.
« Last Edit: December 28, 2016, 08:24:58 PM by perky »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #46 on: December 28, 2016, 04:32:27 PM »
Mark, this is interesting data, thanks! I wonder how much the sensitivity to frequency offset in their measurements is due to the low modulation index of 1 they use. I'll need to run some tests on my settings.

Quote
Also, frequency offset of transmitter to receiver is a real killer with sensistivity and AFC is therefore a very good idea to use

The problem I have with AFC is that it requires a whole lot of additional logic to work right: you have to dynamically determine the RSSI threshold - noise levels vary tremendously from install to install and even due to time of day. Plus you need to actively abort noise rx activations if you don't rx your sync word rapidly after RSSI to reset rx and bring frequency back where it belongs.

Joe

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #47 on: January 04, 2017, 06:44:58 AM »
Quote
I'll need to run some tests on my settings.

Wow am I happy that I just ran these tests. Once your frequency offset is larger than about 80% of fdev no packet reception is possible at all. Based on http://jeelabs.net/boards/6/topics/4624 it looks like the xtal has a tolerance of 10 ppm, which calculates to 9150hz at 915mhz. At 1.2k using a 5000 hz fdev even normal tolerances between modules could make it impossible to communicate.

Then throw in the temperature coefficient of the xtal (see https://lowpowerlab.com/forum/moteino/freq-vs-temperature-update/) and it becomes clear that one has to correct for the frequency offset for narrow-band comms. A wider RxBw doesn't help much.

Joe

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #48 on: January 04, 2017, 08:48:31 AM »
Good work Joe. I'm not surprised at the result though  ;)

Another thing about AFC is once it has corrected the RxBw can be the smallest it needs to be, that effectively increases the fade margin while receiving the packet itself.

Mark.

Edit: I'm not sure how strong the signal was above sensitivity level you used for this test. I suspect for very weak signals this offset dependence would be somwhat worse, a graph of required signal strenth to receive a packet v. percentage offset from Fdev would be handy ;)
« Last Edit: January 04, 2017, 09:04:58 AM by perky »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #49 on: January 04, 2017, 10:26:50 AM »
Quote
Edit: I'm not sure how strong the signal was above sensitivity level you used for this test. I suspect for very weak signals this offset dependence would be somwhat worse, a graph of required signal strenth to receive a packet v. percentage offset from Fdev would be handy ;)

:-)

Well for me this just means I do have to do AFC so I don't feel a need to dig into this much further. Doing AFC intelligently is more involved than one would think:

1.) Accessing SPI while receiving is a no-go since that measurably increases noise even on a Moteino. So actively restarting RX if SyncAddress doesn't timely follow RSSI doesn't work since you'd have to change DIO mapping while receiving to then catch PayloadReady. Therefore actively managing the RSSI threshold and continuously using AFC doesn't work.

2.) Additionally I'm concerned that at the edge of your range with these ultra narrow settings you might get so close to the noise floor that there's no room to increase the AfcRxBw and still successfully do AFC.   

I think I'll just measure the frequency offset once when first pairing a device to the gw which you do close to the gw so 2.) isn't yet an issue. That takes care of the manufacturing tolerance. Then I'll periodically do an AFC using the same AfcRxBw as RxBw to adjust for temperature and aging - say once per hour.

For all other packets I'll just use the measured frequency offset and set RSSIThresh to 255 as I usually do, not using AFC or AGC.

Joe
« Last Edit: January 04, 2017, 10:30:53 AM by joelucid »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #50 on: January 04, 2017, 11:56:31 AM »
Mmm. I've not seen that much noise induced by SPI. I do though use series terminating resistors at the source of SPI signals to take out the high frequency content of the square waves they produce (i.e. slow edges down), and to prevent any possibility of under and overshoot which can cause momentary current spikes if they are clamped by the substrate diodes. That means 56R or 100R series resistors close to the MCU for SCK and MOSI, and 56R or 100R close to the MISO of the radio.

At low signal levels when permanently receiving though you are going to need timeouts from RSSI to address match, and from address match to payload ready, and reset the receiver accordingly.

BTW I did a quick experiment to check this, I had a transmitter sending alternate packets. The first packet was at the correct frequency and correct sync word, the other simulated noise by offsetting the frequency by 20kHz and flipped one of the address word bits so the receiver got an RSSI but no address match. Result without timeouts was 85% packet loss (AFC kicked in for the noise packet and didn't get reset), but with the timeouts version the packet error rate was 0.5%. That's pretty conclusive!

Mark.


joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #51 on: January 04, 2017, 12:14:17 PM »
Quote
Mmm. I've not seen that much noise induced by SPI.

I have a test where I set RSSI thresh to a certain value, then go into RX and see if I get an RSSI interrupt in a short period of time. Using this iteratively with a sweep of RSSI thresh values I can measure the noise floor very reliably. If instead of sleeping I poll a radio register I get a significantly elevated noise floor even with Moteino. You're right though - this could definitely be improved with HW.

Quote
At low signal levels when permanently receiving though you are going to need timeouts from RSSI to address match, and from address match to payload ready, and reset the receiver accordingly.

True if you use AFC or AGC, but not true otherwise. That's why for normal packets I won't use AFC nor AGC.

When I do AFC I'll first send a ping to the gw and establish RSSI from the ACK. Then I'll set the RSSIThresh immediately below that RSSI, send a second packet and do AFC during reception of the ACK. I can use regular ACK timeouts for that packet since I know the timing.

Quote
BTW I did a quick experiment to check this, I had a transmitter sending alternate packets. The first packet was at the correct frequency and correct sync word, the other simulated noise by offsetting the frequency by 20kHz and flipped one of the address word bits so the receiver got an RSSI but no address match. Result without timeouts was 85% packet loss (AFC kicked in for the noise packet and didn't get reset), but with the timeouts version the packet error rate was 0.5%. That's pretty conclusive!

Yeah - that same problem hits you with stock RFM69 and AGC: the low RSSI Thresh below noise floor causes AGC to select min gain immediately and a strong packet can then overload the receiver. Or if you immediately receive loud noise you won't pick up a weak packet afterwards.

Joe
« Last Edit: January 04, 2017, 01:09:40 PM by joelucid »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #52 on: January 04, 2017, 05:47:06 PM »
After a couple of experiments here's another upside of this approach: I notice that the accuracy of AFC is very much dependent on fdev. Used at high bitrates the average error in AFC easily exceeds 5khz and the average manufacturing tolerance. At very tight fdev's however AFC is very precise.

Since I'm doing AFC independently of payload transmission I can do it at a low fdev, yielding some benefit even at the high bitrates. Not sure how useful but it's a theoretical upside.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #53 on: January 06, 2017, 08:18:59 PM »
After a couple of experiments here's another upside of this approach: I notice that the accuracy of AFC is very much dependent on fdev. Used at high bitrates the average error in AFC easily exceeds 5khz and the average manufacturing tolerance. At very tight fdev's however AFC is very precise. Since I'm doing AFC independently of payload transmission I can do it at a low fdev, yielding some benefit even at the high bitrates. Not sure how useful but it's a theoretical upside.
I'm guessing this means the AFC is quantized in steps, and the step size is scaled with Fdev. It also points to the possibility that the S/N is dependent on the ratio of offset to Fdev, so you might not actually gain that much in using a small Fdev for the AFC to lock close to the real frequency while using a much larger Fdev for payload.
Mark.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #54 on: January 07, 2017, 04:16:10 AM »
Quote
so you might not actually gain that much in using a small Fdev for the AFC to lock close to the real frequency while using a much larger Fdev for payload.

Yes, my thought exactly.

BTW, how do you manage AFC and what bitrate do you use? It seems like you set a RSSI threshold and use AFC on every packet, correct? If yes, how do you determine the threshold? Do you dynamically update it? I've had nothing but trouble trying to get AFC to work reliably in dynamic environment with very weak signals because the threshold was almost always either too high or too low.

The scheme I proposed works well to maintain freq sync. But then how do you send the first packet and be heard?

I'm currently looking at temp compensation along the lines of https://lowpowerlab.com/forum/moteino/freq-vs-temperature-update/ but I'm finding that every module has a different freq offset / T curve. The potential saving grace: they all seem to be fairly linear in the range from 10-30 celsius, so two point calibration would give you enough accuracy to talk to each other at room temperature. And if you take a node into the snow it could learn via AFC what the curve looks like outside of that range.

Joe

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #55 on: January 07, 2017, 09:29:04 AM »
BTW, how do you manage AFC and what bitrate do you use? It seems like you set a RSSI threshold and use AFC on every packet, correct? If yes, how do you determine the threshold? Do you dynamically update it? I've had nothing but trouble trying to get AFC to work reliably in dynamic environment with very weak signals because the threshold was almost always either too high or too low.

There are two sources of noise, internal and external. Assuming there are no radio transmitters around at all, the background RF noise would be below the sensitivity level, so the question is what is the nature of this external RF noise? I think it's actually quite peaky, there's an average but in reality there are gaps where that noise level is below the sensitivity level. So if your receiver only wakes up and receives for a few ms before the real packet is transmitted you've created a very small window that ignores all the other noise peaks outside of it. If you were permanently receiving it get's more difficult, you'd need the timeouts previously discussed and your 'window' increases in size. So I set my threshold to be about 5dB above the sensitivity level (which doesn't change). I also use frequency hopping with randomized timing of packet transmission to prevent the possibility of synchronizing with another source.
Mark.
« Last Edit: January 07, 2017, 09:45:21 AM by perky »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #56 on: January 07, 2017, 10:22:30 AM »
Quote
so the question is what is the nature of this external RF noise?

Exactly. And that's where I see the problem. Recall that one of the FAQ's here in the forum is why Moteinos don't send and then it turns out they always sense a carrier. My noise measurement code measures 2ms to see if a given RSSI level is hit. And just by moving the radio onto my desk with its 5 monitors and 2 computers RSSI is hit a couple of dBm higher for every single 2 ms period. So yes there are spikes, but theres also a background buzz which varies by location and depending on what's on close to the radio.

Even to avoid the CSMA problem one needs to manage the threshold. I do that for listen mode for example - otherwise it just doesn't work well. Whenever I get phantom activations I increase the threshold. And over time when I don't I gradually bring it down. This works but I can construct all kinds of scenarios where it would be fatal.

Quote
So I set my threshold to be about 5dB above the sensitivity level (which doesn't change).

I see - so you give up 5db in sensitivity for AFC and AGC (which I'm trying to avoid). And if you do get a 5dB background buzz your screwed, correct? You might end up having to do the same workarounds I use for listen mode.

Joe

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #57 on: January 07, 2017, 11:51:39 AM »
I see - so you give up 5db in sensitivity for AFC and AGC (which I'm trying to avoid). And if you do get a 5dB background buzz your screwed, correct? You might end up having to do the same workarounds I use for listen mode.

Yes, but I also need a fade margin. In other words the signal has to be somewhat above sensitivity level anyway, and as soon as AFC kicks in a lower RxBw is selected which increases the fade margin further.

I can understand putting things into noisy RF environments with constant wideband noise might be problematical though, and I may yet have to pull the same tricks as you.

BTW a lot of these sensing carrier problems using CSMA I believe has a lot to do with how RSSI is read, which I don't believe actually works properly. There are several threads on this. I don't believe that just reading the RSSI register is sufficient and the manual triggering mechanism is broken in the chip (at least I've never got that to work).

Mark.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #58 on: January 07, 2017, 01:46:02 PM »
Quote
Yes, but I also need a fade margin. In other words the signal has to be somewhat above sensitivity level anyway, and as soon as AFC kicks in a lower RxBw is selected which increases the fade margin further.

If you have the rssi thresh 5 db above receiver sensitivity you can't count those in your fade margin, can you? Signals weaker than this will not be received so any margin would need to be on top of that.

Quote
BTW a lot of these sensing carrier problems using CSMA I believe has a lot to do with how RSSI is read, which I don't believe actually works properly.

Yeah I'm quite aware. It took me a lot of time to figure out a way to measure RSSI reliably and I did go through all of these threads for inspiration.

Joe

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #59 on: January 07, 2017, 04:09:06 PM »
If you have the rssi thresh 5 db above receiver sensitivity you can't count those in your fade margin, can you? Signals weaker than this will not be received so any margin would need to be on top of that.

You're right, technically I can't. I've chosen a half way house by putting a criteria on initial packet recognition that is below my normal phase margin, but when AFC kicks in I know that the fade margin during actual packet reception is greater due to lower RxBw. Multipath fading is mitigated somewhat by using frequency hopping. I admit it's a bit of a compromise.
Mark.