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. 

[Mttrinh]

Hi,

An update from our developer:

Are you doing RSSI filtering using the bearer filter in rssi_filter.h, or are you rolling your own on the app level?

For the observed 2 seconds between scanned beacons: If I set the interval (and window) lower (to e.g. 300 ms) using

scanner_config_scan_time_set(300000, 300000);

This will make the scanner call the cb every 300 ms. I still only get a beacon every ~2 seconds, but this is because the unprovisioned device advertises the beacons according to NRF_MESH_PROV_BEARER_ADV_UNPROV_BEACON_INTERVAL_MS which defaults to 2 seconds. Setting this to a lower value in the provisionee, in addition to the lowering of scan interval mentioned above, makes the scanner pick up the beacon at a faster rate, which I guess is what they are trying to accomplish here

[swanav]

Hi Mttrinh,

Sorry for the delayed response. It seems like the issue with the Provisioner Scanner has been resolved. I had tried out the scanner_config_scan_time_set API. But NRF_MESH_PROV_BEARER_ADV_UNPROV_BEACON_INTERVAL_MS turned out to be the culprit in my case. Once I verified that the nRF52840 Mesh Node was detected at a faster rate, I dug through the ESP-BLE-MESH SDK to find a similar parameter. (Seems like they haven't made that parameter configurable). Now the detection works properly and the performance is great!

But the rest of the latency and reliability issues still remain.

I am not sure how long the provisioning process for a single node should take in an ideal scenario. But a period of 3-4 seconds feels like a lot. Is this normal?

I also seem to be still missing some mesh messages (approx 1 out of 6), not sure what that is about.

[Mttrinh]

Hi,

swanav said:

I am not sure how long the provisioning process for a single node should take in an ideal scenario. But a period of 3-4 seconds feels like a lot. Is this normal?

If you also include configuring in the provisioning process (which our provisioner example does), then for a not so complex node, that does not seem entirely unreasonable. Our developer is having a look to see if there is a way to speed things up.

swanav said:

I also seem to be still missing some mesh messages (approx 1 out of 6), not sure what that is about.

Are you testing in a noisy environment? Also are you testing with 2 Nordic devices/DKs? If not could you try this and see if there is any improvement.