Related to Mesh Network Issue

[Anil.N]

Hi Everyone,

I am new to BLE protocol, and coming to our issue we are working on a project in which we used nRF52840 controller for communication between peripherals in the mesh network and the commands which we are sending through the mobile application are also transferred through the nRF over the mesh network by Broadcasting the commands.

Now we are facing an issue that few peripherals are not receiving the commands in mesh network and so they were not able to respond accordingly.

As a solution we are trying to implement the Handshaking method between the peripherals, but i am not able to get that how exactly to implement the Handshaking method in Broadcasting as i don't know the id's of the peripherals which are connected in the network. and how can we implement handshaking in broadcasting type

Awaiting for helpful reply,

With regards,

ANIL. 

[Simonr]

Hi

 What SDK are you using for development, the nRF5 Mesh SDK or the nRF Connect SDK based on the Zephyr RTOS? If you're new to Bluetooth Mesh I would recommend checking out the Bluetooth Mesh stack user guide here to learn of all the concepts specific to Bluetooth Mesh.

I assume the nRF52840 in this instance is acting as a relay, that relays information between a source/provisioner to the end nodes? As long as the end nodes are in range and wake up every now and then to check if there are any messages from devices in the network you shouldn't have to know which device specifically to broadcast to.

What devices are these Mesh peripherals/end nodes in your network? Are you sure the nodes are on, and haven't gone into sleep or system off due to a timer of some kind? It might also be that the nodes have timed out and left the Mesh network. If that's the case, it should be reported that a node has left the network on the provisioner side.

Best regards,

Simon

[Anil.N]

Hi Simonr,

Thanks for your valuable reply,

we are using nRF5 Mesh SDK, v4.2.0 the mesh peripheral is a relay used for lightning and we call it as CB.

basically we connect all the CB's to mesh network and later if the switch is pressed the command(cmd) is broadcasting via BLE and after the fist CB reached it will transfer to the other and it goes on to the all the CB's connected in the Mesh.

Here is the problem that we are facing ie., some CB's are not responding to the cmd when switch is pressed and if we pressed the switch for another time then it is responding, which means that CB is not receiving the cmd even though it is in mesh network.

One more thing that can how can we get the id's of the devices that are connected in the mesh ?? if we able to get the id's then we can implement the handshaking method to over this issue...

Thank you,

ANIL. 

[Simonr]

Hi

Thank you for explaining. So all end nodes are nRF52840 devices, correct? Can you explain what you mean by handshaking, from what I can see there isn't a "handshake" concept in Bluetooth Mesh, so I don't quite understand what you mean here.

One thing that could have happened is that the sequence number counter was cleared or reset at some point. If the sequence number is lower than the highest sequence number seen thus far, the message will be discarded to prevent replay attacks. If you have a limit to the sequence number, it's also possible that it reached the limit before the message got to the end device that were supposed to get it.

The way outgoing sequence numbers are treated and stored, power cycling the device will lead to a "jump" in sequence numbers sent of up to around 8 thousand. Power cycling the device will therefore give a jump in sequence number of 8k which could be use to get it "up to speed" quicker. (The reason for this 8k jump is the number is stored to flash in bulks, to reduce flash wear. Large bulks are "reserved" at a time, and the exact number only held in RAM. On reset, the last sequence number sent may be anything within that bulk, so a new bulk is reserved and numbers start from the beginning of that bulk. With the default bulk size of 8k, each power cycle will get the device to start from the beginning of  the next such bulk. This is implementation specific, and not part of the specification.

If all nodes are broadcasting to all nodes, or all elements on all nodes are broadcasting to one or more elements on all nodes, then the RPL for each node must be large enough to fit all those sender unicast addresses. If that's the case, it would be a good idea to design your solution such that nodes are not relying on receiving messages from all other nodes in the network.

Best regards,

Simon