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]

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.

[Edvin]

I am not sure how ANT would suit to this. If you want to know, I suggest you create another ticket, similar to this one but asking whether ANT can be used for this, and it will be assigned to an engineer who has more experience with ANT.

I don't think this is the first question on this issue, but I guess there are tiny differences between the different use cases.

Is there a specific reason why you want to use the nRF53? I am just asking because at this point in time, the SDK for the nRF53 (the nRF Connect SDK) is not production ready. I am not familiar with this new SDK, so I can't guarantee that the implementations will be nRF53 compatible. But it seems possible to use the nRF52 series for this as well.

So, the issue is that you want up to 50 devices to one gateway, you want low power consumption and relatively low latency. As you say, it is a compromise. How long do you expect the device to last on a battery? And how large is the battery? For the nRF52840, the constant RX current that is required for Mesh operations would be 4.6mA, as you can see here.

It is of course an option to use a proprietary radio protocol. Using this I would imagine you would need to imitate the BLE advertisements.

You can have a receiver that is always in RX mode. Then your sensor devices will broadcast a packet whenever the sensor is triggered. In order to receive the ACK, they would have to open the radio for RX in a short window after the TX, so the scanner would have to generate an ACK (given that the CRC was correct in the scanned message). If the remote device receives the ACK, it can go back to sleep, but if it doesn't receive the ACK, you would need to keep broadcasting this message every Xms, until the ACK is received.

Now, as I said, this looks quite like the BLE communication (ACKs and retransmission on missed ACKs). But the issue is that advertisements don't have ACKs, only BLE connections, and the nRF doesn't support 50 connections). 

Another approach is that the scanner could broadcast a BLE advertisement containing the known state of the devices. If the remote devices knows what bits that represent their own advertisement it can scan and check whether their last advertisement was picked up by the scanner. I am not sure if this one was clear or not. Let me know if it wasn't.

BR,

Edvin

[Alexander Menakhin]

Ok, I'll try opening an ANT ticket.

No, there's no specific reason for the nRF53, honestly, I just took the most advance device example from the website.

Yeah, proprietary radio is always an option, but it makes R&D much more expensive and I'd like to stick to some well-known robust tech if possible.

Each module will have 2 AA's, if it's Energizer Ultimate, then it'll be around 7000 mAh and I want it to last at least 6 months. But the modules will also have LED's, so connectivity is not the only major power consumption factor.

Edvin said:

You can have a receiver that is always in RX mode. Then your sensor devices will broadcast a packet whenever the sensor is triggered. In order to receive the ACK, they would have to open the radio for RX in a short window after the TX, so the scanner would have to generate an ACK (given that the CRC was correct in the scanned message). If the remote device receives the ACK, it can go back to sleep, but if it doesn't receive the ACK, you would need to keep broadcasting this message every Xms, until the ACK is received.

Now, as I said, this looks quite like the BLE communication (ACKs and retransmission on missed ACKs). But the issue is that advertisements don't have ACKs, only BLE connections, and the nRF doesn't support 50 connections). 

Another approach is that the scanner could broadcast a BLE advertisement containing the known state of the devices. If the remote devices knows what bits that represent their own advertisement it can scan and check whether their last advertisement was picked up by the scanner. I am not sure if this one was clear or not. Let me know if it wasn't.

Ok, I'll need some time to research and process that information :)