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

Evaluation of multiple peer-to-peer connections/communications between nRF52840DK and nRF52832

Hello,

In our project we have a nRF52840DK as central device and a BMD-300 (contains nRF52832 chip) as peripheral device. The BMD-300 sends data to the nRF52840DK with a data-rate of 40kBit/s via Nordic UART Service. This works fine. We implemented a Scan-Filter on the central device, so the central device only connects to a defined BMD-300.

For our application we want to use multiple nRF52840DKs and BMD-300s in the configuration I already mentioned. We are curious on how many of this peer-to-peer connections we can use at the same time before the radio traffic starts to generate problems. Thats the reason why we want to evaluate this.

So here are our questions:

1. Is there a way to evaluate this without buying a lot of nRF52840DKs and BMD-300s?

2. Are there any numbers or documents available, which contain informations regarding this topic?

3. Do you have experience on how many peer-to-peer-connections can be achieved at the same time with a data-rate of 40kBit/s?

Thank you very much in advance.

Parents
  • Hi,

    The softdevice can support up to 20 devices in central mode, if you let each BLE event last 5ms, you can get a connection interval of (20*5ms=) 100ms from each peripheral. You may be able to fit up to 2 packets of about 250bytes during that BLE event, the throughput then will under ideal conditions then be up to (2*250Bytes)/100ms = 5kBps = 40kbps. However you should not expect you will have 0 packet loss, so effectively I would say half that (e.g. up to 20kbps with 20 peripheral devices at the same time).

    1. You should test this, e.g. buy several nRF52840 USB dongles can be used for the test.

    2. Check out scheduling chapter.

    3. Based on the above calculation I would say 5-10 devices.

    Best regards,
    Kenneth

Reply
  • Hi,

    The softdevice can support up to 20 devices in central mode, if you let each BLE event last 5ms, you can get a connection interval of (20*5ms=) 100ms from each peripheral. You may be able to fit up to 2 packets of about 250bytes during that BLE event, the throughput then will under ideal conditions then be up to (2*250Bytes)/100ms = 5kBps = 40kbps. However you should not expect you will have 0 packet loss, so effectively I would say half that (e.g. up to 20kbps with 20 peripheral devices at the same time).

    1. You should test this, e.g. buy several nRF52840 USB dongles can be used for the test.

    2. Check out scheduling chapter.

    3. Based on the above calculation I would say 5-10 devices.

    Best regards,
    Kenneth

Children
  • Hello,

    thank you very much for your fast reply and calculations.

    I think I did not explain our request very well. So I will try it again, sorry for that.

    You described a scenario with one central with many connections to peripherals at the same time. Something like this: 

    I want to evaluate how many connections between central devices and peripheral devices can be achieved at the same time if they are close to each other before the radio traffic starts to generate problems. This is shown in the following picture:

    So here our questions:

    1. Is there a way to evaluate how many stable connections can be achieved at the same time?

    2. Can you provide us any informations, numbers or documents regarding this topic?

    3. Do you have experience on how many connections could be achieved, bevor the radio traffic generate usually problems?

    Sorry again for my previous inaccurate description of my request.

    Thank you very much in advance.

  • Thanks for the clarification.

    In BLE the time on-air is very short, all devices are using frequency hopping, and TDMA for communication. This reduce the risk of collisions.

    Even if two peers are transmitting exactly the same time on the same frequency, the two peers may be further apart, such that the signal from the interfering peer is much weaker than the signal from the intended source, this means that devices may still be able to communicate. 

    So overall I would say the risk of devices unable to communicate is very, very small. It may reduce the throughput and increase the latency in a very crowded environment (e.g. CES tech event with thousands of people gathered) but you will still be able to receive data (e.g. from your pulse belt).

    It's more of a theoretical problem than an actual problem. I am not aware of any specific documentation on this, but I would think some third party may have studied this.

    Best regards,
    Kenneth

  • Thank you very much for your reply and informations.

    I will check third party, maybe they have studied this.

Related