BLE Mesh intermittent behavior

[swanav]

We are trying to evaluate the BLE Mesh for a product range and are evaluating the nRF52832 for the same.

Working with the nRF Mesh SDK, I am facing some issues, which are not desirable. I am pretty sure this might be a configuration issue, but I am not able to find the remedy for the same.

I am using the provisioner example from the mesh sdk to provision devices.

1. First off, the Provisioner Scanner returns the un-provisioned device beacons at a 5 Second delay. There seems to be no way to accelerate this scan. I want scan results within a second, so that I can provision the devices as soon as I enable the mode from my provisioner.

2. The duration for each message exchange seems to be slow as well. Provisioning and Configuring the Device is very slow (Takes around 2 seconds). Same is observed for the devices once they are provisioned.

3. The recipient device seem to miss messages every once in a while (I know some packet loss is expected, but this seems to be very frequent, with 1 out of 5-6 messages lost). Tmeshe messages are also not frequent. (Once a second at max). I had 2 nodes (ESP32 and nRF52840) listening to the same group address and the behavior observed would be very intermittent, where One Device would sometimes receive the message while other wouldn't).

I have spent a fair amount of time digging through the SDK, hoping to find something which will fix this issue, but couldn't. 

OS:

   Windows 10

SW Version: 

   nRF SDK Version: 17.0.2 (d674dde)

   nRF Mesh SDK Version: 5.0.0

[Mttrinh]

Hi,

1. We ran the provisioner example with the Light Switch server, and received the beacon and got a printout in RTT within about a second. we can't see this 5 second delay you are seeing. Do you use an unmodified version of the example?

2. Our team need some more time to investigate this, will update you as a soon as possible.

3. Are you talking about provisioning messages or mesh messages in general? One of 5-6 packets going missing is definitely not good in any case. Are you in a noisy environment perhaps? We haven't heard of this being an issue before.

[swanav]

Hi Mttrinh,

1. We provision the device only if the RSSI of the unprovisioned node crosses a certain threshold. So, while the unmodified example does work the way you mention. If we add this condition and the device is beyond the desired range, the beacons will be scanned each 2 (not 5) seconds. If we bring the node close to the provisioner and move it away within this 2 second interval, the node won't be identified by the provisioner and we miss out on the chance to provision it. I am wondering what is the way to minimise this 2 second interval.

3. The provisioning messages are more reliable, but the consequent mesh messages are troublesome.