Protocol for up to 40 battery-powered devices and one central device

[AdrianDE]

Hello,

We are currently working on a project where up to 40 battery powered devices need to talk with one router/coordinator. Each device features a proximity sensor and an LED. They are mounted in an area of around 25 m in length and 2 m in width. However it is difficult to change their battery, therefore long battery life is crucial. There is one Central Device, which collects all the information from the sensors and decides, which LEDs need to light up. The devices need to track an object which will always remain on device no. 1 for a few seconds and then starts moving. So they only need to transmit data if their sensor is triggered (1 Byte of data) but they need to be able to receive data at all time in order to make the LED light up (large latency of 500ms or so is fine).

I hope you can understand the background of the application.
My question is, how such a network could be accoplished? Zigbee, Thread and Bluetooth Mesh seem to use a lot of RAM as the number of End Devices connected to one Router (or however they are called) goes up and most of the time a limit of 20 End Devices is suggested, but maybe I have missed something. Developing a proprietary protocol would probably provide the best result, however out Software Engineers are very busy at the moment and we've not worked with RF technology yet. So I'm favoring the easiest solution. My idea was to use a Star Topology and have the End Devices sleep periodically in order so save current. Once their sensor is triggered (which doen't happen often) they change their behaviour to an alway-on state, so do the closest neigbours (identified by their specific adress), so the object can be precisely tracked.

In terms of hardware we have been looking at the nRF52840, but this is not determined yet. Could it be an option to use two chips on the PCB of the central device and have each talk to 20 end devices? How far would they have to be apart from each other so they don't interfere with each other to much?

If you have any ideas or suggestions I'd highly appreciate your help!

Best regards
Adrian

[AdrianDE]

Thank you very much for the explanations Edvin! That was very helpful for my understanding!

Having two centrals sounds like the best option out of the ones you suggested, however space is also limited in the gateway, so the modules could not be placed very far from each other (approximately 10cm). This would probably harm RF-performance but as the range doesn't need to be very large it should still work.

Mishka said:

By the way, having the central scanning all the time will drain its battery very fast. Adrian, is it supposed to work from a battery too, right?

It is going to be battery-powered as well, that's right. This battery can be much bigger (5 Li-Ion cells for example) and it can be changed more easily but this comes at a certain price so having a longer battery life on the central would be very desirable.

A colleague just pointed out to me, that Digi's Xbee series has a very interesting feature called synchronous sleep. It builds on top of a standard Zigbee Mesh, but all nodes including the routers are only active for a short amount of time and go to sleep afterwards. This has already been discussed in the forum and sounds like a promising solution: https://devzone.nordicsemi.com/f/nordic-q-a/46241/synchronized-network

[AdrianDE]

Mishka said:

may it be possible to have all nodes as LPNs with a couple of friend nodes elected every hour or so?

That's a brilliant idea! If BLE has an issue with changing the node type from time to time, would it be possible (or maybe easier) to implement this in Zigbee or Thread?

[Mishka]

Hi Adrian,

I just finished watching the webinar on the Wirepas Mesh. It looks like with 10ms latency and 25 µA average current consumption, this mesh solution could be the answer

[Edvin]

Mishka said:

may it be possible to have all nodes as LPNs with a couple of friend nodes elected every hour or so? The LPNs are sleeping for most of the time and awake upon interrupt from the magnetometer or the capacitance sensor, or every 5 seconds. On wakeup they flush message queue from the friends and go back to sleep.

 I don't think they can take turns on being full nodes. A node needs to know what node to report to once it wakes up. If this is an option, I think it is better to use BLE connections, and takes turns on connecting.

 

Mishka said:

With connectable advertisements, would it be possible not to keep the connections on the central, but rather connect, send the light state, and then drop the connection thus maintaining number of concurrent connections below 20?

 Yes. That is possible. Again, you can send the state of the sensor in the advertisement, but since advertisements doesn't have ACKs, you can use the connections as ACKs, if the central only tries to connect to the device if they change the advertisements according to the sensor input. This is a viable option. Then the central can cycle through the devices, connecting to them and letting them know if it has any data to them. It would only need to connect to the nodes it actually has data for.

[Mishka]

Edvin said:

I don't think they can take turns on being full nodes. A node needs to know what node to report to once it wakes up.

Do you mean it's technically impossible to drop LPN role and become a usual node?