CC2540 halSleep( ) function

Hello，

    Thanks for your replay. I have read the document Measuring Bluetooth Low Energy Power Consumption， and the document says that when running the BLE protocol  stack the wake up time from PM2 to active is 400us, but I check the cc2540 datasheet and find that the wakeup time form PM2 to active is 120us. I want to know if I don't start a BLE communication , the wakeup time can be reduce or not? Also, the "Post-processing" time can be reduce without running a BLE protocol  stack?  Can you provide some tools that can measure the power consumption when the BLE communication is stop.

   thank you very much

Hi Xiqian,

There's two different things you are looking at there, 120us is the time for the device to wake up and  then you have to wait for the BLE stack to run some code hence the additional micro seconds. What do you mean "not start a BLE communication"? The OSAL runs the complete stack and if you need to do something after sleep you are bound to wait for the start-up because it's the Link Layer (task run by OSAL) that controls the sleep/wake and the application task (your written code) will have to wait until it's finished. It's simply scheduling.

Could you explain what you want to achieve?

Hi,Nick,

What I want to achieve is that I want to develop a pedometer with BLE function, and I want to start the BLE function in a interval, for example, every 5 min the pedometer will spend 20s to broadcast and wait for connection. During the 20s I must  "wait for the start-up because it's the Link Layer (task run by OSAL) that controls the sleep/wake". But the other 4min and 40s, the pedometer doesn't broadcast or connecting, just like a normal pedometer wihtout BLE function. Is that I can to something at this time to reduce the time for "sleep/wake" run by the OSAL?

thank you very much

Hi,

So let's see if  I understand you correctly; during those 4min and 40s you want the possible sleep/wake time minimized? It's still run by OSAL but you will of course not have the pre-radio nor post-radio processing handling packets and I don't think you'll get less than the ~400us, although that figure might have been optimized with the latest stack.

Best Regards

Hi,Nick,

How can I get the latest stack.?

Does the sleep/wake code(especially   LL_PowerOnReq( ) and LL_PowerOffReq()) in the stack can become open souce so that I can learn it? Or, this will be fully open in the future?

thank you very much

Hi,

Xiqian Lin said:

How can I get the latest stack.?

www.ti.com/ble-stack

Xiqian Lin said:

Does the sleep/wake code(especially   LL_PowerOnReq( ) and LL_PowerOffReq()) in the stack can become open souce so that I can learn it? Or, this will be fully open in the future?

No, that's part of the object code (library) and will probably not be available in the future.

Best Regards

Hello,

I have the same need: For several minutes I need the minimum wake time without any radio functionality, and the use radio for a while. Without using the BLE stack, I managed to minimize power comsumption using the 16 MHz RCOSC, which reduces significantly the wake/sleep delays, and as I don't need the precision of the 32 MHz XOSC, it's fine, but I'd need to combine this efficiency with the use of the sleep/wake functionality of the BLE stack, so I'd need to have a efficient sleep function that doesn't try to wake up the radio or the XOSC if isn't needed. How can I do that?

Thanks.

Hey Javier,

I am also trying to do what you are doing. Did you find a solution?

I agree, I may have a use case coming up when I will need the same functionality - sleep/wakeup without waiting for the 32MHz xosc to stabilize every time because there is no BLE activity.

Is it possible to not call the LL_PowerOnReq() function when coming out of sleep?  What are the possible side effects?

-Tyler

Well, I've been looking at the code in the LL_PowerOnReq (and Off) and looks like they only init the radio interface and the timer 2 so I'm working in a modify version of hal_sleep that only calls LL_PowerOnReq when a radio event is expected. It's kind of tricky, because other events (such as OSAL or from your application) may trigger a radio transmission, so you need to check before that if you kept the radio off to turn it on again.

As a summary, there's no simple solution that fits all cases, you'll have to tune it for your application.

In my case, LL_PowerOnReq and LL_PowerOffReq aren't so complex, as most of the code is for debugging or specific situations. LL_TimeToNextRfEvent is the tricky one, as you need to understand the timing calculations.

Javier

Hi Javier,

How are you looking at the code in LL_PowerOnReq and LL_PowerOffReq?  Do you have the source?

Thanks

-Tyler

Unfortunately, no. I had to look at the binary code using the debugger.