• State Verified Answer
  • Replies 4 replies
  • Subscribers 75 subscribers
  • Views 869 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
  • 0

    Hi

    As you're mentioning a "proprietary beacon solution" initially, are you planning on moving outside of the BLE specification? If so, the SoftDevice shouldn't be necessary to use, and nor should the SoftDevice calls or GATTS calls. Or are you still planning to use BLE in your application?

    1. We don't have a GATT read function without authorization, as there are no callbacks for unauthorized reads as RK explains in the link you provided. You can check out this thread as well, which explains more detailed how you can achieve GATTS reads, although authorization will be required here as well.

    2. Once the DCDC is enabled, the SoC will automatically switch between the DCDC and LDO to use whichever is most efficient in terms of current consumption. So if the LDO will draw less current than the DCDC in IDLE mode, it will automatically switch.

    3. What is the average when you set the beacon interval to 100ms then, you've only provided the "minimum power consumption" for that scenario. The longer your advertising interval is, the less current the device will consume during advertising. I would suggest checking out our nRF5x current consumption guide here. It was originally written for the nRF51 series, but the principles and defines used are still very much still valid in the nRF52 series as well.

    Best regards,

    Simon

Reply
  • 0

    Hi

    As you're mentioning a "proprietary beacon solution" initially, are you planning on moving outside of the BLE specification? If so, the SoftDevice shouldn't be necessary to use, and nor should the SoftDevice calls or GATTS calls. Or are you still planning to use BLE in your application?

    1. We don't have a GATT read function without authorization, as there are no callbacks for unauthorized reads as RK explains in the link you provided. You can check out this thread as well, which explains more detailed how you can achieve GATTS reads, although authorization will be required here as well.

    2. Once the DCDC is enabled, the SoC will automatically switch between the DCDC and LDO to use whichever is most efficient in terms of current consumption. So if the LDO will draw less current than the DCDC in IDLE mode, it will automatically switch.

    3. What is the average when you set the beacon interval to 100ms then, you've only provided the "minimum power consumption" for that scenario. The longer your advertising interval is, the less current the device will consume during advertising. I would suggest checking out our nRF5x current consumption guide here. It was originally written for the nRF51 series, but the principles and defines used are still very much still valid in the nRF52 series as well.

    Best regards,

    Simon

Children
  • 0 in reply to Simonr

    Hi Simonr,

    By "proprietary" we still stay within BLE spec, just with a lot of customizaion, i.e. we use our own "manufacturer specific" (we have our company ID) instead of something like iBeacon; we use custom services & characteristics instead of things like "blood oxygen".

    1. Would you mind adding a link to the page you are referring to? Thanks!

    We were contacted by an Nordic FAE outside the forum, and we underdtand that now, we will decide on our end whether to abandon the functionality or switch to "read with auth"

    2. Good to know the SoC is smart enough to figure that out! Does "sub power modes" i.e. "constant latency" or "low-power" have an impact in this operation?

    3. We are still in the middle of figuring out the best beacon interval for our use case, most likely 100-250 ms. I separated "tx current" and "idle current" as I understand beacon interval & connectable/non-connectable will have a major inpact on average current.

    But to answer your question, we measured 1min avarage of 36uA with 256ms interval, +4dBm, DCDC enabled, 3.3V Vdd, 25 bytes, non-connectable payload. (25 includes flags, name, and manufacturer specific.)

    What we don't understand about the power profile lies in between 2 advertising events, (we don't have too much test done with this) but when we shorten the interval to ~100ms, there is no "artifacts" during idle time, and the average for that "idle time" was 200uA, when we lengthen the interval to ~250ms, there are "artifacts" that brings the "idle time"'s avarage to ~800uA.

    We are not using the Nordic's official PPK but using a tool we've been using on other products, and we understand the "absolute" values may be a bit off, but what concerns me is the 4x difference. The 4x difference in sleep current can result in 1% of total average, which we'd like to figure out what it is and/or if it _can_ get much worse after we deploy a solution.

    Thanks,

    Siyuan

    P.S. I've attached 4 screenshots with what I'm talking about...

    unexplained_power_profile.zip

Related
Terms of service