Waking up on packet received... Has anybody tried this?

Jee Labs Talk » Batteries & power

Waking up on packet received... Has anybody tried this?

(7 posts) (4 voices)

Tags:

No tags yet.

gotcha

If RF12B is not sleeping, there should be no problem, at least in theory, on waking up the uC by the RF12B's interrupt (FIFO queued 8 bits). But... can the RF12B module be put in some low-power mode and keep generating these (RX) interrupts?

It would seem that the RF12B is based on a Si4421 ( See post #68 on this url http://blog.strobotics.com.au/2008/06/17/rfm12-tutorial-part2/ ) BTW, does anybody confirm this?
Here is the URL for it http://www.silabs.com/PRODUCTS/WIRELESS/EZRADIO/Pages/Si442021.aspx
This is far more detailed than the HopeRF datasheet!

It should be thus possible to enable the RX chain (RFRECEIVERON 0x82D9 on RF12.h?) with everything else shutdown... what would be the current drawn in that case? The Si4421 seems to draw 12mA as per datasheet, quite an amount of electrons per second! Can anybody confirm empirically?

Can more blocks be disabled in order to lower the current drawn? Perhaps, but nothing seems to show this...

May be the best (or at least simplest) idea would be to have everything sleeping, wakeup periodically and just poll it's peers for new data. Not exactly the same thing, but at least current saving!

Posted 06/03/2010 15:54:28
jcw

Keeping reception active requires quite a bit of power, with any currently common RF technology, as far as I know.

Best you can do is probably TDM and TDMA, which don't need the receiver to be on all the time:
http://en.wikipedia.org/wiki/Time-divisionmultiplexing
http://en.wikipedia.org/wiki/Timedivisionmultipleaccess

I.e. maintain a clock in each node, and use a central node to assign specific time slots to each node. A node could wake up say once every second, and listen for packets for 10 msec, at the exact time when packets for that node may be sent. If the central node acks the time drift back to each sending node, then all the nodes can stay permanently in sync.

Posted 07/03/2010 01:24:44
gotcha

Yep, TDMA and TDM would certainly reduce power consumption. But it is not without paying the price of complexity and reduced reliability.

As somebody said ;-) "This requires a central coordinator, as well as pretty accurately keeping track of time (which is non-trivial with RC-based watchdog timers for sleep modes used with low-power nodes!)."

An interesting thread (http://talk.jeelabs.net/topic/6) discusses time frame sizes and other related topics. Its main contributor (seaton) pushed the initiative of a mesh protocol on Contiki OS, but progress seems to have slowed down by September 2009. (http://code.google.com/p/strobit/wiki/WidgetMesh)

Jean-Claude, did you give this communications scheme (TDM/TDMA on RFM12B) a try?

Posted 07/03/2010 22:51:05
siliconfarmer

I agree with Jean-Claude, every RF technology I know of uses significant power (on the order of transmit power) to have the receive chain active. It is a moderately complex chain of analog and dsp blocks to recover the RF signal enough to recognize data vs noise, and then more digital circuits to filter the data to packets of interest. That's why so many protocols rely on beacons and time slots.

But TD methods are somewhat complex. BTW, I am no fan of mesh, as its even more complex than TDM/A. Frankly, its easier and cheaper to build radios with sufficient range than to muck around with problematic mesh protocols.

I am playing with a star network with the central node on line power, always listening for packets. Nodes decide when it is convenient to wake up and send a packet to the central node. The Central node replies immediately with a NAK if no data is available, or the data that it has queued for the node.

Sensors can request data on almost whatever period is necessary, and the period is completely determined by the sensor node (up to the limits of CSMA), not the central node.

Because receive is around the power of transmit, if you have to wake up and listen for a while (due to clock drift) for the next beacon, that will use more power that waking, doing a quick transmit, and listening for a very limited time for the response.

If you have nodes that only need to communicate on the order of tens of minutes or perhaps hours, vs having to listen to beacons every few minutes just in order to stay in sync, then the power savings become substantial. It can mean years of battery power versus weeks or a few months.

Posted 10/03/2010 05:47:46
jcw

Nod, nod. With 868/915 MHz, the range is quite a lot better than 2.4 GHz, AFAICT. So where Zigbee needs to use meshes to get around the house and through all walls, I get a substantial range with RFM12B's using just point-to-point communication. Mesh would be great, but it's a major task - and it's not as important for JeeNodes as one might assume. I've had a ZigBee based network of PlugWise modules break down within a few meters / 1 concrete wall, whereas JeeNodes will go 10..20m and cross several walls and floors.

As for TDMA, I'd like to try it out one day (if no-one else beats me to it) - not so much to reduce power, but to reduce collisions and reliably allow more devices to operate in the same space. Same for frequency hopping.

In the RF12demo code I'm using on JeeLinks, there is still some unallocated room in the on-board 8 Mb flash memory. The idea I'd like to work out, is to "prepare" acks for sending back to each of the 30 or so possible nodes in a netgroup. So to send something to a remote node, you'd store it in the JeeLink, which then includes that data in the ack the next time a remote node makes contact (and wants an ACK). This way, bi-directional comms is possible without having remote nodes permanently in receive mode.

Posted 10/03/2010 12:01:51
sysrun

Seen this? : http://www.chip45.com/info/idwarf-net.html

Posted 10/03/2010 14:29:28
jcw

Yep. Closed source - driver only included as binary library, at least last time I checked.

Posted 11/03/2010 00:02:51