Maximum troughput with 3 peripherals and one central

[Constantin]

Hi,

I am planning two have the following network:

1 central communicating with 3 peripherals

One of the peripherals will be a smart device (iOS or Android). What would be the maximum through put. From my understanding the minimum connection interval is 7.5 ms and the nRF52 is capable of sending 6 packages in between this interval. But does this mean for three peripherals that the central can send 2 packages two each peripheral in between one interval?

iOS only supports intervals down to 30 ms. This would mean that if an iOS device is inside the network the throughput will reduce by factor 4?

And last questions doe a package send always mean both ways? So the central sends one package and the peripheral answers?

Thanks for your help.

[endnode]

Surprisingly nRF52832 is BT5 as well and even more surprisingly BT5 doesn't make larger throughput through more PDUs/MTUs but through data rate. And because both nRF52832 and nRF52840 support 2Mbps they will have basically equal maximum theoretical throughput.

Now as you use nRF52832 I suppose you are talking about S132 V3 stack (note that there are other Open Source options which can provide different maximums!) and it has indeed detailed section about theoretical maximum throughput in its specification here. If you want to convert these back to PDU/MTU numbers per interval in relation to connection interval used and number of parallel GAP Central links then read this and this blog post as well as this section from SD specification.

[Constantin]

So to be a bit more specific I plan the following scenario.

There are two sensors (peripherals) and one remote (central) and one smart device (peripheral, iOS or Android). Since iOS only supports 30 ms minimum connection interval the overall connection interval will be 30 ms?

Then it is possible to send 6 packages in between one connection interval this means the remote (central) can exchange with each peripheral one package. Is this correct? The only change for BT 5.0 will be the amount of bytes per package which can be sent.

Thanks again,

Constantin

[endnode]

When you start to multiplex several ongoing links (whatever Peripheral or Central like in your case) the situation will stop being deterministic. You can run several Central connections with nRF5x each having different bandwidth and connection interval, it will just "collide" internally in Soft Device scheduler from time to time (no worry, it won't crash, just one of them will be served depending on priorities described in the documentation and the other will continue later when scheduling collision goes away) and you will suffer from scanning bandwidth (meaning that opening of every other Central connection will take more time as Scanner and Peripheral must meet with their intervals which have random shift). In general using Connection interval 15ms or higher should work with 3 Central connections and HIGH bandwidth on nRF52 and S132/S140. For more read...

[endnode]

... full Scheduling section from S132 Soft Device specification (especially last section 16.10). I would actually write the FW and do the test if you are really so much interested into detailed bandwidth.

To the BT5.0 remark: it sounds completely incorrect, at least in the way you wrote it ("The only change for BT 5.0 will be the amount of bytes per package which can be sent."). Already BT4.2 has various extensions like Connection Interval, PDU and ATT_MTU. The only added feature in BT5.0 is 2Mbps airspeed option, it gives you larger bandwidth if you can leverage it.