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]

The observed latency seems quite high. When a broadcast message is sent from device 0x003E to the group address 0xC000, all three devices subscribed to this group do receive and acknowledge the message, but the acknowledgments arrive at significantly different times. One device responds after approximately 115 ms, another after 159 ms, and the third after 341 ms, even though all boards are placed very close to each other.

Could you please explain why there is such a large variation in response timing among devices under identical physical conditions?

[Elfving]

I see. With the holidays coming up though, I unfortunately have to get back to you on this after New Years. I hope that is fine. If not, please contact your local RSM about escalation.

Regards and happy holidays,

Elfving

[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