• State Verified Answer
  • Replies 4 replies
  • Subscribers 75 subscribers
  • Views 866 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 267931
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Can I get GATT Server Read Events & SoC Power Mgmt Question

SLiuCognosos

Hi, I'm new to the Nordic Eco-system, but we are working to use nRF52811 in a proprietary beacon solution.

We are tying to modify the "Heart Rate Service" example to best fit our use case. SoftDevice is S112 7.0.1.

So far, I have encountered the following questions that I could use a little help figuring out: (Thanks in advance!)

  • I see there is an event named BLE_GATTS_EVT_WRITE in "ble_gatts.h", and it is working just fine, but we'd also like to get events on GATT server read events. But I don't see an equivalent on Nordic infocenter's API documents. Is what I'm asking possible to implement? or is it tucked away under some other enums? (I see this page discusses over an older SDK, is this still the case? We intended to use our own authenticatoin, so we weren't planning on enabling "authenticated read" properties.)
  • If I call sd_power_dcdc_mode_set(NRF_POWER_DCDC_ENABLE) and get NRF_SUCCESS, leaving all other power mgmt configurations default. I see DCDC is enabled during beacon TX. In this case, is DCDC still enabled during idle_state_handle() period, or does it automatically switch back to LDO?
  • If I set the beacon interval to 100ms, then the idle state has minimum power consumption (200nA), however, if I only change beacon interval to ~250ms, then I get 2 very consistent small artifacts on my power profile, pushing my idle state average to 800nA, which is quite a big difference. Can anyone help me understand the root of this behavior? (I understand the difference is neglegible, but we use batteries and any power savings can help a long way.)

I know I'm not providing much information in my inquiry... Please let me know if any specific additional infomation could help us figure this out!

Thanks again!

Parents
  • +1

    Hi again

    Thank you for the explanation.

    1. Yes, I forgot to add the link in my last reply, it has been updated now. Sorry about that.

    2. No, this will be managed by the device both in low power and constant latency mode. 

    3. This makes sense. When the advertising interval is short enough (~100ms) the voltage over the DEC4 capacitor won't fall to the point that the device will go into "refresh mode", which is what these artefacts are. While the radio is on, the onboard regulator will switch from normal mode to refresh mode where it charges up DEC4 again. The base current between refresh spikes is very low. Please note however, that the idle current will still be the same on the other end of the regulator whether your device refreshes or not, it will just look different on the input/measuring equipment.

    The energy will be drawn over the advertising event itself instead of separate refresh spikes like you're seeing. If you want to see the actual idle current you need to set the interval between radio events so large that you get multiple refresh spikes or else the current consumption you're seeing will trick you.

    Best regards,

    Simon

Reply
  • +1

    Hi again

    Thank you for the explanation.

    1. Yes, I forgot to add the link in my last reply, it has been updated now. Sorry about that.

    2. No, this will be managed by the device both in low power and constant latency mode. 

    3. This makes sense. When the advertising interval is short enough (~100ms) the voltage over the DEC4 capacitor won't fall to the point that the device will go into "refresh mode", which is what these artefacts are. While the radio is on, the onboard regulator will switch from normal mode to refresh mode where it charges up DEC4 again. The base current between refresh spikes is very low. Please note however, that the idle current will still be the same on the other end of the regulator whether your device refreshes or not, it will just look different on the input/measuring equipment.

    The energy will be drawn over the advertising event itself instead of separate refresh spikes like you're seeing. If you want to see the actual idle current you need to set the interval between radio events so large that you get multiple refresh spikes or else the current consumption you're seeing will trick you.

    Best regards,

    Simon

Children
Related
Terms of service