If I have a number of battery powered cyclic-sleep series 2 end devices, is it possible to get them to asynchronously just send their input states to a router or controller each time they wake up?
If each device wakes up say every 15 seconds, it seems crazy to have to pre-send a fetch message to each device every 15 seconds before they wake up.
I don’t see any serial activity from the controller when an end device wakes up, so the attached PC program doesn’t know a device is awake to be queried once it has woken up.
Is the only mode of operation available to me, to send a message to each end device after each receive of data, so it gets a message next time it wakes up? That seems like more overhead than is necessary.
I’m a newbie at this, so maybe it is a dumb question, but I’ve found the protocol more complex than I expected, and the official documentation is pretty sparse.
I’m not sure whether Periodic sampling is the option for this.
To enable periodic sampling set IR to non-zero value. Refer the ZigBee product manual for more details at the below link, http://ftp1.digi.com/support/documentation/90000976_L.pdf
(page number 96)
Of course the ideal solution is that you eliminate the polls altogether and allow your device to send a ‘response’ which was never polled for. If your central XBee (on the PC) is in API mode, then your PC application merely gathers all the incoming data, using the Xbee addressing to know which sensor sent the data. Your PC would also maintain a timer (some sense of time) to detect when sensors have NOT reported in as required. For example, I have tank level sensors which report in only once per hour (or day). It would be impossible to do what you do - attempt to ‘pre-poll’ for 24 hours expecting 99.99% poll failure.
To use the IR value, you set IR to 0xFFFF (max value) plus make sure at least 1 of the digital pins is in mode 3-5 (such as DIO3). This causes the sleeping device to send upon waking an IS message to the DH/DL destination (if 0/0, is the coordinator). Then ST must be high/long enough to allow your PC time to detect the message and issue its poll. Start with 5 seconds, but you might be able to lower this after success.
However, your battery life will suffer greatly in this design because:
you are sending a useless message (TX takes power)
the PC might not always reply fast enough, meaning a percentage of your samples are lost anyway.
this solution scales VERY badly, so what works with 1 sensor might not work with 10, and what works with 10 might not work with 50.
the XBee+device remains awake for longer than normally required - for example if ST=1 sec and the PC can poll in say 200msec, the Xbee+your sensor might be done at 300msec, but remain awake for 700 more msec, even sending 7 more beacon/polls to the parent for no purpose.
Do keep in mind that as long as the sleeping end-device is awake, it is sending RF polls to its parent every 100msec - see the PO (P-Oh not zero) setting.
Thanks for the replies, guys.
Yes, I guess I was looking for a ‘response’ which was never polled for, but which contains data as well as sender-address.
It seems such a simple thing, and one which would be commonly used in simple setups like a number of devices sending in temperatures periodically, or water levels or…
I’ll chalk up why it isn’t part of the protocol to the same logic as use of totally non-standard pin spacing which forces hobbyists to add the expense and size of a breakout board to every module. (I’m not using Arduinos, so shields are no advantage to me.)
I’m expecting to use of the order of 10 or less XBees, lynnl. So kavya & your suggestion is probably my answer, thanks. I’ll experiment with it.
-This is home automation at my house in its embryonic stages, so I can play around for a bit. Also in the mix is a weatherstation and some X10, all connected to the same Linux server PC as the XBee controller.
The Thread Low Power End Device is preconfigured to have both the MCU in low power state and the radio turned off most of the time to preserve battery life. The device wakes up periodically and polls its parent router for data addressed to it or optionally initiates sending data to the network by means of the parent router.
The low-power module (LPM) from the connectivity framework simplifies the process of putting a Kinetis-based wireless network node into the low-power or sleep modes. For the MKW41Z there are six low-power modes available.
By default, the Thread Low Power End Device uses Deep sleep mode 3, where:
MCU in LLS3 mode,Link layers remain idle,RAM is retained.
The wake-up sources are:
GPIO (push buttons),DCDC power switch (In buck mode),LPTMR with the 32kHz oscillator as clock source.
If my understanding is correct, enabling POWER_SAVING in compiler will make End Device go to sleep and wake up in the period of defined in POLL_RATE. But are there any ways to wake up End Device externally like using interrupt on a Pin?
No, in Zigbee, the parent Router must pull the end device for the end device to send data. It is a function of the IEEE standard and can’t be turned off.