This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Maximum number of connections over BLE for close working devices

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 Slight smile

Thanks in advance.

  • 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

  • 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

    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. 

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

    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.

  • 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

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

  • My pleasure Arsenii, the best of luck with your research Slight smile

Related