I am using 2 nRF528400DK boards. Each board has a unique BLE Mesh sample loaded. The samples were made by modifying the default mesh sample provided by zephyr. One sample acts as a BLE Mesh publisher and the other sample acts as a BLE Mesh subscriber. They each use a custom model, and after being provisioned into the same network via the NRF Mesh app, the publisher sends period basic BLE Mesh messages to the subscriber and the subscriber, after receiving a message, sends the same BLE Mesh message back to the publisher. All messages are unicast, and the samples work as expected without any issues.
For testing, I included a timer on the publisher device. The time is started before publishing a BLE Mesh message and a round-trip latency time is calculated after receiving a response back from the subscriber device. The goal of my testing is to evaluate the Nordic BLE Mesh solution against the publicly posted Nordic BLE Mesh testing blog: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/large-scale-bluetooth-mesh-testing#mcetoc_1gsjs1houb
The test results from this blog claim a round-trip latency of around 30ms. I would expect to see similar numbers. However, the timer measurements I see are 60ms - 70ms which is over twice as long. Am I misunderstanding the blog, or is my implementation of round-trip latency measuring off in some way? Were some enhancements made to the testing done by Nordic for this blog that improved latency measurements?
The relevant code for my samples can be found here:
Publisher:
Subscriber: