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

[awneil]

Mishka said:

those two together may drain the battery much more than the Mesh

My thoughts exactly!

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

[Edvin]

Hello,

Just want to add to the conversation that the reason Mesh nodes typically draws more power is because they have the radio on at all times in order to scan for incoming packets. The reason this draws more power than a normal BLE connection is that BLE connections only use the radio in short bursts. 

If you use the remote devices as scanners, it will draw more current than an advertisement. Actually, the radio consumes a very similar amount of current in RX and TX mode. Scanning is therefore a more current hungry procedure, because you typically have a scan window which is a lot longer than the TX window used for an advertisement.

It works like in this figure:

(Source: https://devzone.nordicsemi.com/nordic/short-range-guides/b/bluetooth-low-energy/posts/bluetooth-smart-and-the-nordics-softdevices-part-1 )

In a mesh the scan window will be close to 100% of the scan window, so if you have the remote devices scanning with 50% of the scan interval, then it will consume ~50% of the mesh current consumption.

This is also the reason why a phone usually does the scanning, because they typically has the bigger battery.

This doesn't solve the issue, unfortunately. In order to send data both ways, it requires either a connection or some sort of Mesh. The maximal number of connections you can maintain with an nRF is 20 devices, so that would require at least 2 centrals. Is that an option?

Another possibility is to use a mesh, which has really low latency, but a bit higher current consumption.

A third option is to have some sort of network consisting of BLE connections. This is a bit more work, but you could have some nodes that are connected to each other, and then one of them will report back to the main central.

Fourth option is using advertisements only, that the central can scan, but then you need to find a way to send data back to the nodes. Either by connecting when you have data to send, or by perhaps sending advertisements from the central, that the nodes scan for. But this will again require more power, since the nodes will have to scan.

The last option would be to use something proprietary (not BLE). Send a packet from nodes whenever you have data, and scan for a few ms after that. This will be quite similar to BLE, but doesn't need to follow the specification, and you don't have the limit of 20 connections.

BR,

Edvin

[Mishka]

Edvin said:

Just want to add to the conversation that the reason Mesh nodes typically draws more power is because they have the radio on at all times in order to scan for incoming packets. The reason this draws more power than a normal BLE connection is that BLE connections only use the radio in short bursts. 

Hi Edvin,

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.

A simple friend election procedure, for example, in a random manner, will distribute the battery load among all the nodes, so for 40 total nodes and 2 friends each node will consume about 10 mA * 2/40 = 0.5 mA in average. 10 mA here is the RX radio + some other expenses.

Mishka.

[Mishka]

Edvin said:

Fourth option is using advertisements only, that the central can scan, but then you need to find a way to send data back to the nodes. Either by connecting when you have data to send, or by perhaps sending advertisements from the central, that the nodes scan for. But this will again require more power, since the nodes will have to scan.

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?

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?