Adding new end device (XBee S2) to existing ZB network

Question

Hello
I have been running a ZB network successfully for some time with coordinator in API(1) mode and three routers in AT mode. All are Series 2
I wanted to experiment with end device sleep for the first time, so I set up one coordinator in API and one end device in AT.
The sleep setup was mode 5 (cyclic with pin wake), SP = 20000-mS, SN = 0xF (5-minute cyclic).
This worked nicely on it's own PAN ID.
There were a few erratic cyclic times (too short or too long), so I thought it might improve things if I moved it to the existing network.
I changed the PAN to the existing PAN and the data frames started coming through.
However, the end device cyclic times weren't 5-minutes any more, but 1-minute 23-seconds, obviously not the set time - the pin awake was not being used.
Changing the end device over to the original coordinator (PAN changed) restored the correct timing.
I been over all the settings, reset devices, but every time it is used on the larger network, the cyclic time goes to the wrong timing.
I would like to get an end device working properly, but I'm stumped at the moment.
Any suggestions please?

Answer 1

Are you setting the Parents SP and SN times to match the end devices?

Comments

Hello mvut
I may have the answer to this one and am currently testing.
As the end device was going to be battery powered, I set up a supply voltage threshold equivalent to about 2.7-V (powering with two "C" alkalines at 3.1-V).
I had noticed that while I had the device in sleep on a bench power supply, every 23-seconds or so, the PSU flagged an over-current - I don't know why it does this with sleep set to 5-minutes.
I decided that whatever this was, it was pulling Vcc below the threshold and triggering a transmission. I took V+ (threshold) out by setting back to the default 0 and the problem disappeared, all back to normal.
I am currently testing by using a plug-top PSU and 3.3-V regulator - if this is OK overnight, I will revert to the "C" cells and test again. I will also scope the Vcc pin to see if there really is a regular dip in voltage. Guessing, the frequency is about every 23 seconds.
Are you aware of any reason why in sleep, the end device might do this?
I think the reason why the behaviour changed when I tested it with another coordinator was the fact that the end device was being powered through a USB adaptor which wasn't being pulled down by the end device.
Instead of using the V+ setting, I might just use an analogue input to monitor the Vcc with a voltage divider and avoid the transmission triggering.
I might also try a 4.5-V battery pack with one of the high efficiency buck/boost regulators. I have a single AA cell torch with a built-in regulator to power the white LED. I might have a look to see how that's done.
SN and SP are set to the 5-minute values on the coordinator, but I'm not sure about the routers. I followed Faludi's advice (BWSN book) that for this sort of application, SN and SP weren't strictly necessary, just good practice.
I'll let you know how I get on.
Cheers

---

That would be the maximum SP time frame that is supported. It is also used to poll the parent to keep the module from being kicked off of the network when long sleep times are used.

---

So, 0xAF0 (2800 x 10) milliseconds for SP means that the end device transmits to the coordinator every 28-seconds, regardless of SN to say, "I'm still here"
My settings were SP = 0x7D0 (2000 x 10) milliseconds and SN = 0xF, giving a sleep time of 15 x 20000 milliseconds (5-minutes).
My guess was 23-seconds for the dip in Vcc so it all adds up.
The polling transmit was enough to take the Vcc below the threshold and kick-off an "unscheduled" transmit, not the sleep period.
I have just checked it again, now on battery, and the timings are fine at about 4-minutes 53-seconds.
Any preferences for a power supply on battery?
Is an analogue with say 100k + 200k voltage divider OK?
I make that about 11uA at 3.3-V
Thanks for the explanation

---

As long as you stay above the VCC limits and your power battery can provide the current you are fine. But you may want to add a Cap on VCC just to keep the voltage drop from being too much as the battery dies.