Connecting 50 BLE slaves to an RPi

[Alexander Menakhin]

The system requirements: 50 identical nRF53-based devices (each with a sensor and an actuator), positioned within a 3x3 meter square should be connected to a single computer (most probably an RPi 4) with BLE.

Latency up to 1 sec is tolerable. 

Afaik, in-built BLE in RPi 4 won't handle it, but I can connect a BLE dongle with a SoftDevice on it, right?

So the questions are:

1. Can SoftDevice handle communication with 50 slaves, each sending at least 1 message per minute?
2. Do you maybe know an RPi alternative with a proper inbuilt BLE module?
3. Will BLE mesh make sense in this case? I only actually need one-to-many communication.

[Edvin]

Hello,

I don't think you will be able to connect 50 BLE devices to any single BLE chip. I don't think it is possible with the RPi (but not 100% sure), but it is not possible with the nRF52NNN because of a limit of 20 connected devices in the softdevice.

You can of course use 3 devices to achieve 50 (60) connections, but it may not be the way to go.

Mesh is a possible solution, but it heavily depends on what your application is going to do. You say that you are OK with 1s latency. What are you doing every 1s? Do you intend to send a lot of data? Or will you only send data every 1s if some conditions are fulfilled?

Depending on this, there are some different approaches that you can try out, but I believe that the easiest right now is that you describe your planned application first, then we can look into details.

Best regards,

Edvin

[Alexander Menakhin]

Thanks for the answer!

Each module has a sensor (proximity sensor) and an actuator (LED). When a sensor is triggered on one module, it should provoke a reaction on another module and notify the central "server" (e.g. RPi4). This time between the sensor triggered and the LED turned on on another module should be around a second, definitely not more than 2.

All the modules should be able to send a "sensor-triggered" event to the server immediately after it was triggered. Each module should also periodically (once in several minutes) send a sort of keepalive message with their battery and signal strength status. 

All the modules are fully battery operated, the server has a normal AC/DC conenction.

[Alexander Menakhin]

Afaik, meshes can be different and there are some alternative mesh implementations to choose from. Maybe you could recommend a partner or two of yours.

[Edvin]

Edvin said:

but it is not possible with the nRF52NNN because of a limit of 20 connected devices in the softdevice.

 Sorry. I missed the part where you said nRF53. I don't know the exact limit, but it is (far) below 50.

 

Alexander Menakhin said:

All the modules should be able to send a "sensor-triggered" event to the server immediately after it was triggered. Each module should also periodically (once in several minutes) send a sort of keepalive message with their battery and signal strength status. 

All the modules are fully battery-operated, the server has a normal AC/DC connection.

 As far as the latency use case, this looks like a typical Bluetooth Mesh scenario, but the current consumption in the Mesh technologies (Bluetooth Mesh, OpenThread, and Zigbee) are not really battery friendly.

Bluetooth Mesh are great for low latency as long as you are not streaming data. But this use case is quite similar to a light switch. Whenever it is switched, the signal will very rapidly flow through the network. Meshes, however, has a low throughput, so streaming a lot of data from all the nodes every second is not ideal. This is why I asked about it.

But as I said, the Mesh technologies aren't that battery friendly.

The reason for this is that a mesh node needs to have the radio in RX mode ~100% percent of the time. This will lead to a base power consumption of the Radio in RX mode. 

The advantage of BLE is that the radio is only used in short bursts, so that it is able to turn off the radio and the chip itself most of the time.  So in this case, neither BLE or Mesh is really ideal for your case.

Perhaps you want to look into using just advertisements for this? Advertisements on the sensor devices makes the currentconsumption low, and it has a low current consumption. You can either change the advertisements when the proximity sensor is triggered, or in fact only advertise when the sensor is triggered. The disadvantage with advertisements is that you will not get any ACKs on the advertisements, meaning you are not sure if the scanner has picked up your advertisement or not. But if you have the devices advertise all the time (e.g. every 1s) the you will also get the heartbeat signal/keepalive message every time the scanner picks it up. But some advertisement packets may disappear if it is hitting the exact same timeslot as one of the other nodes, or if there is a lot of noise. In this case, the broadcaster/advertiser does not know that the sensor didn't pick up the trigger signal. 

BR,

Edvin

[Alexander Menakhin]

Yeah, you pretty much got the problem

Broadcasting is something I'd like to avoid for many reasons, including the absence of ACK.

So, if I get you right, the situation as is seems not solvable without compromising.

Is there maybe anything else you would suggest? Like using ANT(+) or other technology instead of BLE?

I've been researching for many days, I couldn't find any similar case to reference, except for using different kinds of meshes. I can't believe there is no standard approach for connecting a big swarm of sensors/actuators to a single "server" locally. 

I'll appreciate any advice, also regarding which Nordic products could fit the requirements.