Connection Interval - Impact on Throughput

[jumpingfool]

I have recently been power optimising my nRF52 based application, which is a datalogger peripheral that periodically connects to a central to transfer logged readings. The central requests the readings of interest by writing to a characteristic and the peripheral sends back the requested data by writing repeatedly to a second characteristic, monitoring the fullness of the soft device TX buffer to ensure there is no overflow.

The data transferred can potentially be several hundred KB.

After experimenting with the BLE config I found that with a 400ms connection interval and slave latency of 4 I could reduce the power profile of the system to around 40uA, which is more than acceptable.

I am comfortable with the potential latency of such a high connection interval as the application is not user driven, but I am concerned it might impact the data transfer rate. While decreasing the connection interval and increasing the slave latency would counter that I am cautious about placing additional strain on the battery of the central as in some circumstances peripheral and central could remain connected for an extended period.

However, what I found during testing is that data is actually transferred very quickly regardless of the connection interval, with the central receiving hundreds of characteristic notifications per second during data transfer events. Obviously this is a welcome surprise!

I am curious what the mechanism in the BLE standard is that allows for this? I am using an iPhone as the central device for testing - can this behaviour be relied upon for all central devices?

[RK]

which way around is the data going? If from peripheral to central then that's quite possible. Just because the slave latency allows the peripheral not to respond for 4 cycles, it doesn't mean it cannot respond for 4 cycles, if it has data to send then it connects on the next connection interval and starts sending it. Similarly you can send multiple packets per connection interval if you have them queued up to go and then send more in the next one if there are more left.

You should actually check that you are getting the connection interval and latency you're asking for, the central could be giving you something totally different and connecting much more frequently too.

But for peripheral -> central data transfer, you're only really limited to the next connection to start transfer and after that you can blast data away quite fast.

[jumpingfool]

Data is going from Peripheral -> Central and I am pretty sure the central is honouring the connection interval as on the power analyser I can see the radio is active only every couple of seconds at idle. Is there a way this can be confirmed via the SDK?

From some googling I have found that there may be a limit on the number of packets that can be sent in a given connection interval, e.g. devzone.nordicsemi.com/.../

I see ~50 notifications per connection interval arriving at the central, so does this limitation not apply to the Peripheral -> Central direction?

The main point of my question is that I would like to know if I can rely on the behaviour of the iPhone I’m using for testing as being typical, or if different central devices may not be able to receive so many notifications in each connection interval.

[RK]

how many packets can go out during a connection interval depends a lot on the softdevice you're using and the parameters you set for max TX packets, which you don't state. Latest softdevices allow you to queue more packets up during a connection interval which may still go out (old softdevices only sent out packets which were queued before the interval started). Can't really believe you're seeing 50 however, sniffer trace would confirm that.

You can't rely on anything much from a central. They all act differently, they all have differing ideas about what connection intervals they will accept and how many packets they can transfer. The older the device firmware, the less data you'll likely get per interval.