This is a long post, so please be patient when you read it. :)
Here's my question:
Is it possible for orphaned ED (Z-Stack 2.5.0 - CC2531 devices) to sniff for potential parent
instead of constantly sending rejoin requests?
Here's the long description:
The reason I'm asking this question is of course to reduce power consumption to a possible minimum.
I've implemented a simple state machine, in my application, according to the following policy:
We have a set-up of 20 routers and 35 static (non roaming) EDs at client's site. It's an office like site with
concrete (rocket blowup impenetrable) walls. :) Each router is mounted at each entrance (above the door)
of an office room, inside every room there is/are single/2 EDs that is/are mounted on a wall. We are
experiencing bad RF performance in several rooms (caused by PCB printed antennas, possibly ill RF design
and concrete walls). The side effect of bad RF performance is frequent orphaning of EDs which leads to a
frequent high amount of current (~28mA) draw. Long story short, when the RF link is good, ED can work for
~6 months (even more) before we need to replace 2 AAA batteries with fresh ones, where fresh batteries in
the same device with the same FW can last for ~3 weeks (before we need to replace'em) when the the RF
link is poor.
ED (user), for some amount of time (can be several minutes to several days), have no network to
communicate with, hence it's found in orphan state and must not transmit or search (too often) for
a parent in order to extend battery life. However once a user enters to a site with ZigBee network coverage,
the ED have to join to this network and transmit/receive X/Y amount of data. It have to find this network
without any intervention from a user (at this stage no push buttons are allowed). Moreover, once the device
is inside the area of this site, it can rapidly move from one router to another (user is running). Eventually
the user will leave this site, at this point ED must (somehow) to "understand" that it's not inside network
coverage and start to manage it's power consumption in an efficient way again.
I think that's all I have to say at this moment.
If you'r reading this line (and not cursing me for my English) I want to thank you for your time and patience. :)
Again, please excuse me for the long post.
I'll be glad to hear your professional opinion, insights, suggestions, anything useful :)
i have read through your words,but i can't understand them all blame to my bad eng.
what's your mean by saying "sniff "?
By "sniff" I mean something like turning on Receiver and only listen, w/o actually transmitting.
Receiving packets consumes less power then transmitting.
i see! but parent can't know that the end device change to a orphan,so we don't know when to inform the end device(send a message to enddevice).
Well, I don't want the parent to inform end device.
I do want the End Device to make "smart" conclusions in such cases, in other words, I want to write some
sort of intelligent algorithm. Which, I believe, is possible to do with the help of ideas and experience of other
people plus my own.
i am not sure i have understood your words completely.
if yes.i have some suggests:
1、you said the ED should "know" the coverage of the specific network.i think you can judge it by checking nwkdisclist where all network shown.
2、before go to sleep.then you can close the DPOLL so that halt the join request,in this way,there is no data communicate until you restart the DPOLL which can scan the network again.
Any other thoughts?
I want to update this post with additional info:
Following image is an oscope screenshot of voltage measured on 2.7Ohm resistor connected
serially from 2.8V source to our custom PCB with cc2531 on it.
When CC2531 is in sleep mode, the drawn current is ~12uAmpers; An onboard Hall effect sensor
draws about 11uAmpers and the remain current is drawn by CC2531 IC.
The ~6 Seconds window (marked with red rectangle) happens when End Device goes into orphan
state, the peak-to-peak (without added noise) amplitude of the signal is about 75mV (which means
current draw of ~28mAmps).
Well, the practical question (from my original post) is there any possibility in Z-stack just to sniff for
a new parent, potentially avoiding excessive power consumption like presented on the screenshot?
Have you managed to find a solution for this. I am currently trying to do something very similar. I am using the ZNP mini kits as my end nodes running Zstack 2.5.0 on the CC2530. I want to stop the end node batteries from being completely drained if the coordinator looses power. I have noticed that if I turn my coordinator off and forget to remove the end node batteries on friday night when I leave the office then the end node batteries are flat on Monday morning. There must be something I can do to reduce the drain on a battery as power cuts are not exactly unexpected and it must be possible to reduce the current consumption in these circumstances.
I tried tuurning the radio off but found that the CC240 did not go to sleep in these circumstances and the current drain was 1.5mA which is still better than the 28mA drain that you get if the end node is continually looking to join a network.
Thanks for any advice
What is this CC240 device??
Sorry typing error I am using an MSP430F2275 for the application code and the Zstack is on a CC2530. Hope this clarifies things.
I am using the TI ZNP Mini kit for my end node. I have been measuring my current consumption using the same method outlined in the Power Management For The CC2530.pdf document provided by TI with their zStack download. I need to be able to find a way of stopping the CC2530 draining its battery when the coordinator looses power.
So far I have had get the MSP430 to hold the CC2530 in reset when it knows that the ZDO_STATE_CHANGE_IND returns DEV_NWK_ORPHAN. This does reduce the current from a nearly constant 28mA to 1.5mA, but this is no where near the few micro amps when the CC2530 is sleeping. This is a bit extream, but everything else I have tried so far has only drwan more current.
Unfortunately am not familiar with ZNP, so I don't know it's possible to invoke
functions like ZDApp_StopJoiningCycle(), ZDApp_StartJoiningCycle() through
ZNP interface. I don't see such option in ZNP documentation in Z-stack 2.5.0
releise. Try the Z-stack 2.5.1, may be it was added there (or you could wait
for me getting home and checking it).
By the way, did you try to search the forum, I think I saw a discussion about
It does not look as if ZDApp_stop and ZDApp_start joining functions are supported in the Z-stack 2.5.1.a
I have tried searching the forum and have noticed several discussions relating to power consumption but none of them are specifically handling the case of power consumption durung a power cut or if they come close there is no resolution to the issue. Your question came the closest to the situation I am trying to resolve, hence my posting.
Thanks for your help I will go back to searching thorugh postings to see if I can track something down.
You can try a wakeup join/sleep schedule with a backoff sleep time period to save time:
1 rejoin: wake up try 5mins, then if can not join, sleep for 5 min
2 join, wake up try 5 mins, then if can not join, sleep for 10 min
repeating this process and double sleep time as 5*n mins,
external INT can trigger the state to go back 1,
Can save a lot of energy
I think your question is how to sniffer a beacon without sending any orphan/beacon request? if so, theoretically you can change to passive mode to do so
Rowan, check out this thread, maybe you'll find it helpful.
Rui, the join/sleep schedule with a backoff schema you suggested is pretty much
what I have implemented, though there are only one backoff step.
My main concern is the ~7 seconds of constant TX in orphan to rejoin to a new parent.
I was wandering how can one to reduce 7 seconds, to let's say, ~1, ~2.
All content and materials on this site are provided "as is". TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with respect to these materials. No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI.
TI is a global semiconductor design and manufacturing company. Innovate with 100,000+ analog ICs andembedded processors, along with software, tools and the industry’s largest sales/support staff.