Using ListenMode as Wakeup timer

[kobuki]

I have  a wild idea for a robust wake-up facility without using WDT, using listen mode in a somewhat more "inventive" way. When tuning my projects for RSSI, especially my OOK transceiver lib, I realised that having a low RSSI threshold generates noise. 100% guaranteed. What you need to do is:

 - set RSSI threshold to the lowest possible value (highest sensitivity, maybe activating sensitivity boost as well)
 - set bandwidth to very high, like 0.5 MHz
 - set listen mode to wake on RSSI only
 - other parameters are probably arbitrary, could leave them to Moteino defaults or your own

Setting ListenIdle will determine how often the mote wakes up. Setting ListenIdleCoef to 231, ListenIdleResol to 0b11 makes it 1 minute which is perfect for a TH mote, for example. After waking up, radio needs to be set to normal working parameters. Of course values can be juggled around for more possibilities.

[WhiteHare]

That's a clever idea.  Are you proposing to connect the RSSI pin to D3?  in essence, it would give you up to a 63 second wake-up timer instead of just an up to 8 second wakeup timer.

[kobuki]

Yes, that might be necessary. The module wakes up the MCU via DIO0 pin change interrupt on payload ready and other events, but in this case it might not play a role. The DS is hinting at several DIO pins having to do with RSSI, one of them might be a good candidate. Needs RTFM'ing and testing.

EDIT: fixed pin name

[TomWS]

@kobuki, as I read your idea, you're basically using the ListenMode idle interval as a wake up timer, having set the RSSI sensitivity so high that you're virtually guaranteed that a wakeup will occur during the RX interval. 

Is this correct?  If so, I don't understand the references to the other D pins on the radio.

Tom

[kobuki]

Correct. But since this idea is "new" and associated modes that can cause an interrupt haven't been explored yet, I'm not completely sure we don't need the other DIO pins. I'm reading the manual now and it seems that enabling continuous mode, no preamble, no sync word matching will fire an interrupt on DIO0 and thus waking up the mote in its default Moteino configuration. OTOH, DIO2 is the demotulator output in cont. mode and is guaranteed to generate noise with my proposed setup, that I already know.

[TomWS]

But getting back to the proposal, ISTM if you set up the radio in ListenMode (normal 'Moteino' setup isn't relevant in this case) AND set up the parameters as you've suggested, then there may not be a need for a separate device to generate a 'wakeup' burst or even a WDT, the radio will wake up the Mote simply due to RF noise at a time interval that is programmed via the ListenIdle parameter.  If true, that seems to have worthwhile application in a number of cases.

Tom

[kobuki]

Yes. Exactly this is what I propose. Atmega WDT turned off, shaving ~4 uA off the power budget. No external WDT is needed, except for this multipurpose Swiss Army knife-like thing called RFM69 transceiver

'Moteino' setup is important for everyone wishing to save power on it, since it means no change in HW is needed to achieve what I propose. In its off-the-shelf config, it should still be able to run well below 10 uA. In that case it does count.

[TomWS]

'Moteino' setup is important for everyone wishing to save power on it, since it means no change in HW is needed to achieve what I propose. In its off-the-shelf config, it should still be able to run well below 10 uA. In that case it does count.

My use of  the phrase "Moteino setup" specifically refers to the radio settings established in the RFM69 library, which need to be changed to support ListenMode.

Tom

[joelucid]

Yes. Exactly this is what I propose.

This is a good idea! I doubt it's really necessary to use continuous mode or OOK. Simply setting Rssithresh to 255 will probably guarantee Rssi detection under any setting. You can map Rssi to dio0 so no HW mods required either.

You could use this as general purpose wake up timer. Not only would it be lower power than the wdt but also much more accurate.

One feature of the burst collection approach is that you completely avoid collisions due to the server controlled polling of nodes. Combining your trick with the burst collection mechanism you could get both the lower power consumption of your approach plus the synchronization via the server. That effectively gives each Moteino an accurate synchronized clock.

Since we now have a synchronized clock we can have all nodes schedule their rx Windows during the same second every 5 minutes and get standby power consumption on a Moteino without regulator operating at 8mhz using internal rc clock down to 1200 nA. Not so shabby.

Joe

[kobuki]

Yeah, it simplifies a few things for your design, if it works reliably (I think it does). In listen mode, only the internal RC oscillator of the RFM69 is working, and it's probably as prone to frequency skew as any other. The module calibrates it on startup, but a forced calibration can be started any time. Felix's lib already has the function exactly for that. I guess a calibration cycle won't hurt every hour or so.

It would be nice to have an addition to the LPL lib (or in a separate one) that works similarly to the existing low-power support libraries, but instead of the internal Atmega WDT it uses the RFM69. I might even write it if you don't beat me to it

BTW, it's kobuki, not kabuki :x (They've completely unrelated origins.)

[TomWS]

Combining your trick with the burst collection mechanism you could get both the lower power consumption of your approach plus the synchronization via the server. That effectively gives each Moteino an accurate synchronized clock.

I'll admit that I haven't finished my morning coffee, but I'm not quite getting how this Wakeup timer gets synchronized with the server.

Tom

[joelucid]

I'll admit that I haven't finished my morning coffee, but I'm not quite getting how this Wakeup timer gets synchronized with the server.

The assumption is that if you regularly recalibrate the radio's RC sensor like I did in this prototype (https://lowpowerlab.com/forum/index.php/topic,1269.msg8600.html#msg8600) you get a fairly accurate timer. Now you only need to periodically send a current timestamp to the nodes and they can maintain a synchronized clock fairly well.

In the above prototype I used the radio as timer to schedule the next RX window for all motes during the same 3 second window in a 5 min period instead of waking RX once every three seconds. However if I missed the burst the timing would become unaligned. However with the new method we can get the wakeup with certainty and simply start another 5 min listen mode just before the window opens.

Or as I said in my second post we could move to modified ACKs and just send system time during the ACK.

[TomWS]

Great!  Thanks for the explanation!

Tom

[joelucid]

This works well as expected. Attached is a quick prototype. Currently only supports delays up to 65 seconds (the radio doesn't support more natively, longer periods need to be pieced together).

Interestingly I need to wait until the third RSSI interrupt. I already receive two during the initial RX window which seems to indicate that the radio actually starts a second RSSI detection after deciding to stay in RX during the 1st RX window.

Just use like this for a 30 second sleep period:

   RFM69Listener::delay( radio, 30000 );
   reinitializeRadio();

reinitializeRadio should be your code to restore the Radio to it's normal condition.

Code attached.

[WhiteHare]

Great!  I gather you're using
radio.writeReg( REG_DIOMAPPING1, RF_DIOMAPPING1_DIO0_11 );
to map RSSI to DIO0?  That's a definite improvement over the earlier idea genesis, because with only two external interrupt pins on the ATMEGA328P, it's definitely better to keep one free for other purposes (like, for instance, connecting to a motion sensor).  Touché!