Sending periodic samples (IR) from temperature, humidity, or other sensors using an XBee module is simple. There are lots of examples online, and it works regardless if the device is always-on, or just wakes up every once in a while (SM) to send a sample before going back to sleep, allowing it to run for weeks and months on batteries.
Even easier is using change-detect (IC) to transmit a message when an IO pin changes state. For example, you can trigger the transmission of IO samples when a door opens or closes using a magnetic reed switch. All is well until you try to power your simple trigger-switch from a battery, because change-detect only works when the XBee is awake. Now what?
The following assumes the reader is familiar with XBee devices, API-mode, X-CTU software, etc. I’m using and linking to XBee Pro 900 HP documentation, but the features and settings should apply equally to other XBee modules.
Don’t Over Complicate
XBees have several different sleep modes, but for a trigger-switch that spends most of the time sleeping, this is not a job for coordinated synchronous sleeping networks built with routers, co-ordinators, and end-devices. Periodically waking and sampling isn’t effective either, as it could miss the trigger unless you sample so often you kill your battery.
Using pin-sleep mode, a trigger-event might be able to drive SLEEP_RQ in some cases, but attempting this for a momentary switch leads to all sorts of ridiculous scenarios (not that I tried or considered them or anything…):
- Wake a microprocessor using an external interrupt (the trigger) which drives SLEEP_RQ to wake the XBee, send a message, then put everything back to sleep.
- Using some kind of delay, timer, watchdog supervisor, TSP511X, or SCR arrangement to latch SLEEP_RQ low long enough to do something useful.
Assuming you come up with the right arrangement to keep the XBee awake (very hard for momentary switches), the challenge is to force some kind of transmission quickly before it goes back to sleep. Such a solution is far too complicated for just a simple switch!
Commissioning a Solution
None of the Digi documentation on the sleep habits of XBees references this, but look at how a commissioning pushbutton works when an XBee is in asynchronous sleep:
Wakes the module for 30 seconds. Immediately sends a Node Identification broadcast transmission. All devices that receive this transmission blink their Associate LED rapidly for 1 second. All API devices that receive this transmission send a Node Identification Indicator frame – 0x95 out their serial interface.
A remote XBee rapidly flashing in response to a trigger-event doesn’t seem too useful, but a remote XBee in API mode hooked to a microprocessor, node-red, or xbmq is now capable of receiving an NI frame for each and every trigger event from an otherwise sleeping XBee just by connecting the trigger to DIO0. The 30-second wake time does waste some precious milliamp-hours, but that time can be used to do something useful, like toggle or read IO pins or query the system-voltage (%V), which can be very useful information for battery powered nodes.
Example
Here’s how to build a super-simple battery powered XBee node that transmits an NI frame whenever a switch is closed.
Battery powered sleeping XBee. Wake-up-and-transmit.
The forward voltage of the diode is selected to drop the battery voltage to a safe range for the XBee (3.1V – 3.6V). If using 3 x AA(A) batteries, use a diode with a forward voltage of 0.9V. Any other arrangement that provides proper voltage to the XBee can be used instead.
If you want to program the XBee remotely you’ll need to temporarily pull SLEEP_RQ (9) low so you may want to include a switch or a jumper in your prototype.
Adding LEDs and enabling ASSOC and RSSI (D5=1, PO=1) is useful to see when the device is awake and when it is transmitting, but will add further drain on the battery.
XBee Programming
- ID = your-network-ID, must be the same on transmitter and receiver
- AP = [1, 2]
- SM = 1
- NI = some string that identifies the device, included in the NI frame
- CE = 2
- DO = 1
Test Setup
- Program one XBee and wire up according to the schematic
- Program a second XBee with the same ID and AP.
- Connect the second XBee to XCTU.
- ‘Discover radio nodes in the same network’ to verify you can see the first XBee.
- Switch to ‘Console Working Mode’ and ‘Open the serial connection’
- Close the switch connected to the first XBee
- Verify a Node Identification Indicator frame is received, and view the frame details to see the address and NI of the sender.
Conclusion
It would be great if XBee IO pins had a wake-on-change feature, similar to the wake-on-interrupt sleep modes of most microprocessors, but if you’re using API and pin-sleep modes, and just want a simple notification of an event, the commissioning button seems to do the trick for low-power, sleeping nodes.