nRF51-ble-bcast-mesh
nRF51-ble-bcast-mesh copied to clipboard
NordicPlayground
Power usage
Hi, I noticed that enabling the meshing functionality adds a lot of power consumption (going from 20μA to 13mA). Is this the expected behaviour? Also: which settings would change the power consumption the most? Slightly unrelated question: could you show a time line example of what a node is doing? When it broadcasts, when it's listening, maybe including normal advertising or while its connected. This would help me a lot to understand the different settings and how the meshing affects/is affected by other communication.
Hi, this is the expected behavior. In order to minimize propagation delay and maximize throughput, the mesh attempts to keep the radio in RX mode for as much time as possible. The mesh in its current form isn't intended for battery powered operation, and no real effort has been put into reducing the power consumption.
Currently, there are no configuration parameters for reducing power consumption for the mesh, as its core propagation scheme doesn't really allow for any significant power consumption reduction. If you want low power devices to participate in the mesh, I recommend that you make those devices connect to a full-fledged mesh-device through a regular Softdevice connection, and let the mesh-device act as a proxy, relaying any messages to and from the mesh through its SD GATT server. As of v0.6.8, the mesh supports the S130 softdevice, which allows the devices to act as masters (you could try your luck with the S120 as well, but it isn't officially supported, so your milage may vary).
We'll look into putting in a timeline for the next release, sounds like a good way to demonstrate the behavior.
Hi Trond, The power consumption seems to be a formidable issue. Is there any change or update as of yet?
The re-broadcasting mesh will initially be used only for high powered relays. The leaf nodes can be battery operated. That will be the initial usecase that was targeted, lowering the power consumption will be done but only after the intial usecase has been fulfilled. If low power and range is a need you can look at the Fruity mesh which uses the softdevice S130 to create a mesh using BTLE Connections between Central and Peripheral.
I have also just hit the power consumption issue after spending a LOT of time on using and implementing the library. It is very strange that this issue is mentioned nowhere! To me it should be the first sentence of the description. Quite contrary you write that:
The value propagation is controlled by an implementation of the IETF RFC6206 "Trickle", a flood control algorithm for lossy, low power networks.
Is this a bad joke or what?
You can constrain the power usage in 2 ways directly, reduce the scan interval and increase the advertising interval. This will hit the propagation delays across the mesh but will reduce the power consumption. However we have not focused on this use case, however this is possible.
As long as I understand then advertising interval is logarithmic so it should not be a problem, right? The problem is probably with having radio in RX all the time. Is it not possible to synchronize all the devices in the mesh so they know when exactly they should start and stop RX because they know that others will advertise at the time?
It is like having exactly predefined global timeslots a couple of milliseconds long when radio is active so you know that you do not need to use radio in RX in the remaining time because you will not receive anything anyway. Lets say that the timeslots are 20ms every 500ms. Then the radio RX will be active only 4% of the time so power consumption should go from 14mA to 0.5mA.
Does it make sense? I am willing to help implementing it but I do not know the library much so it would be a challenge :)
We do not have the sync mechanism for the RX but the discussion in issue 96 could be used to get the common clock as a start point. Neighbourhood slots in time may be simpler to manage as opposed to global ones but yes, your approach of synchronizing slots will lower power consumption.
Ok, thanks. Will take a look at it. Could you point me to the relevant *.c files that I should start with for RX syncing?
BTW: Shouldn't you really make a clear statement at the front page description that it is NOT suitable for low power devices? As it is now, it is very misleading...
We will add the pointers to the sync in issue 96 where it is being discussed. Understand the issue and will look to mitigate it.
Thanks for you help. I will probably stop rbc mesh on all devices and start it every 15 minutes, run it for 10 seconds with high advertising frequency to spread all new measurements and then turn the rbc mesh off again. That however requires common time keeping in the mesh so that the devices know when to turn the mesh broadcasting on and off. For now I will supply the time when uploading the program and hope it will remain accurate down to 1 second when using app timer but it would definitelly be great if the common time was automatically synced accross the mesh ;)
Dear David,
what is the status of providing pointers on how to implement the local or global time synchronization into the library. I face a situation where the devices should run preferably several years on single battery. The devices will wake up very sparsely (maybe once a day) to do the measurements and to send it to a base station through the BLE mesh. This however requires that the devices are more or less time synchronized down to ca. 1 second accuracy to wake up at the same time, send the information out and retrieve information from others.
A simple idea that I would like to implement is that during transceiving of the measurements the base station will broadcast current time (obtained from GSM). Nearby devices will obtain the time information, offset it by approximate transmission duration and broadcast if further. This way the time information would get spread through the mesh. I believe that with this simple approach I could maintain 1 second accuracy. What do you think? Any pointers how to implement that?
You can easily get the support for the required situation on leaf nodes without too much trouble. However getting this on the routing nodes i.e. waking up once a day would mean that all the routing nodes need to be synchronized to the instant, which is a bigger challenge.
First lets comment on your approach, to save power on synchronizing we need to sync using the 32KHz clock, the 32KHz clock with an RC source has a drift of 250 ppm, the 32KHz clock when driven by a crystal can have drift of 20ppm. Lets assume you are using the crystal and conditions are ideal (no packet loss due to interference), i.e. the RX needs to on for 20s for every 1 million seconds.If we scale this, we need the RX to be on for 2ms for every 100s to get the sync message. In practice so multiple sync messages appear more efficient so we can have shorter RX windows, so we do need a lot more messages in a 24 hour period. In practice we will lose messages due to interference so some re-transmit scheme/catchup scheme is also required. The "master time server" would also need to be in RX almost continuously, which means that the master node cannot be low power.
However we will add more detailed comments to #92 by next week.