[BitCloud] How to force EndDevice to sleep while network was not started

[mshoff]

Hi,

does anybody know how I can force my enddevice to go into sleep mode while the network was not started?
I tried it first with SYS_EnableSleepWhenIdle() and then manually with ZDO_SleepReq() (this is returning ZDO_BUSY_STATUS).

It seems that some tasks in SYS_RunTask sets SYS_taskFlags which is preventing executing SYS_IdleHandler().

I am using Bitcloud 3.2.0.

I am happy for every hint.

[ataradov]

does anybody know how I can force my enddevice to go into sleep mode while the network was not started?

First of all, you need to disable SYS_EnableSleepWhenIdle(). By enabling it, you give control over the sleep to the stack. After that ZDO_SleepReq() should just work.

Some earlier versions had a problem where you had to call ZDO_ResetNetworkReq() in the beginning to bring the stack state into shape, but this should be long fixed in v3.2.0. You can still try and see what happens.

It seems that some tasks in SYS_RunTask sets SYS_taskFlags which is preventing executing SYS_IdleHandler().

It would be helpful to know what task it is.

[mshoff]

Thank you for your fast response!

I found this post:
http://www.avrfreaks.net/forum/using-bitcloud-unable-sleep-without-coordinator

With ZDO_ResetNetworkReq() on startup I can force the sleep mode.

The next issue is current consumption. Unconnected I have about 3,2 mA vs. 0,01 mA in "connected sleep". What can be the cause for this difference?

[ataradov]

What hardware we are talking about?

[mshoff]

It is an self designed board based on ATmega2564RFR2 - similar to "Atmel ATMEGA256RFR2 Xplained Pro" or the "ZigBit extension boards".
I am using the HADevice example.

Does the stack have some sleep characteristics depending on the connection state?

[ataradov]

Does the stack have some sleep characteristics depending on the connection state?

It should not. But I also expected no-network-no-sleep bug to be long fixed by v3.2.0.

Are you sure there is no difference between I/O pin states in those two cases? Maybe some debug pin, or network status LED?

3.2 mA is really low for either MCU or RF part. So things appear to be sleeping, but not quite.

[mshoff]

The I/O pin states are the same in booth cases. I am using two timers instead of the appDeviceTaskHandler for my application control. Any button click is starting the timers. The first timer has TIMER_ONE_SHOT_MODE and defines the duration of the second timer, which is in TIMER_REPEAT_MODE with an interval of 50 ms.

I have some new insights:

1. If my device is connected and the connection is lost, then it trys to rejoin and after MAX_ATTEMPS_TO_ENTER_NETWORK is reached, it goes to sleep with 0,01 mA.
2. If my device was never connected to any network and no network is reachable, then it will do the same like bevor and goes to sleep for a very short time. But it immediately wakes up and consumes >12 mA. With acitve timers after button press the consumption goes down to 3 mA. If the timer has finished, it goes back to 12 mA again. 

[ataradov]

12 mA looks like a full active power consumption. I really don't know what's going on here.

The way I would go about debugging this is to put a small (~10 Ohm) series resistor in a power supply line and measure voltage drop over this resistor using a scope to get a current consumption profile. Timing information from this may tell more.

[mshoff]

Hi, I found the reason of my problem.

If both timers was finished, my application is sending an onoff-command. This causes in unconnected state the blocking of the sleep-mode.

But why is this only an issue, if my device was never connected?

[ataradov]

But why is this only an issue, if my device was never connected?

It is possible that there is difference in handling of incoming requests depending on the previous connection state. Technically, you should not call networking APIs if you are not connected.