Mesh segmented message long roundtrip time

[Simsim]

Hi Nordic Team

I encounterd the following behaviour:

Segmented message took 8s for acknoledge state.

I did the following:

Setup: 2 Devices NRF52840DK, provisioned and configured one groupadress to write/listen on.

TTL = 4, acknoledged message. No Gatt connection active, but advertising.

Code: Based on NRF Mesh SDK 5.0 (i know, no more developement on this)

->Send message 14byte payload so segmented message is nescessary.

<-then wait for Ack. this takes 8s from send to ack.

When sending unacknoledged the busy flag stays the same time on busy (status = 8).

This can be confirmed on the receiving side as well.

I  also monitored the traffic with the mesh sniffer APP, there the publish message needs 2 seconds.

Question:

what does consume this much time? where can i optimise the round trip time?

[tesc]

Hi,

Round trip time should be much less than 8 seconds, and the 2 seconds that you experience with the app sounds much more reasonable.

There is a limitation (imposed by the Bluetooth Mesh stack) where a mesh device should not originate more than 100 packets within a sliding window of 10 seconds. This will in some instances reduce throughput and lead to long delays (typically delays a little shy of 10 seconds.

Since the device is advertising, I would expect the radio to use the SoftDevice for BLE from time to time, which with the nRF5 SDK for Mesh solution means the device will have gaps in Bluetooth Mesh performance. (I assume this advertising is normal BLE which is happening concurrently with running the Bluetooth Mesh stack, can you confirm this?) In particular, when there is a collision between the normal BLE advertiser advertising, and the Bluetooth Mesh stack scanning, this may lead to the Bluetooth Mesh stack not receiving packets. Especially if retransmit intervals are a multiple of the BLE advertising interval, you may risk multiple collisions in a row, lwading to very long response times.

In order to figure out what might be happening in this particular case, I am afraid I would need some more information. If you have any sniffer traces, or steps to reproduce the behavior, then I may be able to look into that. Also, confirmation (or correction) regarding what BLE advertising is ongoing (with full information about intervals etc.) and whether the BLE stack is also concurrently scanning, would be of great value, for assessing what might be the issue at hand.

Regards,
Terje

[Simsim]

Hey Terje

Thanks for pointing in the right direction. I had Gatt Advertising on 200ms what leads to the long roundtrip time, while going back to 2000ms the roundtrip time was going to 3.4s what is near to the point i was expecting.

Thanks for the profound answer

Regards

Sim