How to characterize the delay between two reliable messages of 64 bytes ?

[PaulGui]

Hi community !
All is in the title.

The latency between sending the message and receiving the callback is not stable ( between 1600 & 4300 ms)
I know that this delay is here to be sure that every devices in a group get the entire message but is there a way to calculate it ?

Sincerely

PG

[Susheel Nuguru]

I am not an expert in Mesh but my colleague responded as below.

"4300ms sounds like a lot. Is it really a group message, and not to one specific node? Alternatively that all the nodes listening on that channel is many hops away.

I don't remember the exact number, but I believe the delay added for each hop is something around 50ms + some 0-10ms random delay"

[PaulGui]

Thanks for replying !

I calculate the latency by setting a timer when i call the sending function on main.c and stop it when i get the callback. So it's like a round-trip latency. And in addition i got a BLE connected connection in parallel of Mesh one. Maybe that explaination make this latency "normal"

My message is a group one and my default TTL is set at 4, and i never touch it in the app. I got this latency for a 1 hop distance.

Do you have a latency average for a payload around 64 bytes ?

Sincerely

PG

[Edvin]

Hello PG,

Can you please try the same test with a smaller payload? E.g. below 11 bytes (6 or 7 bytes). Just for testing purposes. 

Can you please describe how you send the message? What function call do you use, and what sort of ACK do you get to measure the round trip latency?

BR,

Edvin

[PaulGui]

HI !
When i'm sending with 9 payloads i got like 50 ms for a round-trip so 25 ms to reach the server.

I'm using a custom model based on RSSI one. When i send , for example 64 bytes of data, i let the soft make it reliable and i get this value of latency ( between 1600 & 4300 ms).
I'm using a ACK message because i testing it and i saw on another topics that latency will not change if it's a ACK or UNACK One . I stop the timer at app_generic_onoff_client_status_cb().

[Edvin]

Have you tried to toggle an LED or something when the entire (64B) message is received on each node? Do you see a popcorn effect, or are they turned on at the same time? And would you say it takes a couple of 100ms or 4 seconds?

The reason it takes longer is that the payload of each physical message in Mesh is quite low. Around 11 bytes I believe, because of all the headers in the Mesh network. The Mesh packets are, as you may already know, modified BLE advertising packets. So they are restricted to 31 bytes, and the headers take up around 20 bytes. I am not sure exactly how the internal latency between packets works, but in Mesh there is a bit of delay, to avoid too many collisions. Remember that every node will repeat every scanned message several times, and the originator of the message will send out the next packet after the first packet is done circulating in the network.

However, I still think 4 seconds sounded like a lot, but perhaps it is expected with such "large" payload. 

BR,

Edvin

[Edvin]

If you try to send the message as a unicast message (a message to one specific device only). does it affect the round trip time? And how about if you turn off all nodes but these two nodes?