Increased Power Consumption in HRS Example After Connection, Before Notifications Enabled

[Jackson Burnette]

I loaded the BLE peripheral HRS example from the Nordic SDK 17.0.2 on an nrf52840 DK. I connected a PPK II while connecting the peripheral using an nrf52840 dongle and the nrfconnect BLE pc app. I would connect to the nrf52840 DK via nrfconnect and then manually enable notifications on the heart rate measurement characteristic. There was a delay of 20 seconds or so between the initial connection and when I enabled notifications.

I noticed that the average current is an order of magnitude greater after connecting to the peripheral but before notifications are enabled compared to after notifications are enabled. Any insight as to why the difference in average current draw is so great would be much appreciated.

post connection, pre notification enable

post connection, post notification enable

[Stian Røed Hafskjold]

Hi, are you able to zoom in on the BLE events and see if the connection interval changes, or if you see any other differences between the two modes. Perhaps you can share the exported PPK plot here? If you click on save/export and share the measurement as a .ppk file, that would be great, thanks.

[Jackson Burnette]

Ah, of course. I should have done that from the beginning.

I'm having trouble uploading the ppk file as is (hit Insert > Image/Video/File, upload, choose file, stops at about 60% w/o error message, nothing happens if I hit Ok). Maybe the file is too large?

I don't have the setup immediately available. Here's a link to the ppk in google drive until I can figure out the upload issues, https://drive.google.com/file/d/1ta91juYrKH78FYyHVfxQiMrlnSF8uKSr/view?usp=sharing. Hope that works.

[Stian Røed Hafskjold]

Thanks, not sure why you can't upload the file, but I was able to download it from google drive.

I can see that the connection is maintained at a 400 ms interval when there is no data transfer, and it increases to a 7.5 ms interval during the notification period.

400 ms:

7.5 ms:

Either the application is configured to increase the connection interval during notifications, or it has a slave latency of 52 (7.5ms*(52+1) = 397.5ms), meaning that the slave is allowed to skip every 52 packets if there is no data to be sent.

[Jackson Burnette]

Stian Røed Hafskjold said:

I can see that the connection is maintained at a 400 ms interval when there is no data transfer, and it increases to a 7.5 ms interval during the notification period.

I see those same connection intervals but in opposite portions of the trace than you reference, 7.5 ms when the connection has been established but no notifications enabled and 400 ms after notifications are enabled. Although, it would make more sense if it was as you say so maybe I am missing something.

I am using the unaltered BLE HRS peripheral example from the 17.0.2 SDK (nRF5_SDK_17.0.2_d674dde/examples/ble_peripheral/ble_app_hrs/main.c). I believe that the minimum connection interval for that example is 400 ms and there is no renegotiation as far as I know.

[Stian Røed Hafskjold]

Hi, yes you are right. It's opposite of what I said. Or actually, it's not related to notifications being enabled or not at all. The central is deciding the connection interval, and the peripheral can only request the interval. So what happens is that during the initial connection request by the central, the connection interval is set to 7.5ms. This is not dependent on any peripheral application settings. When testing here, I see that the initial connection interval is set to 50ms. Then the peripheral performs a connection update request, and in the hrs example the requested value is 400 - 650 ms. The time it takes for the peripheral to request a new connection interval after the initial connection procedure is given by the FIRST_CONN_PARAMS_UPDATE_DELAY definition in main.c.

[Jackson Burnette]

Ah, okay I see what you're saying.

FIRST_CONN_PARAMS_UPDATE_DELAY is set to 5 seconds in the hrs example correct? The period of high power draw in the capture I linked earlier is ~16 seconds. I have another one where it is 30 seconds. That seems to indicate that it is not related to FIRST_CONN_PARAMS_UPDATE_DELAY?

Are you able to recreate what I'm seeing with a period of high power draw after the initial connection and before notifications are enabled? It's totally possible that the period of high power draw is not actually related to notifications enabled, but that's what it seemed like to me.

[Stian Røed Hafskjold]

Hi, I do not see the same here. It changes the connection interval to 650 ms after FIRST_CONN_PARAMS_UPDATE_DELAY ms, and does not change whether notifications are enabled or not.

Looks to me like the central is requesting a shorter connection interval.

Yes, it seems to make sense that the connection interval will decrease after notifications are enabled, because of the ble_conn_params_init() design. It takes an argument, start_on_notify_cccd_handle, which is set to the hrs notification handle, and that is supposed to initiate a new connection update procedure after notifications are enabled. However that does not explain the shorter connection interval before notifications are enabled. Are you able to capture a BLE sniffer log? It would tell us what is going on between the central and the peripheral. Also, have you tried using a different central? Can you try to set the start_on_notify_cccd_handle variable to BLE_GATT_HANDLE_INVALID?