Author Topic: CRC vs FEC  (Read 31920 times)

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: CRC vs FEC
« Reply #60 on: January 07, 2017, 09:21:46 PM »
And if you do get a 5dB background buzz your screwed, correct?

I may possibly see a way around that.  Upon detection of a >=5dB signal, you start a timer and then continuously resample RSSI, looking for an opening.  If the source of the signal is a legitimate, intentional transmitter (i.e. not  merely the RF pollution of elevated background noise from your collection of 5 monitors), then it must obey the regulatory duty cycle rules.  And that means the signal must stop within a predictable timeframe from the time of first detection.  If it does, then you start transmission because you have what appears to be an opening.  If it doesn't, then you transmit anyway, because you can infer that it's not an intentional transmitter

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #61 on: January 08, 2017, 10:11:44 AM »
Quote
Upon detection of a >=5dB signal, you start a timer and then continuously resample RSSI, looking for an opening.

Remember it's the receiver we're talking about. You need to set an RSSi threshold and as soon as that gets hit AFC starts, potentially detuning your receiver. You need wait for sync and reset the receiver if it doesn't come as quickly as it should so you can RX packets again. It takes like 6-8 bytes of preamble plus the 2 sync bytes until you can make the decision - quite a bit of time.

Set the threshold too low and you'll be latching onto noise all the time, never ready to read a signal. Set it too high and you won't receive weak signals.

Because of differences in background noise you need to dynamically adjust the threshold. But any such algorithm has the problem of differentiating between background noise and signals based on a pretty irregular sampling of unreceivable RSSI threshold triggerings.

You want to raise the threshold quickly if there's noise so you don't miss many packets. And you want to lower it quickly so you don't miss weak signals once the noise is gone. But you don't want to trigger on the noise floor often again missing packets. You need to avoid raising the threshold on periodic signals from other radios etc.

It just seems like a pretty difficult problem to solve for all corner cases. Which are sure to hit you somewhere in a commercial product.

Joe

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #62 on: January 08, 2017, 10:22:30 AM »
Quote
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.

I think it's quite possible that AFC works below the sensitivity of the receiver. So maybe you can set the threshold right at the sensitivity level and still be good. Modulo the threshold management problem.

AFC seems like a great mechanism for low beta, mid bitrate applications (like the example in the app note you quoted) where you need quite a bit of signal to noise to receive anyway, but still don't have a large fdev. In that scenario threshold mgmt is easier and AFC might work quite a bit below RX sensitivity, allowing the thresh to be at sensitivity even while using a larger afcrxbw.

But with ultra narrow-band applications I'm skeptical.

Joe

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #63 on: January 08, 2017, 12:58:56 PM »
Yeah, it's a bit of a pain.

There is one possibility that might help. Currently I open my RX window a few ms before the packet is transmitted. If there's noise that's above the threshold at that point it'll trigger an RSSI and AFC, and as you say that can take some time to complete. If my real packet comes along a few ms later which has a higher signal strength it might not be seen properly as it has already been triggered. If instead I extend the preamble of the packet and start the transmission before the RX starts then it may see the real packet immediately and lock on to that instead, and because the signal strength is higher it should over-ride the noise.

BTW my PER is currently about 1.2% but that is with an 868MHz burglar alarm with 5 transmission sources in the house as well. If I take the sources outside away from the burglar alarm it drops to about 0.7%.

Mark.
« Last Edit: January 08, 2017, 01:00:44 PM by perky »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #64 on: January 14, 2017, 12:31:07 PM »
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.

Turns out with my approach of setting RSSI Thresh to 255 and always being in RX RSSI can be read fine over time. The problems only seem to exist when your waiting for RSSI thresh to be hit.

One big problem RFM69 and also my lib has/had is RSSI is read after PayloadAvailable hits. This is after decoding of the packet. Depending on the speed of the sender TX might have ramped down by then and you get inconsistent values. I saw that with 16 Mhz Moteinos, but not with 8 Mhz ones.

The solution is to read RSSI continuously during reception until CRC hits. That way I finally get consistent readings regardless of clock speed settings.

Given that I now sample RSSI all the time I just keep the last 1024 readings (I store one every 5 ms) and can produce nice little charts like the one attached (a 1200 baud packet coming in).

Cool eh?

Joe

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #65 on: January 14, 2017, 12:54:45 PM »
Now I can show you what I mean with the rssi thresh adjustment problem. Attached is a chart showing what happens when I plug in a 433 Mhz AC Plug 1m from my GW.

Switched on at ~3300 ms.

Joe

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #66 on: January 14, 2017, 02:21:29 PM »
That's really good work Joe.

I found that once a packet starts to be received it is frozen at its final value at the point payloadReady happens, but is unfrozen again once the FIFO has been read and payloadReady de-asserts (if you have AutoRxRestartOn set to 1, although I didn't try with it set to 0). So I always read RSSI after a payloadReady asserts but before reading the packet data out of the FIFO, i.e. before any decoding of the packet. I get consistent results with this.

I'm currently trying to solve the RSSI threshold problem with AFC. I think once the receiver has locked onto a transmission sequence it can turn on only during the time the transmitter is sending its extended preamble (similary when sending a reply, the sender would enable its receiver while the preamble of the reply is active). I think that would allow setting RSSI threshold to 255 as it will trigger immediately since to receive the packet it has to be above noise anyway.

The problem with the above is inital locking. Currently I scan the channel for a valid packet, and then lock on to the sequence putting the receiver to sleep and waking it up on the next calculated timeslot. So how do I receive the initial packet to lock to without setting a threshold?

It's clear that the higher the threshold the lower the frequency of noise triggers, and a noise trigger cause the receiver to temporarily not receive until the address match timeout whereby it will be re-enabled, so there are windows where it can't detect a real packet. The frequency of that depends on the threshold and on the amount of noise. Set the threshold too high and you lose range, set it too low and your packet error rate goes up. Mmm.

Mark.

Edit: There may be a way out of this. It's only initial locking where I need to have some kind of dynamic RSSI threshold, after that I think the above scheme would mean I don't need to bother with it. So maybe I try to set the RSSI threshold to one that has a low enough frequency of noise triggers to allow me to lock within a decent timeframe. Any chance in posting your RSSI measuring code? ;-)
« Last Edit: January 14, 2017, 02:31:41 PM by perky »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #67 on: January 14, 2017, 04:20:47 PM »
Well I've just done an experiment, I had a receiver set at -95dB threshold and turning the receiver on 4ms before the packet was transmitted gave me about 1.2% PER (I've got a burglar alarm on the same frequencies with 5 sources of transmissions). Changing it to turn on the receiver when the transmitter is sending preambles has dropped that to 0%. Still set to -95dB, so need to drop it to below noise floor, but that's encouraging....
Mark.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #68 on: January 14, 2017, 05:30:54 PM »
Mark, i would not like to have a sketchier connection particularly during locking which requires 25 packets on average. In fact I don't want to require any AFC for usual traffic at all in case it impacts on sensitivity.

Thats why I have an initial pairing in proximity where boh nodes are set to a wide band seting so both can talk. When they're locked the gw starts a calibration session where it heats up its radio and derives its temp correction coefficients by pinging the sensor and receiving the acks at narrow band settings with AFC while cooling down. Here the timing is clear and the nodes are close so either your scheme or a high threshold work. The acks are sent using the narrow band profile where AFC is most effective.

Now both nodes switch to narrow band. The client can now periodically ping the gw with an afc request and learn its temp correction table by applying afc on the acks. Again the timing is clear so your method would work. I've been sending a ping first, and have taken the rssi of the ack - 1 as thresh.

I could also use the heating method for the sensor - but these may be rfm69w's so they aren't capable of self heating. So instead the devices are considered paired when the gw is calibrated and the remainder happens on the go.

The beauty is when I lose connection I can just lock again without any AFC involved. So locking is possible at the most marginal link strength.

Did my first range test today while taking a walk with the family. Gw with dipole in the house, Moteino at sub zero temps outside with usual wire antenna. At 1200 baud I had reception at about 1km away - pretty good considering the gw was indoors. Lowest packet RSSI was -121, packets around -115 were common. Overall I consider it a success.

Joe

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #69 on: January 14, 2017, 06:04:37 PM »
Quote
I found that once a packet starts to be received it is frozen at its final value at the point payloadReady happens, but is unfrozen again once the FIFO has been read and payloadReady de-asserts (if you have AutoRxRestartOn set to 1, although I didn't try with it set to 0). So I always read RSSI after a payloadReady asserts but before reading the packet data out of the FIFO, i.e. before any decoding of the packet. I get consistent results with this.

That's weird - I don't use any additional buffer, so I don't clear the FIFO quickly and I retrieved RSSI in the PayloadAvailable irq. Still I saw the inconsistencies and I could make the stop by adding a delay(1) before putting the sender out of TX.

My sense was that RSSI is locked when you put the radio into opmode standby, but that happens too late in this case.

Quote
Any chance in posting your RSSI measuring code? ;-)

Well the point is there's nothing special about it anymore. I just avoid updating RSSI when CRC has been detected. Here's the section:

Code: [Select]
bool SX1231Driver::available() 
{
if( !isTransmitComplete() ) return false;

if( _mode != SX1231_OPMODE_RECEIVER ) {
setMode(SX1231_OPMODE_RECEIVER);
}
else {
if( !(readReg( SX1231_REG_IRQFLAGS2 ) & SX1231_IRQFLAGS2_CRCOK ))
_rssi = readRssiValue();
return readDIO0();
}
return false;
}

Note that I'm starting to get more comfortable accessing SPI during RX. The reason is I've finally figured out when that hurts and what to do about it: with my new GW's with dipoles at somewhat of a distance I don't have that problem. If I put the dipole close to the board it starts to happen.

The old gw's with wire antenna's all have the problem. So I think it's the ESP8266 radiating into the antenna. Now I only need to stop this on boards with chip antenna. That should be a bit of a challenge.

The more involved RSSI detection code managed RSSI detection without accessing the SPI - still useful to see how much of an impact that has.

Joe

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #70 on: January 14, 2017, 06:19:19 PM »
Quote
(if you have AutoRxRestartOn set to 1, although I didn't try with it set to 0).

Ah that might be it. I have autorxrestart off because that allows faster packet bursts for the bootloader. Will have to try if that fixes it. Would be nice to keep the no spi option open.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #71 on: January 14, 2017, 06:35:30 PM »
Quote
The beauty is when I lose connection I can just lock again without any AFC involved. So locking is possible at the most marginal link strength.

And if wasn't clear - since the gw never does AFC or AGC other than during pairing it can always use the 255 rssi thresh.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #72 on: January 14, 2017, 07:08:48 PM »
Thanks Joe, some neat solutions there.

Ah that might be it. I have autorxrestart off because that allows faster packet bursts for the bootloader. Will have to try if that fixes it. Would be nice to keep the no spi option open.
That makes sense. The RSSI is probably latched after a payloadReady until a RX reset condition, which with autorxrestart on will happen when the FIFO is emptied.

My system is different to yours it seems. Everything is battery operated, and the status back from the nodes is low bandwidth data, so I use a polling method where the controller requests a response from a specific node which are all locked to the controller's packet sequence. That means the controller only transmits with low duty cycle, and it also needs to be narrow band to allow multiple channels in the small sub-band of 868MHz I have available. The nodes don't send requests to the controller. If I had to have a receiver permanently on in my controller I'd be in the same boat as you! Having said that, it's the locking that's the thorn because that does need to be permanently on during the scanning part for a lock. I also want the system to be easily installed by a user so any node can be made to talk to any controller in a simple configuration process, so I don't really want any calibration (even though it appears this has solved your problems).

So what I'm left with now is trying to come up with a reliable algorithm for setting the threshold for locking, but that ain't easy. There could be other radios on channel for up to 3.6 seconds at a time with only 1.8 seconds between each one (staying within their 1% duty cycle over an hour) which might cause me to raise the threshold too much because that's really a transient reception that will go away. And there could be several devices doing this just at that time. It may be I'd need to do some kind of RSSI scanning for quite some time to establish a reasonable threshold.

It might be that dropping the threshold until the radio permanently triggers then raising it by a fixed amount might do the trick, but If you can think of an algorithm that might work I'm all ears ;)

Mark.
« Last Edit: January 14, 2017, 07:18:14 PM by perky »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #73 on: January 15, 2017, 01:37:09 AM »
Quote
It might be that dropping the threshold until the radio permanently triggers then raising it by a fixed amount might do the trick, but If you can think of an algorithm that might work I'm all ears ;)

How about setting thresh to 255 and rxbw to your afcrxbw and continuously monitoring RSSI. Then when you see something that might be a packet you set thresh to your observed floor and kick off reception with AFC. That might work given your longer preambles.

I do think it will hurt though - depending on your settings. If you use a RxBW of 5000 hz you'd need to use at least 4x that to do AFC reliably. That's 6 dB more noise. And it doesn't seem like you need more than 6 dB signal to noise with the low bitrates to receive.

So don't toss temp calibration out the window too quickly. You could do it during manufacturing to avoid the pairing step and allow every node to talk to every controller. Or you could use TCXO's - HopeRF will do custom modules starting at quantities of 3000 I believe.

Edit: actually you can just keep the noise floor at 255 during afc. But during rssi proving you have afc off.

Joe
« Last Edit: January 15, 2017, 03:47:18 AM by joelucid »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: CRC vs FEC
« Reply #74 on: January 15, 2017, 02:50:04 AM »
Quote
Ah that might be it. I have autorxrestart off because that allows faster packet bursts for the bootloader. Will have to try if that fixes it. Would be nice to keep the no spi option open.

Yeah - that was it. But I'll stick with the new method for now. So nice to auto-generate these charts.