BLE Mesh intermittent behavior

RE: BLE Mesh intermittent behavior

Mttrinh — Mon, 15 Mar 2021 10:06:40 GMT

Hi,

[quote user="swanav"]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?[/quote]

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.

[quote user="swanav"]I also seem to be still missing some mesh messages (approx 1 out of 6), not sure what that is about.[/quote]

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.

RE: BLE Mesh intermittent behavior

swanav — Wed, 10 Mar 2021 05:59:14 GMT

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.

RE: BLE Mesh intermittent behavior

Mttrinh — Thu, 04 Mar 2021 19:29:36 GMT

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

RE: BLE Mesh intermittent behavior

swanav — Wed, 24 Feb 2021 16:32:25 GMT

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.

RE: BLE Mesh intermittent behavior

Mttrinh — Wed, 24 Feb 2021 16:20:18 GMT

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.