Request test firmware for large scale testing scenario

[Nagajans]

I was reviewing the Large scale Bluetooth mesh testing - Blogs - Nordic Blog - Nordic DevZone and noticed the statement: "Initialize the network by flashing the test firmware on the nodes." in the test procedure. I’m interested in performing similar latency and reliability tests. Could you please let me know where I can find the test firmware used in your evaluation?

[Elfving]

Hi Nagarajan,

I think it would be best if we could guide you on how to do this rather than to share this internal project. Though please contact your local RSM (regional sales manager or other nordic representative) about this, as I think that would be a good way to start addressing this. 

Regards and happy holidays,

Elfving

[Nagajans]

Thanks for the input. I performed an nRF52840 board-to-board test using the nRF Light and Light Switch examples and monitored the timestamps in the nRF Mesh Sniffer. Based on my observations, is it possible to further reduce the latency through BLE Mesh configuration?

distance (metre)	round trip latency for acknowledged message (ms)
0	48
0.5	66
3	105
6	100
10	214

[Nagajans]

I’ll wait for your response—this clarification is very important for our Bluetooth Mesh decision-making.

[Elfving]

Hi again, happy new year, and thanks for the patience during this holiday period

Nagajans said:

I am using the NCS v3.1.0 light_switch and light sample applications for testing. In my setup, I observe approximately 100 ms response delay between the client and server at a 3-meter distance, with no relay nodes enabled.

I just tried a quick test of this myself using a logic analyzer, and got 13ms. I am not sure exactly what is happening in your setup with the Mesh App, though I had a talk with the team developing it and they claim the timing there should be accurate.

I want to note that what you are seeing are the times from the selected mesh message. The user needs to swipe the row to the right to "select" that message. All other messages will be timed to that one. But I agree that it does look like a >100ms there. I haven't tried this test using that app yet.

Would it be possible for you to try it using a logic analyzer?

Regards,

Elfving

[Nagajans]

I would also like to wish you a Happy New Year.

I performed OTA upgrades using both NCS version 2.9.0 and NCS version 3.1.0, and I am observing a significant difference in upgrade time. For a firmware image of approximately 350 KB, the OTA upgrade took about 45 minutes with NCS 2.9.0, whereas it took nearly 2 hours with NCS 3.1.0.

I would like to understand the primary reasons for this substantial increase in OTA upgrade time between the two versions.

[Elfving]

Hi,

That is a bit surprising. I assume these are both Mesh DFUs you are talking about? What does this test setup look like? Are you just updating one node in both of them, and what does the network look like?

Regards,

Elfving

[Nagajans]

Yes, this is specifically related to BLE Mesh DFU. The setup uses two nRF52840 devices placed close to each other, so RF range or interference should not be a limiting factor.

[Elfving]

I see. And everything regarding provisioning and starting the DFU process is the same in the two NCS versions? 

[Nagajans]

Yes, all configurations are default, and I did not make any changes to the code.

[Elfving]

I've now confirmed with the Mesh team that the results should be comparable, given that similar configurations are used. So as that is not the case here, I assume that the default values for some important config is changed between these NCS versions. Like you remember from the large scale testing blogpost, configs like 'Network Transmit Interval' can play a role.

Could you get me the configs that were used for these two projects, either the prj.conf for the explicit changes, or preferably the /[app]/build/[app]/zephyr/.config for the resulting set of all configs that are enabled? Or if this happens to be the default light_switch and light sample applications again, I can always find these and compare them myself 

Nagajans said:

The setup uses two nRF52840 devices placed close to each other, so RF range or interference should not be a limiting factor.

Just to make sure, these are DKs, right?

Regards,

Elfving

[Nagajans]

Yes, I understand that. I would like to know which configuration parameters play a major role in the observed DFU timing difference. In both NCS versions, I used only the light and light_switch sample applications, with no custom modifications.

It would be very helpful if you could also share a recommended strategy or guidelines for choosing optimal configuration parameters based on network size—for example, what configurations are best suited for 10-node, 50-node, and 100-node BLE Mesh networks.

[Elfving]

Understood. I'll look into what the difference could be there. 

According to a test here, a unicast transfer of 300KB firmware could take about 45-50 mins, group cast transfer of the same firmware takes about 130mins. I know you said that the tests with the two NCS versions where done in the same way, but since the timing matched so well I just wanted to ask: you didn't happen to do the one test on NCS 3.1 using a group address?

Nagajans said:

It would be very helpful if you could also share a recommended strategy or guidelines for choosing optimal configuration parameters based on network size—for example, what configurations are best suited for 10-node, 50-node, and 100-node BLE Mesh networks.

I could give some recommendations based on this, but I would say that my recommendations wouldn't be mainly based on the number of nodes per se, but on the topology. If there are a 100 nodes just sitting on your desk, then relaying would almost not even be necessary. Though if you are placing a hundred nodes on telephone poles along a highway, where one can just reach the next one, that is a different story. For that situation I would for instance argue that a large TTL is important.

Regards,

Elfving