Question on Optimizing BLE power Consumption

RE: Question on Optimizing BLE power Consumption

Emil Lenngren — Tue, 11 Feb 2025 23:29:29 GMT

With a connection interval of 180 ms, slave latency latency 29, you have the effective interval of 180*30=5400 ms. With a total sleep accuracy (central sleep accuracy 100 ppm + peripheral sleep accuracy 20 ppm) of 120 ppm, we get 5400*0.000120=0.648 ms. Add an empty packet length of 80 microseconds and you get 0.728 ms.

With a connection interval of 270 ms, slave latency 21, you have the effective interval of 270*22=5940 ms. If you have a total sleep accuracy of 270 ppm, we get 5940*0.000270=1.6038 ms. Add an empty packet and you get 1.6838 ms.

Given your graphs, these numbers seem reasonable. What I can't explain though is that you say that your iPhone reports different sleep clock accuracies every time and despite this you see consistency how wide your window widenings are in the power profiler.

About window widening and slave latency in general, the longer time since the latest correctly received packet (anchor point), the more widening have to be applied, since the widening to apply is simply the formula [time since last anchor point] times total inaccuracy. Note that every packet exchange in a connection event starts with the central and ends with the peripheral. If the peripheral sends something, the link layer is waiting for the link layer acknowledgement. If no acknowledgement is received in the central's next packet (which will occur during the next connection event), the peripheral will retransmit until it receives an acknowledgement. Due to this, the peripheral is optimised to ignore slave latency after it has sent a packet while it is waiting for the ack, so that in case the packet was lost, retransmission will happen quickly. Only in case any device has more than one packet to send in its queue, the central will be able to reply to the peripheral in the same connection event (and hence deliver an acknowledgement).

RE: Question on Optimizing BLE power Consumption

Amanda Kinley — Tue, 11 Feb 2025 22:30:06 GMT

I apologize for the delayed response. After looking over the sniffer trace again and re running the test, I am getting a different Sleep Clock Accuracy for the central (an iPhone 14) almost every time. Sometimes it is low, in 20ppm range, other times it is 250ppm or somewhere between. Is this to be expected? Regardless of what is reported in the sniffer, I still see the 1.6ms RX window when connected to the iPhone.

[quote userid="26071" url="~/f/nordic-q-a/118509/question-on-optimizing-ble-power-consumption/521146"]Is it possible to upload that sniffer trace?[/quote]

It is uploaded! The one titled NRFSnifferLOGconnectionToDK is the connection to the development board and the other is connected to the iPhone.

[quote userid="26071" url="~/f/nordic-q-a/118509/question-on-optimizing-ble-power-consumption/521146"]

And is the increased RX window only present some times, or on every connection interval?

[/quote]

On the first transmission after an HVX is scheduled, the RX window is always longer (~1.6ms). The second RX interval immediately after is much shorter (~300us). In addition, when removing the slave latency, every RX window is around 300us.

[quote userid="135319" url="~/f/nordic-q-a/118509/question-on-optimizing-ble-power-consumption"]1) After scheduling a notification of only 2 bytes with the HVX, I am getting two events on consecutive connection intervals despite only scheduling one. As I understood it, only indications would need an acknowledgement on the subsequent transmission. I am aware that notifications still have a link layer acknowledgement, but I thought that this would be in the same connection interval and not the subsequent. I have attached screenshots of my power profiler for both the entire window (from HVX called to the second transmission) as well as a zoomed in views of the first and second transmissions. [/quote]

Is this behavior to be expected when sending a notification?

Thank you for your help!

/cfs-file/__key/communityserver-discussions-components-files/4/NordicForumSnifferLOG.pcapng /cfs-file/__key/communityserver-discussions-components-files/4/NRFSnifferLOGconnectionToDK.pcapng

RE: Question on Optimizing BLE power Consumption

Edvin — Mon, 03 Feb 2025 14:17:45 GMT

Hello,

I see that this screenshot is from a sniffer trace (probably from the nRF Sniffer for Bluetooth LE). Is it possible to upload that sniffer trace? And can you pinpoint approximately where in the sniffer trace (what packet) that has this increased RX window belongs to?

And is the increased RX window only present some times, or on every connection interval?

If you have a sniffer trace of the connection that doesn't have the increased RX window, please upload that as well.

Best regards,

Edvin

RE: Question on Optimizing BLE power Consumption

Amanda Kinley — Sat, 01 Feb 2025 00:23:15 GMT

The clock accuracy of the peripheral is 20ppm. The sleep clock accuracy of the iPhone is reported to be 0 to 20ppm in the CONNECT_IND packet as shown below.

RE: Question on Optimizing BLE power Consumption

Emil Lenngren — Fri, 31 Jan 2025 07:52:57 GMT

What is the sleep clock accuracy of the two central devices? You can find this value in the CONNECT_IND packet, sent at the beginning of the connection. You can see this with nRF Sniffer. If the central reports a more inaccurate clock (higher value), it means the peripheral must apply a larger window widening. Note that the widening is linearly increased depending on how long time ago the latest successful connection event was.