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

[Edvin]

Probably not impossible, but I don't know the details of how it would work. But as for a power saving method, I don't think it would be beneficial, because all the nodes would then have to wake up, and set up the new parent node. Also, you I don't think you can have 40 LPNodes on one friend node (since a friend node is basically a modified BLE connection). Another issue is that a friend node can't send a message to a LPN unless it decides to wake up, you would have to turn on every one second in order to get 1s latency.

[Mishka]

The one second delay probably is not an issue. Please think about it as a power save mode. All nodes are "sleeping" in LPN role and waking up every few seconds to check network status, or if an interrupt occurs. If something interesting happened they won't go LPN anymore until there are tasks to do. But when finished, most of the nodes are going back to LPN. So the latency will only be visible on the very first event.

Interesting part here is which nodes will become the dedicated friends. To maintain this it will require some kind of distributed overlay network. The network should know how many nodes it has, and hence how many nodes required to be online all the time, i.e. number of dedicated friends.

There must be an election procedure to guarantee no nodes are lifetime friends draining their batteries. It's possible to promote the nodes with full battery, or the nodes which cover some particular areas better. After reaching agreement, information about dedicated friends is spread between nodes and the lucky ones will turn back into LPNs.

As for any distributed protocol, I don't expect it to be trivial. But just wondering can it be achieved without breaking Mesh compatibility.

Disclaimer: to not distract from the main topic, for this particular task a connection less BLE (like, first broadcasted - first served) might have the job done. And another promising option which I've mentioned earlier is the Wirepas Mesh. It's designed for battery operated devices. But know to little about it, sorry.

Mishka

[AdrianDE]

Hi Mishka,

after reading your comment I just attended the webinar as well and it sounds pretty interesting. Very similar to DigiMesh in terms of having just one node type. But the extra cost to get a licence is quite a bummer. I also asked them about the latency and current and 10ms is the latency if the devices are always on, not in low power mode. In low power mode the bitrate is 1kBit to 4kBit. However they didn't give any numbers on latency in this mode.

I'm still thinking about implementing a synchronized sleep on top of Zigbee. It seems like this has been successfully done by some people (take a look here for example: www.ece.uah.edu/~milenka/docs/am_ssst05_synch.ppt).
If anyone is reading this who has done it, I'd highly appreciate your help!