How to put Router into Deep Sleep Mode (PM2 or PM3) for CC2530

Hi Harry,

Thanks for your reply!  I guess the requirement does look like confusing.

Here may better describes what we try to achieve:

1.  ZED is battery powered, but it only sends signal a few times a day and such signal is information purpose only.  We did think about if other routers are sleeping, so we basically cache the data on the parent router and eventually it will get to coordinator in a reasonable amount of time.  The network is not huge.

2.  Router needs to conserve power too because it is kinda of battery powered ( image a super cheap low capacity rechargeable battery), except this battery can be recharged a few times per day.  We did some calculation that if we put router in RX mode all the time, there may not be enough power...

So we are not really trying to save power, but try to make the whole system work in this very restricted environment.　　That is why we try to put router into sleep mode to save its power usage.

The reason why we try to use Z-Stack is because the router may have access to enough power in some environments, so we can expand the features and software can be dynamically configured and works cross different environments at run time.

Thanks

Jiang

Hi Harry,

Really appreciate your suggestions!  I am definitely giving it a try, at least from the proof of concept level.

Thanks so much!

John

I have a bit of a longer rant about this.

As Dirty Harry points out, one can't do sleeping routers with Z-Stack unless building on an ad-hoc high-level sleep/wakeup protocol which, at the end of the day, won't be very energy friendly.

As he also rightfully points out, to really implement sleeping routers, one must go the beacon network route. All this occurs at the MAC level and above (eg. at the network or app level).

However, beware: several issues stand in your way:

a) a sleep/wakeup scheme for sleeping routers implies synchronisation among the nodes of your network.  To exchange messages, involved parties have to be awake, and not in sleep mode (PM2).  At the scale of the network, this implies a global sychronisation scheme where all nodes (both end-devices and routers) go to sleep to save power, then wake up "preferably synchronously" in order to exchange info. Preferably synchronously - because if they don't wake up synchronously, one ends up with out-of-sync and re-sync issues (one active device talking to a neighbour device in sleep mode which can't hear the messages sent to it) plus the management of buffered data and message retransmissions.

b) The inter-node sync issue is central for sleeping nodes, and in particular for sleeping routers. As a user, you want additionally to be able to configure the sleep/wakup periods dynamically. i.e. to be able to configure at runtime the length of the night and the length of the day in a day/night cycle.

c) Assuming you've sorted the sync aspects somehow, this somehow does imply a beacon network.  Now, by using a 802.15.4 MAC-level beacon network configuration, one will discover pretty soon that although there are provisions in 802.15.4 (TI-)MAC for inter-node synchronisation according to a master/slave scheme i) it's hard to scale that to the level of the network, ii) it's almost impossible to vary the duty cycle (day/night) without major network reconfiguration implying a reset of the MAC layer, iii) the re-sync issue is almost not solved (due to packet loss, difficult radio environment or too many collisions, once a node gets out of sync, it'll take time and energy to re-sync, which is a process performed by MAC over which one doesn't have much control), iv) basically one can't handle the synchronisation error cases gracefully because there's little knowledge of what's going on on the sync-side of things. One just has indications telling whether the device is in-sync or out-of-sync, but no more. And that's not enough.

d) One will then try an alternative - build a beacon network manually at the network layer, that is on top of (TI-)MAC, with a duty-cycle scheduler with controls explicitly when the device is going to sleep (PM2) and is waking up. This way, all of the above issues can be sorted out because one has control over the process (sync, out-of-sync, pkt loss, beacon and data rtx, and even dynamic user-level control of the day-night periods within the duty cycle, the length of the latter being also configurable). This solution does lead to a somewhat proprietary network layer with added value over the standard Z-Stack network layer, because the devices can now have a sleep/wakeup duty-cycle profile, including the routers.

e) Assuming all that is a given, you've got a "pulsing" network which sleeps (most of the time) and wakes-up regularily and synchronously to exchange and route messages from one node to another. And then, you'll want to get the most out of your network and you'll figure out pretty soon that a sleeping router (which is great but a contradictory notion anyway) will start dropping messages due to out of memory conditions resulting from too much buffered data (accumulating in some parts of the network partly because of the sleep periods) and you'll end up extending the (RAM) message queues to flash, by using flash a a secondary storage for the data to mitigate the situation.  Note that the amount of RAM persisting trough a PM2 sleep cycle is limited, hence the issue.

f) Etc. etc., etc.

 I'll stop here, because there is so much more to be done in order to have sleeping routers... that you might really get discouraged by seeing how many cans of worms such a simple and intuitive concept can open :-)  If it's not provided with TI-MAC or Z-Stack - it's not an accident.

Now, if I tell you that I've gone that route and I have all of the above implemented and working, and on top of this, I have it working on CC2430 devices which have at most half the ressources of CC2530 onces, I'll probably get some respect here <wink>, but that's not the point...

The point is that sleeping routers are hard to do and for a proof of concept like yours, you're better off with the hunch of Dirty Harry.  And if it is not satisfactory, bear in mind that going the beacon network route requires, as a minimum, a ton of work.

Good luck!

You can use the following code 

if(BaseStationState==STATE_BS_IDLE)
{
unsigned char rxOnIdle;

//turn off ZigBee task
nwk_setStateIdle( TRUE );
// turn MAC receiver off
rxOnIdle = false;
ZMacSetReq( ZMacRxOnIdle, &rxOnIdle );

halSleep(20000); //20sec deep sleep

//turn on ZigBee task
rxOnIdle = true;
ZMacSetReq( ZMacRxOnIdle, &rxOnIdle );
// set NWK task to run
nwk_setStateIdle( FALSE );
}