(Whoops… this post got mis-scheduled – fixed now)
Yesterday’s post illustrates an approach I’ve recently discovered for using the RF12 driver in a very simple way. This works in one very clear-cut usage scenario: sending wireless packets out periodically (without ACK).
Here’s the basic idiom:
What this does is completely ignore any incoming data, it just waits for permission to send when it needs to, and then waits for the send to complete by specifying “2” as last arg to rf12_sendStart().
No tricky loops, no idle polling, everything in one place.
With a few lines of extra code, the RFM12B module can be kept off while not used – saving roughly 15 mA:
And with just a few more lines using the Sleepy class, you get a low-power version which uses microamps instead of milliamps of current 99% of the time:
Note the addition of the watchdog interrupt handler, which is required when calling Sleepy::loseSomeTime().
The loseSomeTime() call can only be used with time ranges of 16..65000 milliseconds, and is not as accurate as when running normally. It’s trivial to extend the time range, of course – let’s say you want to power down for 10 minutes:
Another point to keep in mind with sleep modes, is that it isn’t always easy to keep track of time and allow other interrupts to wake you up again. See this recent post for a discussion about this.
But for simple Wireless Sensor Network node scenarios, the above idioms will give you a very easy way to turn your sketches into low-power mode which can support months of operation on a single set of batteries.
Update – it looks like the above RF12_sleep() arguments are completely wrong. They should be:
- rf12_sleep(N) turns the radio off with a wakeup timer enabled if N is 1..127
- rf12_sleep(0) turns the radio off
- rf12_sleep(-1) turns the radio back on
This list matches what is documented on the wiki page.
I’ve spent the last week working through all your blog posts from the last few years- lots of fun topics! There have been so many… I’m not sure I’m clear on the current state of the JeeLabs art for average current draw for a room node with a PIR sensor and nothing else. Is that summarized somewhere? Thanks! Also looking for good low-power PIR sensor available in US. Currently using Radio Shack 49-426, runs many months on a 9V (used 8 hr per day.)
Wow. If you have suggestions on how to make the 600+ posts more accessible and easier to skim, please let me know. As you say – lots of fun topics :)
Average current draw for room node w/ PIR is still a moving target – I’m seeing in the 100 µA range right now (latest / recent roomNode.pde sketch), almost half of which seems to be caused by the internal pull-up resistor needed to read-out the PIR open-collector output.
The PIR sensor I use for the Room Board kit was purchased in China, minimum quantity 100. Best low-power PIR I found before that was the ELV one in Germany, as used before in the kit. I’ve still got a few of those left, if you’re interested.
Note that running on 9V does not give you better lifetimes than running on 3.6..4.5V. A 3x AA pack is bound to give you a much better lifetime.
Surprising Addendum: My RS# 49-426 PIR alarm unit draws 105.4 uA +/- 0.2 uA from the 9V battery when switched OFF, and 103.2 uA +/- 0.2 uA when ON (!) according to my Tek DMM916 multimeter. So the off switch just disconnects the LED and alarm, not the PIR sensor. Sure enough, the current fluctuates +/- 25 uA when I wave my hand in front of it, when turned OFF. I’ll be darned.