Maximum number of connections over BLE for close working devices

[Ars Morozov]

Hello. I'm doing research for new project, regarding with BLE and WIFI capabilities to connect big amount of device to one host. I should choose between WIFI and BLE. I need to have a stable connection with 30 moving pairs of peripheral devices in range around 150 meters in the line of sight outdoor conditions. Devices inside each pair will be close to each other. WIFI not discussed here, so my question about BLE. 

If I select BLE, I see this solution.
So, each pair will have peripheral and multirole devices. Host device will be main central. Peripheral devices will be connected to multirole (here multirole device is client). Multirole devices will be connected to main central as peripheral (here multirole device is server).
NRF52840 with Softdevice S140 is the best solution from hardware point of view for multirole and for main central. Softdevice S140 support 20 concurent connections, so I should place 2 NRF52840 to get 30 connections on host. So, how do you think is it possible to build described here system and have stable data transmition from peripheral pairs to host? 

In this system will be 60 connections. BLE have 40 channel (and 3 for advertising). Is it possible to have a more than one connections on one channel for close working devices?

To ease of understanding I drew this on attached figure. Hope this help to understand what I mean.

Also if you have any other ideas and suggestions to development of described system I will gladly get to know them 

Thanks in advance.

[awneil]

Have you looked at BLE (or other) Mesh ?

The nRF52 chips can support up to 20 connections at a time - see the SoftDevice specificatrion.

Ars Morozov said:

BLE have 40 channel (and 3 for advertising).

The number of channels does not (directly) set the number of connections.

A connection does not permanently occupy a channel.

[Ars Morozov]

Thanks for fast answer.

awneil said:

Have you looked at BLE (or other) Mesh ?

Yes, I've considered also BLE Mesh, but I need higher throughput, and higher speed of data delivery.

Actually, you don't respond on my question. Is it really possible to get stable connection in this system on BLE? Maybe I'm not consider some problems and challenges which I will meet, during development? I'm understand that my question is kind of abstract, but maybe you can give some directions to discover information or maybe you already see that this is impossible?

[ovrebekk]

awneil said:

Presumably, that actually applies to any two (unsynchronised) Centrals in close proximity - it's not specific to just the nRF52840 ... ?

Correct, but if the two nRF52840's are put close together on a PCB the antennas might be just centimeters apart, leading to strong interference between the two. 

Other devices would typically not be this close, and would hopefully have a lower duty cycle on the radio than a central running 10-15 connections. 

Potentially any 2.4GHz source could interfere, and if you put the board on top of a WiFi router streaming 4k video it will definitely affect performance ;)

[awneil]

I was thinking of other manufacturer's SoCs ...

[Ars Morozov]

Espressif ESP?:)

[awneil]

the point is that it's all down to the laws of physics - so it applies irrespective of manufacturer

[Ars Morozov]

Hello Overbekk,

ovrebekk said:

Do you have any particular latency or throughput requirements?

Yes, I have some requirement, but as experience tell me, it's easy for BLE. Latency of delivering from each pair to main central should be less than 2 seconds, throughput  from each pair to main central is less then 150 bytes/s. 

ovrebekk said:

Combining a lot of links is not an issue unless you need to push a lot of data. You will get occasional packet collisions, but BLE is designed to handle a fair bit of packet loss without the link breaking down. 

ovrebekk said:

If you use Nordic devices with Bluetooth 5 support on all sides you can leverage the new CSA#2 feature, which makes each device use a more random channel selection scheme. The advantage of this is that if you have a packet collision between two device pairs they are very unlikely to collide again on the next packet attempt, and they should be able to coexist nicely. 

ovrebekk said:

One potential issue here is if the two nRF52840 devices on the central side are placed very close together. Then they might interfere with each other even if they are using different channels, as a strong TX signal can block out a receiver if it is strong enough. The two nRF52840's would not be synchronized, and will at some point try to send packets at the same time. 

Hm, everything is sounds really good, but problem with placed together two nRF52840 is critical issue... So here I see two potential ways to solve this trouble: 
1) To extend number of possible concurent connections. But is it possible? It's a softdevice limit, but is it possible to do something with that?
2) Synchronize two placed close nrf52840, but how to do it? 

Which direction is more perspective? And also give please me some information to start more deep learning about selected way, if it possible.

Thanks in advance.

[ovrebekk]

Hi

1) In the future we might be able to increase this limit, but we won't be able to increase it in the short term. If you are starting development soon then there isn't much to do about the 20 link limit. 

2) Synchronizing two nRF52840's running BLE is not possible, but it should be possible to use slightly different connection intervals on the two centrals to make sure that they don't repeatedly collide at the same interval. Say you use a connection interval of 200ms on one central and 180ms on the other, then they should mostly stay out of each others way. 

3) A third option which we haven't yet discussed is to run a proprietary 2.4GHz protocol rather than BLE. This gives you more flexibility with regards to packet format, timing, number of connections and so on. The drawback of this method is that you essentially have to implement the stack yourself, and you would have to expect to spend significantly more time developing the software. 

We have two simple proprietary protocols in the SDK, called ESB and Gazell, but they are significantly less sophisticated than the BLE SoftDevices. 

Best regards
Torbjørn

[Ars Morozov]

Hi Overbekk, thanks for the answer. 

I've open another thread to discuss synchronization of two placed close nRF52840. So, here we can discuss about problems with a large nubmer of coonection in the air.

But anyway

ovrebekk said:

1) In the future we might be able to increase this limit, but we won't be able to increase it in the short term. If you are starting development soon then there isn't much to do about the 20 link limit. 

...

ovrebekk said:

2) Synchronizing two nRF52840's running BLE is not possible, but it should be possible to use slightly different connection intervals on the two centrals to make sure that they don't repeatedly collide at the same interval. Say you use a connection interval of 200ms on one central and 180ms on the other, then they should mostly stay out of each others way. 

it is one way, but as you understand, overlappling will occure periodically..

ovrebekk said:

3) A third option which we haven't yet discussed is to run a proprietary 2.4GHz protocol rather than BLE. This gives you more flexibility with regards to packet format, timing, number of connections and so on. The drawback of this method is that you essentially have to implement the stack yourself, and you would have to expect to spend significantly more time developing the software. 

Yes, it's also applicable way, but if we will understand that BLE is really can't sutisfy our requirements, we will select WIFI. For me BLE more preferable than WIFI:

1) if we select WIFI we should provide also another inerface to transmitt information about access point, or you access point with always the same settings;

2) lower power consumpition;

3) nRF5 SDK more friendly to use than some others that I saw.

[ovrebekk]

Hi Arsenii

I do agree BLE should be a better option for this use case. 

Technically a proprietary 2.4GHz solution could be just as good, but as mentioned it would require significantly more development time. 

If you have access to enough kits/modules it should be possible to do some evaluations to measure the impact of putting the two central devices close together, to give you a feeling of the impact it will have on latency and link quality. 

Best regards
Torbjørn

[Ars Morozov]

Yes, one of the directions of this researches for project is about interfere of two placed close nRFs. Thanks for the answers.

[ovrebekk]

My pleasure Arsenii, the best of luck with your research