Getting True Low Power Performance from PROC 222005

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
jaatc_1773026
Level 1
Level 1

Hi,

I'm wondering if someone can point me in the right direction. I've been developing with PSOC for a while now for a whole bunch of projects however I've just really started to drill down into the Lowest of Low Power modes. I'm primarily working with BLE in all applications on the 222005-00 module, however whatever I try I cannot seem to maintain a long deep sleep period when connected to BLE.

I wondered if I was making a mistake with the BLE preventing it from going to sleep fully, I've setup the BLE with a 4000 interval (min and max) but when connecting the unit up to a logic probe I can see its waking up every 50ms, what is more its sleeping for just 8ms each cycle. Which means it's really on more than it is off (safe to say not the Low Power result I was hoping for).

I've tried a bunch of examples with very little success, the only indication I have that it is possible is that in the advertising state with a 1000ms advertisement interval it is quite happy waking up every 1s and staying in deep sleep between those points. As soon as I connect it to a device (phone in this case) returns to the 50ms interval, and sleeping for just 8ms.

I assumed that with a 4000ms connection interval set in the BLE component it would be asleep for a comfortable ~39##. I guess a big question would be am I in a misconception about the 4000ms connection interval only waking up after 4000ms (or does it need to wake up every 50ms for sync?). If that is the case then how do you ever achieve the supposed average of 5-7uA on a 4000ms connection interval?

NB: SWD pins are set as GPIO, release not debug mode. . .

Any suggestions?

0 Likes
1 Solution
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi,

The reason for this might be because the connection interval set in the Central device (mobile). In any BLE connection, the central is the one that decides the connection interval. The peripheral can only negotiate the connection interval and the central may or may not accept for the negotiation request.

To update the connection parameters at the central side, the peripheral has to call the API CyBle_L2capLeConnectionParamUpdateRequest (uint8 bdHandle, CYBLE_GAP_CONN_UPDATE_PARAM_T *connParam). Upon calling this API the central response with

CYBLE_EVT_L2CAP_CONN_PARAM_UPDATE_RSP This event indicates the connection parameter update response received from the master. Event Parameter pointer points to data with two possible values: Accepted = 0x0000 Rejected = 0x0001.

Please refer BLE component datasheet for more information about these APIs and events. Also please refer Day19 code example Conection parameters in Github.

Thanks

Ganesh

View solution in original post

2 Replies
VenkataD_41
Moderator
Moderator
Moderator
750 replies posted 500 replies posted 250 solutions authored

Hi,

The reason for this might be because the connection interval set in the Central device (mobile). In any BLE connection, the central is the one that decides the connection interval. The peripheral can only negotiate the connection interval and the central may or may not accept for the negotiation request.

To update the connection parameters at the central side, the peripheral has to call the API CyBle_L2capLeConnectionParamUpdateRequest (uint8 bdHandle, CYBLE_GAP_CONN_UPDATE_PARAM_T *connParam). Upon calling this API the central response with

CYBLE_EVT_L2CAP_CONN_PARAM_UPDATE_RSP This event indicates the connection parameter update response received from the master. Event Parameter pointer points to data with two possible values: Accepted = 0x0000 Rejected = 0x0001.

Please refer BLE component datasheet for more information about these APIs and events. Also please refer Day19 code example Conection parameters in Github.

Thanks

Ganesh

Hi Ganesh,

thank you for your reply. This is very helpful! it would appear that the mobile framework is defaulting to 50ms connection interval (which would explain the results being the same with all the examples). I must confess I thought the connection parameters update was only when it was changing (and would be set correctly when first connected - an oversight on my behalf).

Thank you for your help, I will try and make the changes to see if it fixes my issue.

Many thanks

James

0 Likes