About the mesh configuration failure

[caca1989]

I use ble_app_uart（sdk 14.2） + light_switch（mesh1.0.1）

Questions are as follows:

1client + 1server is ok, but in the second server there will be network failure!

log：

<t:         16>, nrf_mesh_sdk.c,  191, Initializing softdevice
<t:         22>, nrf_mesh_sdk.c,  206, Initializing mesh stack
<t:        576>, nrf_mesh_sdk.c,  214, Enabling mesh stack
<t:        586>, main.c,  283, Setting up access layer and models
<info> app: UART Start!
<t:     455425>, provisioner.c,  272, Local provisioning link established
<t:     457025>, provisioner.c,  258, Using static authentication
<t:     468332>, provisioner.c,  267, Static authentication data provided
<t:     480932>, main.c,  503, Provisioning complete. Adding address 0x0100.
<t:     480941>, provisioner.c,  111, Getting composition data
<t:     483114>, provisioner.c,  314, Composition data: 0059000000000020000100000002010000020059000000
<t:     483122>, provisioner.c,  119, Adding appkey
<t:     484445>, provisioner.c,  227, Local provisioning link closed
<t:     484604>, provisioner.c,  128, Binding appkey to the Health model
<t:     486125>, provisioner.c,  140, Binding appkey to the Simple On/Off model
<t:     487372>, provisioner.c,  165, Setting publication address for the health server to 0x0001
<t:     489535>, provisioner.c,  187, Setting publication address for the On/Off server to 0x0001
<t:     491739>, provisioner.c,  196, Adding subscription
<t:     493364>, main.c,  466, Configuration of device 0 successful
<t:     816497>, main.c,  405, Node 0x0100 alive with 0 active fault(s), RSSI: -27
<t:     847993>, provisioner.c,  272, Local provisioning link established
<t:     849222>, provisioner.c,  258, Using static authentication
<t:     860601>, provisioner.c,  267, Static authentication data provided
<t:     872955>, main.c,  503, Provisioning complete. Adding address 0x0101.
<t:     872964>, provisioner.c,  111, Getting composition data
<t:     875645>, provisioner.c,  314, Composition data: 0059000000000020000100000002010000020059000000
<t:     875653>, provisioner.c,  119, Adding appkey
<t:     876316>, provisioner.c,  227, Local provisioning link closed
<t:     876925>, provisioner.c,  128, Binding appkey to the Health model
<t:    1144061>, main.c,  405, Node 0x0100 alive with 0 active fault(s), RSSI: -28
<t:    1471988>, main.c,  405, Node 0x0100 alive with 0 active fault(s), RSSI: -30
<t:    1799588>, main.c,  405, Node 0x0100 alive with 0 active fault(s), RSSI: -28
<t:    1859982>, main.c,  490, Configuration of device 1 failed

However, when the first server is successfully networked, the power is turned off and the power is on the second server. In this way, the network can be successfully established. What is the reason for this?

[Jui-Chou (Rick) Chung]

Hello caca1989,

Since you are running NUS and mesh concurrently, I would like to suggest you extend the advertising interval and also the connection interval to be more than 100 ms to avoid the collision of mesh packets. 

And in the current light switch example, once if the configuration procedure failed, it would be a little hard to recover. 

Would you please erase and re-program both of light swtich client and server, and check if the error still happen?

[caca1989]

Hi Rick Chung,

Thank you for your reply, I've tried the method you mentioned, but this is not the reason!

   

[Jui-Chou (Rick) Chung]

Hello caca1989,

Does it mean after you erase both of the servers and client, and run the demo again, you still can only finish configuration for one server, and always failed on configuring the second one?

[caca1989]

Hello RIck Chung，

but. After I successfully configured the first server, I shut it down and then powered on the second server. In this case, the second server can be configured successfully! Feel the configuration is disturbed by the first server!

[Jui-Chou (Rick) Chung]

Hello caca1989,

Are there lots of device advertising on your site? I would assume there may be too many devices advertising at the same time which interference the configuration procedure.

I would like to suggest you modify the SCANNER_BUFFER_SIZE in nrf_mesh_config_bearer.h from 512 to 2048, recompile and program to see if this can do help : )

[caca1989]

Rick Chung,

thank you very much！

the SCANNER_BUFFER_SIZE modified to 1024, 2server can be configured successfully, but I need

more servers, such as 50 servers, then the SCANNER_BUFFER_SIZE takes up too much space, there

are other more effective way? I'm afraid of 50 servers this value is too big

[Jui-Chou (Rick) Chung]

Hello caca1989, 

Great to hear that it works :)

No, we don't have to enlarge this parameter because of we are going to add more servers.

Since this parameter is for allocating the scanner buffer for receiving ADV packets. If the size of the scanner buffer is not large enough and also there are lots of ADV in the environments, scanner buffer will be filled to full easily.