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.