This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

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

Parents
  • 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

  • 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.

    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?

  • 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.

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

  • 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.

    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

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

  • 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 Thinking

Reply Children
  • 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!

Related