Author Topic: RSSI sensitivity issues with Listen Mode  (Read 5983 times)

joelucid

  • Hero Member
  • *****
  • Posts: 868
RSSI sensitivity issues with Listen Mode
« on: November 26, 2015, 11:44:16 AM »
Quote
Possible.

Good thing I implemented a little command last weekend to test at which RSSI threshold a Mote gets woken up by noise. I tested it during  the weekend and found no issues (>185, my threshold is 180). However I just ran it again and it came in <180 multiple times. So I'm lowering the threshold to 160.

This could explain the power consumption and possibly the spikes.

New version already deployed. Let's see if this improves things.

It might make sense to dynamically tune the RSSI threshold for listen mode in the future.

My theory is now that the listen bug is really this general: when a mote detects RSSI during its rx window it will not leave rx until it finds a packet or RSSI drops below the threshold again. In other words the rx timeout only applies after RSSI has dropped. That's really bad!
« Last Edit: November 28, 2015, 11:04:18 AM by joelucid »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Tino, Listen Mode discussion
« Reply #1 on: November 26, 2015, 12:51:30 PM »
I think we should change our listen mode implementation such that we only use it to detect RSSI and then control the rest from the 328p. That way we directly detect false awakenings and we can work around the listen mode bug. But we still get the same low power consumption.

So we map RSSI to DIO0. When the interrupt hits we wait a short period of time until payload ready. If its not we notice a false awakening, abort listen mode and enter it again.

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Tino, Listen Mode discussion
« Reply #2 on: November 26, 2015, 01:35:26 PM »
I can't remember how your code sets up registers for the listen mode noise wake-up timer, but my original idea was to use continuous mode. This would alleviate the problems associated with the interrupts initiated by the sequencer. And I also think that mapping the RSSI to DIO0 would be the right method.

(BTW, shouldn't we move this convo to the designated board?)
« Last Edit: November 26, 2015, 01:40:23 PM by kobuki »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Tino, Listen Mode discussion
« Reply #3 on: November 27, 2015, 02:30:20 AM »
Quote
I can't remember how your code sets up registers for the listen mode noise wake-up timer, but my original idea was to use continuous mode. This would alleviate the problems associated with the interrupts initiated by the sequencer. And I also think that mapping the RSSI to DIO0 would be the right method.

I use packet mode both for the timer and for server initiated wakeups. Which has the advantage of not having to reprogram the radio between Rssi detection an packet reception. I understand the interrupts better now: you get one for plllock before the radio is in rx state as that also goes to dio0 if you map Rssi there.

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Tino, Listen Mode discussion
« Reply #4 on: November 27, 2015, 04:22:16 AM »
Well, the mode setting is only a couple of additional registers to set/reset and might rid you of other problems. Haven't tried myself though. If I'll ever get the time to spend time on this, I'll try this as well. OTOH, do I get you right: you now use this very high sensitivity value for reception as well? I had problems with very low RSSI threshold values, catching a lot of unneeded junk and had to drop a lot of spurious packets based on other measures like CRC. In this situation if one's not careful enough at choosing preamble and sync word parameters, the module can easily end up firing an endless stream of interrupts on the ATMega (seen it, been there).

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Tino, Listen Mode discussion
« Reply #5 on: November 27, 2015, 11:42:51 AM »
Quote
you now use this very high sensitivity value for reception as well?

No, I used to have a threshold of -90 for rssi for reception. As quick workaround I've now raised that to -80 because of the issues with the Tino's in the weekend home. Mapping RSSI to DIO0 instead of "payload available" will allow me to detect when i get a false RSSI detection. I can then automatically adjust the threshold to minimize false detections.

kobuki

  • Sr. Member
  • ****
  • Posts: 289
Re: Tino, Listen Mode discussion
« Reply #6 on: November 27, 2015, 11:46:59 AM »
I think it's a somewhat roundabout way and has some empirical assumptions that makes it a little less robust (in my eyes at least) - but for everyone his own solution, I'm curious about yours!

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Tino, Listen Mode discussion
« Reply #7 on: November 28, 2015, 05:57:40 AM »
Quote
Anyhow, for the RFM69, perhaps a solution would be to hop to a different frequency on the hope the interference/noise  isn't a problem there?

Actually I already use a different frequency for listen mode than for normal traffic. I do this to enable traffic on the normal channel while the wakeup burst is ongoing. I think these problems are really to be expected: background noise will change due to all kinds of environmental influences. The system needs to be robust against those changes.

It's non-trivial: you cannot set the threshold too high because the mote will never wake up again. So just increasing it will not work. I think it's a combination of recording sender RSSI and keeping a good safety margin to that, monitoring and reacting to false awakenings and finally keeping the costs of false awakenings down by working around the bug.

Kobuki is probably right: for less enterprising souls this might be too challenging. But for me the interactivity of listen mode is clearly worth it. However the noise wakeup approach is also certainly valid and I will probably support it for nodes when interactivity is not needed.

Joe

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: Tino, Listen Mode discussion
« Reply #8 on: November 28, 2015, 06:02:02 AM »
Quote
Or maybe it's something with this particular pcb since this Tino also seems to draw more power than the others.

I figured out another aspect of the difference: The weekend home is only heated when we're there (very rarely recently). The colder it gets the lower vcc the Tino measures. You can clearly see this in the two short hills in the chart where we were there. So the overly steep decline in vcc is at least to some extent due to ambient temperature declining from ~20 degrees celsius to around 7 now.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: RSSI sensitivity issues with Listen Mode
« Reply #9 on: December 07, 2015, 02:37:12 PM »
As an alternate failsafe, I do wonder whether some of the newer RTC's  could serve as a watchdog for the RFM69 getting stuck in an extended Rx while in Listen Mode (the scenario being discussed here).  Some of them (e.g. MCP795W22) claim to be able to do smart event detection by programmatically looking for a particular pattern of io signals.  For instance, the MCP795W22 consumes <1uA of current even while running, so if it could do the job, a smart watchdog might impose very little additional energy burden.

« Last Edit: February 04, 2016, 04:34:39 AM by WhiteHare »

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: RSSI sensitivity issues with Listen Mode
« Reply #10 on: December 08, 2015, 04:51:09 PM »
Quote
As an alternate failsafe, I do wonder whether some of the newer RTC's  could serve as a watchdog for the RFM69 getting stuck in an extended Rx while in Listen Mode (the scenario being discussed here).

I still think this can be handled by the rfm69/328p itself. I haven't done any more work in the space since increasing the Rssi threshold solved my problem. Voltage compared to 2 weeks ago literally unchanged.

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: RSSI sensitivity issues with Listen Mode
« Reply #11 on: December 18, 2015, 03:24:36 PM »
Turns out the PIR sensor (https://lowpowerlab.com/forum/index.php/topic,1478.0.html) was an excellent test case for this problem: triggering the 433mhz outlet requires a fairly long OOK signal and that triggers RSSI detection in ListenMode nodes.

I've implemented the workaround discussed here. I now map the RSSI interrupt to DIO0 and select RF_LISTEN1_END_10 which causes listen mode to stop when RSSI is detected. In the interrupt handler I wait 8ms for PAYLOADREADY. And finally I restart listen mode.

Obviously doing this in the interrupt handler is far from ideal. But I really don't want the radio hanging in RX while some sensor library is spinning in delay().

This is now robust against noise. And I can measure the number of false RSSI detections.

One drawback is the number of IRQ's fired. For every listen period I get two interrupts when no signal is detected. And I even get two with RF_IRQFLAGS1_RSSI set if there is a signal. Luckily it's possible to determine the one that counts: RF_IRQFLAGS1_RSSI needs to be set and REG_OPMODE needs to be RF_OPMODE_RECEIVER.

The frequent interrupts make it a bit challenging to manage interrupt handling. Where one might have used LowPower.powerDown( SLEEP_4S, ..., ...) previously that code now always returns when the listen window hits. But I have it sorted out now.

I'll post some code in a few days if this keeps working.

Joe

joelucid

  • Hero Member
  • *****
  • Posts: 868
Re: RSSI sensitivity issues with Listen Mode
« Reply #12 on: December 25, 2015, 04:10:59 PM »
This is working pretty well and I'm actually finding a big advantage with this method: not only do I get an Irq whenever listen mode receives a burst. But I also get a pll lock interrupt every 2.8 seconds regardless of whether the server is sending anything. The benefits are obvious: I can now spend 3uA on listen mode and get a regular wdt style wake up for free.

The one area are where this will really help is a project that Tom has inspired me to: the reestablishment of the 9v battery. Everybody hates it: a Moteino powered with 9v battery burns 2/3rds of all energy in the LDO. And compared to 2xaaa or coin cells size is just not convincing.

But 9v limno2 batteries have about the highest energy density available and are uniquely qualified for driving bistable sprinkler valves. If only we could efficiently convert that voltage down to the optimum 2.0v sleep voltage of a 328p. We would get an estimated battery life in the centuries with listen mode enabled. Regular buck converters won't work but I think there's a solution.

Stay tuned for more details ...

Merry xmas to all.