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

[Mishka]

Hi,

The battery powered devices have a LED and a proximity sensor which have to cover distance up to 2m - the tunnel width. Of course, it depends, but those two together may drain the battery much more than the Mesh.

Also, it seems the that the 40 nodes are not talking to each other. But is it really important to have such a feedback from the moving node no. 1? When a fixed node detects presence of the moving object and reports it back to the object, for what reason it waits for an additional approval from it? I mean, if the task is about finding location of the moving object it might be possible to switch to the Bluetooth 5.1 direction finding.

However, if the moving object carries no Bluetooth node, like in a smart lighting project where path of a moving person needs to be lighted ahead of the person, it might be better to stick to the Mesh. The communication between nodes may help to build some advanced features like predict direction of the movement, and avoid turning the lights off when the person weren't leaved the tunnel yet, but is out of the proximity sensors.

Mishka

[AdrianDE]

Hello Mishka,

the example you gave is very good for how this system should operate (even though it's quite far from the actual usecase): The person enters the door and stays there for a while to take of the shoes and so on. Then he starts to walk through the room where he needs to be tracked and in front of him there are LEDs lighting up. Furthermore all LEDs must be controllable from one central gateway... All nodes are stationary, node no. 1 is just how I called the one near the "door". This sounds like a standard usecase for mesh applications, however as mentioned all the nodes are battery-powered (by a single 18650 Li-Ion Cell).

The proximity sensing hardware is actually already finished and it uses very little power by relying on a combination of a capacitive and a magnetic sensor. Furthermore the LEDs will be very rarely activated but the peripheral devices need to listen all the time if they should turn on or not. Of course the LEDs will be consuming a significant amount of power but it's probably not going to be more than 30%. I hope to get the average current for the RF Module down to 1mA.

Mishka said:

The communication between nodes may help to build some advanced features like predict direction of the movement, and avoid turning the lights off when the person weren't leaved the tunnel yet, but is out of the proximity sensors.

These features (or at least similar ones) are actually very important, that's true! I was thinking about putting all the intelligence in the gateway and having "dumb" nodes which just send sensor data and receive the information of the LED-Status. What to you think? Is this less ideal than a true mesh?

[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?

[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