Connection Interval - Impact on Throughput

RE: Connection Interval - Impact on Throughput

RK — Mon, 13 Nov 2017 21:46:15 GMT

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.

RE: Connection Interval - Impact on Throughput

jumpingfool — Mon, 13 Nov 2017 21:40:46 GMT

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.

RE: Connection Interval - Impact on Throughput

RK — Mon, 13 Nov 2017 21:14:22 GMT

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.