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]

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 :)