Pin wake

Question

Hello,
I'm just starting experimentation with XBee modules, and would like some more information about wake options.
I would need to wake the module on every transition of several digital inputs, and from what I understood, pin wake :
- is only available for DI8
- is only available for falling edges
Is this correct ?
Is the behavior I need possible ? If yes, how ? If no, would it be available in some future version of the FW ?
My problem is to detect openings and closes of furniture in real time, thus cyclic wake option is not suitable here. Any suggestion would be welcomed.
Best regards and thanks in advance.

Answer 1

Hi,

I use the SLEEP_RQ pin (maybe DI8 I didn't verify the pinout) to wake-up a module. In my case, I configure the module in sleep mode 5 (SM), and also don't forget to set the sleep period to any value different from 0, for example SP64.

So, SLEEP_RQ should be at level 1 to allow the module to sleep after the default time to sleep value of 5 seconds and then set the pin to 0 to wake-up the module.

In my case I use SM5 to also awake it on RF activity but if you only use a 'local' wake-up, you can use sleep mode 1 or 2 instead.

hope it helps.


Message was edited by: alainbo

Answer 2

Hello, and thanks for your quick reply.

I had already experimented with all the various flavors of sleep modes, but unfortunately, and as I tried to explain in my original message, I couldn't get a complete fulfillment of my needs.

First of all, the pin driven sleep (SM1 or 2) is only available for DI8. Second problem is that it is level driven only. In fact, I was looking for a solution allowing to awake the module on any transition of the input signal, and optionally, on several inputs.

This last point is not really a show stopper since I can find a way to "OR" in some sense (not to be taken with the conventional logic acceptation) several inputs, and use the result to drive DI8, the main need being to detect any transition and awake based on this.

Thanks in advance for any suggestion.

Answer 3

Mode 4 says the device wakes periodically to check for RF. Mode 5 says it is possible to wake the device through the RF interface, and then says it acts the same as mode 4 with the exception of a pin wake capability. I am a little confused by waking on RF activity. Are you saying that in mode 5, RF wakes the device even if it is sleeping, or that the device wakes, checks for RF, and then sleeps? The docs are somewhat confusing on sleep and coordinators.

Answer 4

When the module is set for SM4 or SM5 the module will wake cyclically and look for its Coordinator to see of there is any data buffered for it. It does not have the ability to Sniff RF when it is sleeping. There is a good article that describes the intricacies of cyclic sleep in the Knowledgeable at:
http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=2193

Answer 5

What sort of time resolution do you need on your DIO lines? How much latency is too much?

The reason that I ask is that you could set the module to cyclic sleep and have it wake every given period of time, say 1 second (assuming 1 second is small enough time latency) and sample the DIO lines then go back to sleep.

If this is still not good enough and you need Pin Wake then you could do as you suggested; which is to build a logic gate that will toggle SLEEP_REQ when any one of your logic lines changes state.

Answer 6

Thanks for the response. I think the users manual description of SM=5 is misleading. From my bench testing, your response, and an online chat with support it is not possible to wake the device over the RF link. Darn. I was hoping to use SM5 to wake my remote micro when the other side of the link sent a message. While it seemed strange that the device could wakeup on RF and still conserve power, RFID's do it, so it was worth investigating.

Answer 7

Hi Travish,

I'm afraid cyclic sleep will not allow me to reach the maximum battery duration, since XBee S1 consumes "lots of" power when in idle mode (strangely, power consumption in idle mode is greater than in emit mode, according to the specs). So cyclic wake with a period short enough to give a low latency sounds like not really a good solution.

The current solution I'm working on is to handle input signals with a MCU (ATtiny13 for instance, since I know Atmel chips a bit), which can be configured to be awaken for any state change on several inputs (6), and which will toggle the sleep request of the XBee and forward it the input signals. This will work, but will require and extra chip, and I was looking for something without this.

Would a firmware customizing allow the feature I'm looking for ? If yes, would you have some sample of FW customization I could study to evaluate the difficulty of this approach ?

TIA for any feedback

Best regards

Eric