setup configuration nRF5 SDK for mesh sensor network with aggregator

[wimp]

Hi,

I am working on a development where the values of a bunch of nodes with a sensor needs to be captured in one aggregator device in a mesh network. The aggregator then sends all aggregated data through its serial link or other communication channel. The readout of the sensor data is only required on a very slow timebase (once per hour or even less) so the nodes can go into a low power state in between. All nodes are battery powered and required to have a long lifetime. The aggregator can be mains powered.

I started from the light dimming example which seems to resemble closest to my needs but I am struggling to determine who has to be server and client. And as the number of nodes is variable how do you determine the amount of elements and/or modules?

I am fairly new to mesh networking so I could use some help to get started with the correct setup for my network. The reason to go for mesh networking is that the RF environment is not stable and might require relaying through other nodes to reach the aggregator device. Also nodes might change location but is probably less influencing than the RF environment.

Does anyone have a similar use case and willing to share your setup configuration or even code example? I have searched around and although this seems the perfect use case for an nRF5 SDK for mesh example project I could not find anything.

Thanks for any help that can advance my project. 

[Hung Bui]

Hi Wimp, 

Could you give more information about your mesh network ? What's the range between the nodes  ? And what's the max range between the node and the aggregator ? What is the maximum number of nodes ? 

Note that a node running on constrained power consumption can't do relaying on a normal Mesh network. In BLE mesh the relay nodes have to be main powered. 

If all the nodes except for the aggregator node has to be battery powered, and if you don't have a large number of node to connect to, you can think of using the normal BLE connection instead of Bluetooth Mesh. Nordic's BLE stack can support up to 20 BLE links and you can connect multiple of star BLE network together. This would work with a limited number of node and network. It would be too complex to maintain when you have lots of node, for example 100 nodes. 

Regarding your question, you can define a single element on the aggregator which has a client . All other nodes can have a server and they report to the client on the aggregator. 

[wimp]

Thanks for your time to help me out.

To answer your questions: I have no clue about the range but it will be a harsh RF environment with interferers and objects in between which will give a considerable attenuation. This project is a testcase to find out the behavior and possibilities to use such a system in this kind of environment. The number of nodes can definitely be more than 100 units.

To overcome the relaying problem, isn't it possible to have the whole mesh powered on for lets say 5 minutes every few hours and then go to sleep again? During this time they can send their data and resychronise their wakeup timers. How long would it take to re-establish the mesh after wakeup?

Can you clarify a bit more how to configure the client please. So a single element with multiple modules then? But it is still unclear to me how to know the number of modules to provide. Or do the servers all publish to the same address and there is just one module in the client subscribing to that same address? In that case how do you differentiate between the nodes and make sure all nodes have been read?

Many questions while I am trying to build up experience. Please be patient with me. Thanks.

[Hung Bui]

Your option of turning on the mesh network for 5 minutes every few hours may work if you don't have a requirement to have shorter latency. When active the current draw by mesh could range from 7mA to 9mA (depends if the CPU have to process data or not), sleep current (with RTC on) is about 2uA. You can do the calculation on the battery life base on these numbers.  But I don't think it would last for a few years in this scenario, unless you use very high capacity battery. 

The network is established right away after the node wakes up (no connection time). But you need all the node to be on to make sure the messages are relayed. So they have to be in sync and clock drift have to be considered. 

Another option is to have a few relay nodes that is main powered works as the back bone of the network. This way your sensor node doesn't need to stay active for a long time and can work with much smaller battery. 

The client-server model I suggest is to have multiple servers (one on each node) to report to a single client (on the aggregator)  . All server report to the same address (can be unicast or group address)