I am using a hardware version 1941 Series 2 module, firmware 1347 (ZNet 2.5 router/end device). First of all, my Series 2 modules are old. They seem to work with this firmware version (1347/1147), is this hardware/firmware compatible? Do I have other options for this hardware such as Digimesh?
I am developing and end device that will need to wake at fixed intervals (5-15 minutes) and handle requests from the coordinator. I plan to sleep my CPU as well during this period. According to the documentation, it appears that I could use pin 13 to wake my CPU when the XBee module comes out of sleep. This would work for me to a point, but it’s not the most efficient way to conserve power and I’m looking for something a little tighter. For instance, let’s say the coordinator is unavailable for a few hours. I would like to be able to have the XBee module awake, waiting for the PAN rather than have my CPU awake and idle when there’s nothing to do. How might I trigger an interrupt based upon receiving data from the module? This will be a battery-powered application obviously, so every mA matters
The series 2 module supports ZNet 2.5 firmware (including 1x47) and ZB firmware (based on the ZigBee PRO feature set). DigiMesh is supported on other XBee platforms, not on series 2.
Regarding your end device design, depending on your application, there are a couple ways to accomplish what you are requesting.
#1 - The XBee could wake every 28 seconds and send a quick poll request to its parent to check for new RF data. If none is present, the XBee will return to sleep immediately. By setting SN to a large value, the On/Sleep pin would remain low (keeping your external CPU asleep) until SN wake cycles occur, or until RF data is received.
#2 - If the XBee must sleep for a long time (i.e. several minutes), you will have to architect things slightly different. In ZB/ZNet, a parent can only buffer data up to 30 seconds. If an end device sleeps longer than 30 seconds, it is difficult to guarantee reliable data delivery to the end device. A good approach to work around this is to have the end device notify the coordinator when it finally wakes from sleep. For example, you could set IR on the end device to cause it to send an IO sample when it wakes. When the coordinator receives this IO sample, it can send data to the end device, knowing it will be awake for ST time. Once the coordinator sends data to the end device, it can send a remote ATSI command to the end device to put it to sleep immediately. (Your coordinator should use API firmware.)
Also, you should strongly consider using ZB firmware. It offers a number of improvements over ZNet when working with end devices.
Hope that helps!
I appreciate your response. I typed up a long reply of my own, but decided it was probably too much information. I’m going to try coordinating sleep periods between my coordinator and end devices, using the end device CPU to sleep the XBee module via ON/SLEEP.
Actually, I should have said DTR/SLEEP_RQ.