nrf mesh SDK 2.1.1

[vnagy1]

Hellou, i have questiuons about NRF MESH SDK 2.1.1. 

We have in production street light based on light_switch_server_nrf52832_xxAA_s132_6_0_0 from NRF SDK 2.1.1.

When we tested communication, we have problem by changeing IV index by big communication traffic , because  in function static inline bool iv_timeout_limit_passed(uint32_t timeout), was timeout set to 96 hours. We needs changing IV index in test more often because we updated FW remotely by mesh. So we change this timeout to 4 minutes. Its work well on small test mesh network(3 devices). IV index was changing and communication work properly.

But we have this software aplicated on bigger mesh network (more than 80 devices) . In this network after provisioning device communicated first 2-3 weeks without any problem, but after its happens that device randomly stop communicate. Devices dont response on commands. On devices in this network are permantly sends commands - here is big communication traffic.

Communication is based on command-response principle. 

When the device stop communicate - server doesn;t communicate with client till to power of reset. When the power of reset is aplicated, device start again communicate with client. 

Its is possible that is because we change the time in static inline bool iv_timeout_limit_passed(uint32_t timeout) from 96 hours to 4 minutes.?

Have any same problem with that device stop communicate?  Any advice how we can fix this bug? Changing SDK version for higher version is not possible in this moment - devices are installed. 

[tesc]

Hi,

The timeout of 96 hours is from the Bluetooth mesh specification. The reason is for giving all nodes a chance to completely roll over to the new IV index before the old one gets deprecated. (There are always two IV indexes that are "valid", letting nodes still using the "old" index participate in the network until they get a message they should go over to the "new" one.)

If you set that timer lower than 96 hours, then your solution will no longer be Bluetooth mesh compliant. You risk that nodes on your network may stop working, in particular if there are other nodes on the network (that are incapable of shorter IV update frequencies.)

Since the devices start working again after a reset, it sounds strange if it should be rapid IV index rollover causing this. Some more information would be needed to figure out what might be the issue.

• Do your devices do any logging, that can be examined?
• Is it isolated to single devices, or does it happen with multiple devices at the same time?
• Does it happen when the device exhausts sequence numbers? When triggering IV Update?

Regards,
Terje