BLE Mesh on Nrf52832 Event based System on Sleep. Anchor and Tag are Battery Powered.

[starkAbhi]

Hi,

i am using nrf connect extension in vs code with Zephyr OS build v3.2.99-ncs2 and Nrf connect SDK 2.3.0. Our Application requirement as Shown in below Image.

Anchor:   Sleep -> Wakeup on BLE event -> Receive message and Process data -> Message Carry forward to Gateway-> Goes back to sleep. Anchors are Battery Powered. how can i achieve sleep mechanism with nrf52832 soc?  because continuous reception leads to more power consumption. it drained out battery very quickly. are there any available example on sleep in reception of BLE Mesh?

Problem in Flooding messages on Anchor side: How can i prevent from flood of messages ?

Regards

Abhishek

[tesc]

Hi,

If the data must be relayed from anchor to anchor before reaching the gateway, then the anchors must be Bluetooth mesh relay nodes, which means they must be constantly in RX. This is by specification, and this is how the relay nodes are able to reliably relay messages over the network. There really isn't any way to change that behavior. Relay nodes will constantly consume around 6 mA.

Bluetooth mesh relies on having a backbone of relay nodes that are always on, for transferring messages over the network. Low power nodes (LPN) can save power and only turn on the radio when they need to send something or check for incoming messages. Relay nodes, on the other hand, must be always on.

One pattern, is if you have relay nodes (always on) listening for advertisements from beacons. Then the beacons can have even lower power than LPN, but they cannot receive any information from the mesh network itself. This is what we do for the Bluetooth: Mesh Silvair EnOcean example, which listens for advertisements from a specific switch which is powered solely by the button presses. Please note that the listener is a normal mesh node, always in RX, just as relay nodes. It is not an LPN.

Problem in Flooding messages on Anchor side: How can i prevent from flood of messages ?

I do not quite understand what you mean by that. Can you please elaborate?

Regards,
Terje

[starkAbhi]

Hi tesc ,

My other Ticket regarding

Tags: Sleep -> Wakeup-> Transmit Message-> Sleep periodically in interval of 5 min. Tags are Battery Powered. how can i achieve sleep mechanism with nrf52832 soc? system off example only put whole mesh tag in Deep sleep. are there any example in which it starts mesh -> send data-> back to sleep with ~ 2.2uA current consumption?

tesc said:

If the data must be relayed from anchor to anchor before reaching the gateway, then the anchors must be Bluetooth mesh relay nodes, which means they must be constantly in RX. This is by specification, and this is how the relay nodes are able to reliably relay messages over the network. There really isn't any way to change that behavior. Relay nodes will constantly consume around 6 mA.

In conclusion, Continuous reception lead to more current consumption in mesh. are their any API or Function to set transmission Power dbm?

tesc said:

I do not quite understand what you mean by that. Can you please elaborate?

 All Tags are sending message to gateway though Anchor.  Anchor act as Relay. All each Anchor want to transmit their message to Gateway. One tag range in Between multiple Anchors. it become cluster of messages. does this lead to flooding of messages on Anchor side? are their any repeat of messages protection in Mesh?

Regards

Abhishek

[starkAbhi]

Hi Terje,

tesc said:

What are the Kconfig warnings referred to in the build log?

It is solved by Pristine build.

How can set/change data rate of BLE Mesh Tag and Anchor?  My requirement is to have fast data transmission between anchor and tags. Data exist in air for minimum time.

Regards

Abhishek

[tesc]

Hi,

starkAbhi said:

It is solved by Pristine build.

I am happy to hear that you solved it. Pristine build may be needed sometimes, especially when changing configurations.

starkAbhi said:

How can set/change data rate of BLE Mesh Tag and Anchor?

There is no setting for data rate in Bluetooth mesh. There is a restriction of data rate out from one node (see next paragraph) but apart from that the limitation comes from factors such as packet collisions and congestion.

There is a limitation of maximum 100 network PDUs per 10 second sliding window, which limits the theoretical throughput out from one node to somewhere above 100 bytes per second. This limitation is from the specification itself, and the purpose is to keep the number of packages sent reasonably low for reducing the risk of congestion.

Regards,
Terje

[starkAbhi]

Hi Terje,

tesc said:

There is no setting for data rate in Bluetooth mesh.

What are the default values of data Rate in  BLE Mesh Network?

tesc said:

There is a limitation of maximum 100 network PDUs per 10 second sliding window, which limits the theoretical throughput out from one node to somewhere above 100 bytes per second. This limitation is from the specification itself, and the purpose is to keep the number of packages sent reasonably low for reducing the risk of congestion.

I did not get it. Could you please explain it with some examples? 

Regards,

Abhishek

[tesc]

Hi,

starkAbhi said:

What are the default values of data Rate in  BLE Mesh Network?

There is no default data rate, as it all depends on the size and topology of the network, the amount of messages sent from the devices on the network, and the number of hops those messages are allowed to take.

starkAbhi said:

I did not get it. Could you please explain it with some examples? 

Messages in Bluetooth mesh can be up to a couple of hundred bytes maximum, but then get divided into several packets. A single packet can hold 11 bytes payload. Each node (each device in a network) can send a maximum of 10 packets per second. Your tags are well within this limitation.

In addition, relay nodes can relay messages at a rate of several tens of packets per second. Your relay nodes (the anchors) should be able to handle the throughput coming from your 2 000 tags, although there may be some packet collisions which can be handled in several ways, for instance:

• Accept that some messages gets dropped.
• Retransmit messages.
• When sending a message, the value from the previous message (or from the N previous messages) to that message. Values then arrive late, but you get the full data series.

Which solution is the best relies on your requirements.

I highly recommend reading up on Bluetooth mesh, in order to understand how the technology works and what are the limitations.

Regards,
Terje

[starkAbhi]

Hi Terje,

Thanks for your support

tesc said:

I highly recommend reading up on Bluetooth mesh, in order to understand how the technology works and what are the limitations.

I am actually reading more about mesh network in BLE Stack.

tesc said:

In addition, relay nodes can relay messages at a rate of several tens of packets per second. Your relay nodes (the anchors) should be able to handle the throughput coming from your 2 000 tags, although there may be some packet collisions which can be handled in several ways, for instance:

it would be nice to have Sync in tags to handle collision. let see.

Regards

Abhishek