Author Topic: CRC vs FEC  (Read 10958 times)

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #75 on: January 15, 2017, 08:52:23 AM »
OK, so given my preamble is now extended (it'll be an additional 6ms plus the original 5 bytes worth of the real packet, that 6ms deals with +/-3ms of LO offset drift so receivers still remain locked even if they miss several packets in a row), I think you're suggesting sample RSSI in ultra-fast non AFC mode and look for a set of consecutive RSSI values that are relatively constant for 6ms to indicate a packet might be being transmitted, then I could trigger AFC and try to receive it. If I can measure RSSI fast enough, do the maths and programme into AFC mode within that 6ms timescale then it might work. Thanks for that!

I might need to look for a step change at the beginning given it will need a certain S/N above ambient noise to receive anyway, have you a feel for that value? would 6dB do it?

Mark.

Edit: BTW I've run the test with the receiver put into RX mode while the transmitter is sending preambles now for over 12 hours with a packet drop (two way) of less than 1 in 1000. So that definitely works well.
« Last Edit: January 15, 2017, 09:59:32 AM by perky »

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: CRC vs FEC
« Reply #76 on: January 16, 2017, 09:22:20 AM »
Quote
I think you're suggesting sample RSSI in ultra-fast non AFC mode and look for a set of consecutive RSSI values that are relatively constant for 6ms to indicate a packet might be being transmitted, then I could trigger AFC and try to receive it.

Yeah exactly. You'll need to experiment with how to detect a packet. Normally a jump in RSSI that holds for a little bit would be a good criterion. But you want to get as close as possible to the noise floor so maybe you start trying if you find consecutive measurements that are atypically clustered at ceiling of the noise floor.

Quote
I might need to look for a step change at the beginning given it will need a certain S/N above ambient noise to receive anyway, have you a feel for that value? would 6dB do it?

Very dependent on bitrate. At 1200 baud it seems like its maybe 3-4 dB from this weekends field data. Which you likely couldn't detect because the larger RxBW adds more in noise. The higher the bitrate the more S/N you'll need.

Joe

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #77 on: January 16, 2017, 09:40:01 AM »
OK, I'm actually running at 12k bps (needed for low battery life). That means I'll need a greater jump, I'll start with 10dB. If this works well then I might even be able to not send the full extended preamble at all (or at least a much shortened version of it) and use the same technique when locked, that will help battery life. I'm going to give this a go today.
Mark.
Edit: It may not even be needed to detect a plateau after the jump, just a jump might be a good indication that a transmission has started. I'll try that first.
« Last Edit: January 16, 2017, 09:49:32 AM by perky »

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: CRC vs FEC
« Reply #78 on: January 16, 2017, 10:56:40 AM »
Quote
I'll start with 10dB

10 dB above RxBW noise floor sounds more than plenty. Now your AfcRxBw will likely be maybe 5x that. So that's around 7 dB more noise. So you're likely looking for 3 dB peaks at AfcRxBw.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #79 on: January 20, 2017, 06:57:53 PM »
I had a go at this with no luck. It sort of worked, but RSSI readings were jumping around too much to make it usable. However I have changed the sending and receiving packets to use the scheme of only going into rx when the tx is already sending a preamble and it's rock solid, very low PER (less than 1 in a thousand), and RSSI threshold is set to 255 for those.
Mark.

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: CRC vs FEC
« Reply #80 on: January 25, 2017, 03:09:48 AM »
Quote
However I have changed the sending and receiving packets to use the scheme of only going into rx when the tx is already sending a preamble and it's rock solid, very low PER (less than 1 in a thousand), and RSSI threshold is set to 255 for those.

Yeah that was a really good idea of yours. I now also switched to this approach for the AFC response. Previously I had done a ping first and used the RSSI of the response plus a few as thresh, but that never worked really well. It's finally coming together!

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #81 on: January 25, 2017, 06:08:44 AM »
It does appear to work remarkably well, and eliminates the RSSI threshold problem completely once locked. You do need tight absolute timing control of course, but you've invariably got a mechanism for that already especially if you're doing frequency hopping (I use the AVR's RTC counter driven by a 10ppm watch crystal for that).
Mark.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Re: CRC vs FEC
« Reply #82 on: January 25, 2017, 06:38:42 AM »
I wonder whether using a longer preamble would have a nearly equivalent effect in terms of reducing packet error rate?  It comes with the penalty of increased transmission time, but it would allow for some CSMA induced variability (if you're using CSMA, that is).

Also, I wonder if it's necessary to go to the extreme of setting the threshold all the way to 255, or whether setting a more conservative lower bound on RSSI (but still lower than anything expected) wouldn't be more of a happy medium.  Granted, in some cases that lower bound might still turn out to be 255, but not in the general case. Not sure  how that more conservative lower bound should be calculated, but I'm just floating the notion to see if it might be worth figuring out.  Perhaps it is yet another way to avoid false triggers and thereby reduce packet error rate still further.

[Edit:  The other nice thing about your method of not turning on the Rx until the preamble is expected is that it eliminates the 16ma of Rx current that would otherwise be wasted listening to nothing useful while the transmitting node is gearing up to respond with its next packet.  So, that's great icing on the cake, and possibly another good reason to do it. ]

Thanks for sharing! :)
« Last Edit: January 25, 2017, 06:57:54 AM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #83 on: January 25, 2017, 07:29:29 AM »
Unfortunately this is not a particularly good scheme for low power. From the receiver's perspective it will still be receiving waiting for the packet proper even if it's just a preamble and not waiting for an RSSI threshold, but the worst bit is when sending a reply because it needs to also send an extended preamble so that the other end can time its turning on of the receiver to coincide with that preamble. What you gain is a lack of dependence on RSSI threshold which means those transfers can be done right down to the noise floor plus the S/N needed to receive reliably, and there's no false triggering if a signal happened to come along which is above the threshold but below the real packet because the real packet would override it.

As for setting the RSSI threshold at 255, there's no point in not doing that if a preamble is already being transmitted. If you did you'd still need to choose a threshold that is at the noise floor to get the best out of it so nothing really gained by doing that.

Horses for courses, you don't get things for free in this life ;-)

Mark.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1298
  • Country: us
Re: CRC vs FEC
« Reply #84 on: January 25, 2017, 07:39:34 AM »
and there's no false triggering if a signal happened to come along which is above the threshold but below the real packet because the real packet would override it.

Ahhh...  Now I see the beauty in it.  Thanks.

perky

  • Hero Member
  • *****
  • Posts: 873
  • Country: gb
Re: CRC vs FEC
« Reply #85 on: January 25, 2017, 08:00:38 AM »
Yeah, in fact this I think is the primary reason I went from 1.2% two-way PER down to < 0.1%, I was getting false triggers due to a weak interferer which just happened to be above the RSSI threshold I'd set but below my real signal level.
Mark.