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

[awneil]

AdrianDE said:

most of the time a limit of 20 End Devices is suggested

Is it? Where?

Pretty sure that all those Mesh technologies are perfectly capable of well over 40 nodes!

Check the SoftDevice specifications, but I think the limit is 20 simultaneous BLE connections.

from your description, it doesn't sound like your Peripheral devices all need to be connected all the time? Or even most of the time?

it sounds like they could simply broadcast their status in their advertising, and the Central would only need to connect when it actually needs to send something to a Peripheral ?

[AdrianDE]

Hello awneil,

thanks for the quick reply! I know, mesh technologies can handle massive amounts of nodes but the usually rely on multiple line powered devices which can forward data and act as routers. However in my case, there is just one line powered device and a lot of battery powered ones which is not what mesh networks are designed for. Of course I was talking about the number of simultaneous connections to one router, not the total amount in a network.

I'm sorry if my description was misleading.
The peripherals need to be able to receive data from the cetral device all the time in order to know when their LED needs to be turned on. However they only need to transmit data if an object is in close proximity (which doesn't happen very often), that is correct.

What do you think would be the best way to implement this? Do you think BLE is the way to go?

Best regards
Adrian

[awneil]

AdrianDE said:

the usually rely on multiple line powered devices which can forward data and act as routers

I don't think that's true.

Perhaps you just need to try it. Buy a few DevKits - do some experiments ...

AdrianDE said:

The peripherals need to be able to receive data from the cetral device all the time in order to know when their LED needs to be turned on.

Surely, it only actually needs to be connected when the LED state needs to be changed ?

Perhaps you could reverse the roles - your gateway device could actually take the BLE Peripheral role, and your remote devices are BLE Centrals ... ?

You haven't said what battery you'll use. It sounds like these devices are going to be "permanently" installed - so can you us a (relatively) large battery?

[AdrianDE]

awneil said:

Perhaps you could reverse the roles - your gateway device could actually take the BLE Peripheral role, and your remote devices are BLE Centrals ... ?

This is a good idea! So you suggest the gateway is constantly advertising data which includes the information which LEDs need to be active and once a sensor is triggerd it connects to the gateway and sends it data, right?
Do you know what happens if multiple sensors are triggered at the same time? And how quickly will this system work? The object is moving quite fast, up to 3 devices per second. A timestamp will be included of course, but the remote devices can't know if the gateway is already connected, can they?

awneil said:

I don't think that's true.

"Bluetooth mesh profiles provide the basic infrastructure protocol to support the relay of messages from tags over a network of mesh relay nodes, which are typically line-powered devices" (https://wisilica.com/company/how-bluetooth-mesh-is-advancing-the-implementation-of-smart-building-technology-2/)

awneil said:

Perhaps you just need to try it. Buy a few DevKits - do some experiments ...

We already have one nRF52840 DevKit but I wanted to do the research about the protocol and topology before buying more DevKits because I can only decide which MCU to use once these questions are out of the way.

[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