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

[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?