Mesh relay enable/disable

[Peter Gombos]

Hi!

We would like to install approx. 2000 pcs BLE devices in a mesh network. The device density is quite high (2x5 meters matrix, same level, no objects).

I think only couple of nodes should have relay functionality. Too many relays cause extreme network load, message cache overflow and ineffective network operation.

I plan to enable the relay function in 80 devices only. The distance between relays is 10-15 meters. The number of hops between the longest ends is about 20 hops, so TTL will be set to 24.

I plan to disable the relay, proxy and the advertisement functions in the normal nodes.

Is my approach correct? Will it work? What do you recommend to optimize the network? Shall I play with the retransmission parameters?

The next question is related to enable/disable relay functions: I would like to use the same fw in the nodes. Enable the relay is a configuration parameter. I couldn't find API function to do this. However there are public functions in the mesh source code core/include/network.h like network_opt_get/set. (mesh v5.0)

Is it recommended to use these functions to tune the relay function?

[Mttrinh]

Hi,

Your approach seems to be fine. Not having all your nodes in the network beeing a relay node is an intended way of doing it. Like you mentioned, having too many relays will cause a huge load on the network and disturbance between the nodes. 

As for your question regarding the API for enabling/disabling the relay feature, I think you can use it but not entirely sure. I will have to discuss this with the mesh team and come back to you with an answer on Monday.

[Mttrinh]

Hi,

Peter Gombos said:

What is the recommended way to stop advertisement but remain the member of the mesh?

By "stop advertising" I assume you mean disabling the proxy functionality? You can disable proxy by setting this define MESH_FEATURE_GATT_PROXY_ENABLED to 0.

[Mttrinh]

Hi,

The chip variants are very much alike, so it shouldn't cause any issues, Is there a external 32kHz crystal on the "noname modul"?

If you don't you can try switching to the RC Oscillator to test to see if that is the issue?

[Peter Gombos]

Honestly I don't know much about the clock source of the module.

Shall I change the bootloader sdk_config.h? I did so but nothing changed

#define NRF_SDH_CLOCK_LF_SRC 0
#define NRF_SDH_CLOCK_LF_ACCURACY 1

[Peter Gombos]

The module made by Minew. The doc says: "Integrated DCDC inductor and an external 32.768K crystal oscillator reduce design complexity and BOM cost."

[Mttrinh]

Hi,

Try this.

[Peter Gombos]

Hi,

It doesn't help.

As I wrote earlier the module _has_ LF oscillator. This is not the issue.

It is so strange. If I disable the proxy by the "#define MESH_FEATURE_PROXY_ENABLED 0" I have the same assert.

I tried the light switch server example and it behaves the same. The assert happens after couple of seconds.

[Mttrinh]

Hi, 

Looking into the assert you get, it means that the SoftDevice got an unexpected radio interrupt which is typically because the application used the radio outside of the timeslot. You can try to increase TIMESLOT_END_SAFETY_MARGIN_US in steps of 100 us upto 1000 us and see if that helps.

Though it seems strange that you get the assert as well if you disable the proxy by the "#define MESH_FEATURE_PROXY_ENABLED 0".

[Peter Gombos]

Hi!

Tried with 200 us no success. But the next step (300 us) eliminates the assertion. It works!

What could be the reason? How does this modification impact the performance?

[Mttrinh]

Hi,

It is hard to tell what the exact reason is but it is related to the clock source on the module device(Minew). 

Increasing the margin should not create any other problems than potentially decreasing the performance of the node a bit. Having a longer margin would mean that a longer timeslot would be needed. Which might make throughput a bit lower, or might not. So if peak throughput is not an issue then you will probably not notice any effects from increasing the margin.

There have been a long discussion in a similar thread, not sure if it is the same issue but might be worth to have a read.