Hi all: I’m getting a really strange problem that I try to accurately describe, so sorry in advance for this long post.
Im geting a problem with some LT(H) end-devices working in sleep mode: They are programmed to sleep for 5 minutes and then waking up and sampling for 500 ms. They work fine but some times they start to continuously sending samples as they were always awake.
My coordinator has the serial gateway access enabled, so my programs interface with the xbee network not running in the whole coordinator but in other computer that establishes a telnet connection with the coordinator. When the tricky end-devices becomes sending samples continuously, I disable the serial gateway access, reboot, enable it and reboot the coordinator again and the problem solves, at least for some hours or (luckily) days.
In the same network there are other end-devices working in sleep mode but this problem only is present in three specific LT(H) end-devices. The only possible difference is that the tricky end-devices reach the coordinator via one router.
I’m pretty sure that the problem is located in the sensor and not in the gateway/router/end program for these reasons:
Sensors suffering the problem become out of battery much before that other LTH sensors not suffering this problem. I suppose that, since they start transmitting continuously, battery consumption is higher.
There’s a fancy demo of the previous statement: I plot received sensor temperature values each 5 minutes. When end-devices start their non-stop transmissions, temperature values change in 1C-2C, then I reboot coordinator, problem become solved and at the same time sensor temperature returns to its expected values. I suppose that continuous transmissions, and thus higher battery consumption, forces a voltage dropout and then temperature sensor read errors.
What confuses me, among the whole problem itself, is why it becomes solved when rebooting the coordinator if the problem is located in the sensor?
All devices in the network (coordinator, routers and sensors) use the last firmware release, specifically the API version of each firmware. After upgrading firmware, problem disappeared for weeks and I though it was solved. Now I think that the problem went away for some time because I rebooted all LT(H) sensors after upgrading firmware, but this term has not been yet confirmed, ie, I’ve not compared the way rebooted and non-rebooted end-devices work.
Long post, I know. My aim carefully describing it is both helping other people with similiar problems and trying to get a solution, though I think it must be a firmware bug and it might be submitted to the online support.
No error for three days with any improvement in the network addressed to solve it. Simply it’s gone.
It seems that error happens in periods when network seems unstable: since I periodically monitor node availability requesting Node Receive signal strength (similar to pinging LAN hosts) I can detect when network devices fail in their responses. Anyway this term cannot be confirmed in a solid way.
Once more Lynn was right: Firmware version outdated.
Even being quite sure that all sensors ran with the last firmware version (2xa7) one of them was not updated. After updating it now is running right for weeks.
Starting on friday one of my sleeping end-devices started to send data with no end (it might send one poll each 5 minutes). Now the device is in battery-low state (something logic on the other side)
What is new is that the end-device has been able to leave that state after three days in it. Until now I had to reset the coordinator in order to fix the problem in the end-device.
This is very frustrating, battery is depleted after using it for one month.
I have not seen your problem (& did not see where you mentioned the firmware version), but you might not want to have IR=ST, as technically you are asking the unit to go to sleep at about the same time as you take a sample.
Best case, you should be getting 2 samples each wake period - once the instant it wakes and the second IR=500 msec later just as it prepares to sleep. However, you have a race condition between IR and ST for the second sample.
You should really set IR to 0xFFFF, since the sensor WILL take one sample when it wakes (so at time 0x000), and although it does start a timer to send another in 65 seconds, you go to sleep at ST=500, so that timer aborts.
If you wish to delay the sample a few msec from waking to let the sensors settle, then set WH=50 or 100, which delays the sample for 50 or 100msec respectively.
As far as I know, and based on my notes, these devices use the last firmware release (namely 2xA7). I remember upgrading them since they came with an older firmware and, at first, I thought it might be the cause (in fact they worked fine for weeks after upgrading). Anyway I’m going to check it today.
I’m going to follow your advice about IR and setting it to 0xFFFF since, by now, they only send one read (the first one).
