Eventual High Increase In BLE Power Consumption with nRF52840, nRF5 SDK v17.1.0, S113 v7.3.0

[ntennies]

We've been doing some long-term power consumption testing of our product with the Nordic PPK2 — which is a fantastic tool — and have discovered an anomalous increase in BLE current draw after our system is running in steady-state for about six hours. We think it's very clear this being caused by a change in behavior of the S113 SoftDevice, perhaps due to some interaction with the iPhone 11 Pro running iOS v17.4.1 that we used for the test.

Specifically, about six hours into a ten-hour overnight test, we see an abrupt and persistent change in BLE current draw, increasing from about 180 uA in the first six hours to a new mode which features long (e.g. 10 minute) periods in which BLE current draw is about 550 uA. Because this change happened in the middle of the night -- roughly six hours after the iPhone went to sleep mode, at a time when there was no interaction with the IPhone or the test device -- and because it does not appear to be correlated with an increase in BLE traffic from our mobile app, it appears to be a change in behavior of the S113 SoftDevice, perhaps due to some interaction with iOS.

Is Nordic aware of such an issue? What could cause the S113 to change its behavior and increase its current draw so dramatically? What can we do to prevent or remedy this if it occurs?

I have attached a PDF showing six screenshots from this ten-hour PPK2 capture. The first three show what we typically are seeing and expect during fast-advertising and for the first six hours of our test after  successful connection and pairing. The last three show the sudden and persistent change in behavior that featured long periods of high BLE current draw for the last four hours of our test.

One possibility we considered was that somehow the S113 was disconnecting and entering fast-advertising for reconnection for some reason. However, we log all such BLE state transitions, and no such transitions occur. To the best of our knowledge, the S113 should still have been connected to the iPhone. Also, this anomalous high current draw (e.g. 550 uA) is about 100 uA less than what we see during fast-advertising. 

What is interesting, as shown in the last screenshot in the PDF, is that once we started interacting with the phone (but not our mobile app) in the morning, the anomalous high current draw did not disappear, but did change behavior, switching from long periods of high current draw to shorter bursts, but the overall high current draw was still persistent.

Thank you for your help!

7776.blequestion.pdf

[helsing]

Hi Nathan,

Just letting you know we have started looking into this.

[ntennies]

Thank you. We have a little more data from our exploration of this issue:

1) We ran another ten-hour overnight test and we saw the same basic behavior, but with two differences:

• The transition — which occurred at about the six hour mark — from normal BLE current draw to the upsweeping runs of high BLE current draw started after only an hour in the most recent test.
• The upsweeping runs of high power consumption were shorter, much as shown in the second half of Image 6 in the PDF. We didn't get any of the long, ten-minute upsweeping runs.

2) Something we missed at our first look at the anomaly is that once it starts, when we're not in one of the long upsweeping runs of high BLE current draw, the BLE current draw is actually lower than what we're seeing before the anomaly starts:

• Once the anomaly starts in the first test, we're seeing 550 uA BLE current draw in the long upsweeping runs, but then in the periods in between those runs it drops to around 83 uA.
• In the six hours in our first test before the anomaly starts — as shown in Image 1 — we see the BLE current draw oscillate between 195 uA and 220 uA over a 5-10 minute period
• As a result of this, in our first ten-hour test, the average power consumption over the six hours before the anomaly started was only about 30 uA lower than once the anomaly begins.
• In our second test, we see the same pattern, but because the the pre-anomaly BLE consumption is about 30 uA higher than the first test (for some reason), and the pattern of the anomaly changes to shorter upsweeping runs (as mentioned above), our long-term average BLE current draw during the anomaly is actually about 60 uA less than before it starts.

3) While the anomaly seems completely persistent in our tests once it starts, we've discovered that turning BLE off and back on again will reset the behavior to its non-anomalous state for (so far) 1-6 hours.

So I guess the bottom line is that the average long-term BLE current draw during the anomaly is not substantially different — plus or minus 30-60 uA — than before it, but the behavior of BLE current draw changes dramatically once the anomaly starts. But it would be helpful to understand what's causing this persistent change in behavior, and why we're generally seeing variability in BLE current draw both before and after the anomaly starts between test runs.

Thank you again for looking at this.

[helsing]

Thank you for the update.

Would you be able to post the ppk trace files? Recordings with the best possible sample rate(100k samples per second) would be great. Then we could try to check whether the device is in a connection, advertising etc., or whether there is something else running.

[ntennies]

We've identified the source of the anomaly: the long upsweeping periods of high current draw for BLE that started 1-6 hours after our tests began are not real, but are an artifact caused by running PPK2 at 1000 samples per second. This is, of course, somewhat surprising because not only could we see this sudden and persistent change in behavior, but PPK2 was absolutely telling us that the BLE was drawing much higher current draw.

We determined this by running another long-term test at 1000 samples per second and then waiting for the anomaly to start occurring consistently. We then stopped sampling and restarted sampling at 100K samples per second, and the anomaly did not reappear, and BLE current draw consistently stayed a flat 200 uA.

Interestingly, when we stopped sampling again, and restarted at 1000 samples per second, the anomaly also did not immediately reappear, although I'm sure it will eventually. I'm wondering if part of this is that the PPK2 is also based on a Nordic chip, and so there's something about the sampling period that is closely (but not exactly) synchronized with BLE activity on our nRF52840. I still find it surprising that this could yield such consistent yet complex patterns, and I still don't understand why the PPK2 is showing such a dramatic change in behavior at some point.

Also, what this suggests to me is that when the PPK2 is configured for lower sample rates, it is still likely using a 10 us sampling window, but now those samples only occur every 1000 us. So the PPK2 isn't providing average current draw across that 1000 us window, it's just sampling for 10 us within that window, and where that falls on the periodic BLE spikes can misrepresent the current draw as being abnormally high or low. Is that correct? I'm assuming there's not a way to turn such averaging on?

Of course, the reason we dropped the sample rate down to 1000 Hz is that this allows us to collect 13 hours of samples, versus only 600 seconds at 100 KHz. Ideally, we'd like to perform a long-term test while continuing to sample at 100 KHz. Is there a way to increase the sampling buffer size? or is it possible to use the PPK2 API to retrieve samples for an indefinite period even when sampling at 100 KHz?

Thank you again for your help!