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 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.

However, documentation and studies indicate that in a 100-node Bluetooth Mesh network with relay nodes, the maximum end-to-end delay can be around 65 ms.

Could you please explain how such low latency is achieved, and what configuration or code changes would be required in my environment (using the sample code) to reach similar latency?

[Elfving]

Is it an acknowledged message? Is it a larger one? Is it just the default that comes with the samples?

[Nagajans]

its acknowledged message and it is just default unsegmented message that comes with the samples.

[Elfving]

How are you measuring the latency? Are you seeing BT_MESH_ACCESS_DELAYABLE_MSG being turned off making a difference here?

[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