Question on Optimizing BLE power Consumption

[Amanda Kinley]

Hi, 

I have a two part question aimed at optimizing the battery life during BLE transmissions. I am using an nRF52805 with the S112 soft device and a DCDC regulator connected to the Nordic pp2. My connection parameters are as follows: Max con interval = 525ms, Min = 495ms with a slave latency of 10 and 18s con sup timeout. 

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. 

2) When connecting to the standalone BLE app on nRF connect desktop I am getting a substantial power decrease compared to that of the same negotiated parameters on an iPhone. From looking at the pp2 data, the RX window is being opened for 1.6ms (as shown selected below) compared to 600us (shown selected above) when connected to the Nordic app. My MTU size is 23 and my event length is set to 6. This is also verified with a sniffer that the iPhone is not negotiating these two parameters. Is this a common or could I be missing something in my config.

 

The first transmission is on the left and the second is on the right. 

Thank you for your help with this! 

[Emil Lenngren]

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.

[Amanda Kinley]

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. 

[Edvin]

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

[Amanda Kinley]

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. 

Edvin said:

Is it possible to upload that sniffer trace?

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

Edvin said:

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

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. 

Amanda Kinley said:

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. 

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

[Emil Lenngren]

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).