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
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
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
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().
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().
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
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?
Hi !
When my nodes are in an one hop range, they turned on at the same time no matter the distance (between 0 m to 65 m). When i need to used a relay node, i can see like a little "lag" like 100 or 200 ms. i made some test and for now, it's less longer to send a pre-cut message than sending the 64 bytes cause of this little latency between two sending.
I know that throughput is depending on Bluettoth SIG Mesh which is based on Bluetooth 4, and the only way to make Mesh more suitable for industry is waiting and upgrade of Mesh. Do you have some info about when a new release of BLE Mesh will be posted ? Just to get a date to put a reminder on and make new test of BLE Mesh.
Sincerely
PG
Hello PG,
Unfortunately, I don't have any details regarding roadmap plans, and at least not for roadmap plans from Bluetooth. And I am not sure they intend to increase the throughput, or the packet size in Bluetooth Mesh packets. I have not heard anything about that, but then again, I may not be updated.
Is there some way for me to reproduce this? Perhaps I can do that, and check with our Mesh team whether it is expected or not.
I wish I could tell you exactly what to do to shorten the time, but I am not a Mesh expert. We are very short staffed this month due to summer holidays, and all the mesh experts are out of office. I am sorry for the inconvenience.
That being said, if the receivers respond quite quick, then I am not sure whether you would need ACKs in this case. There is not really a good way of Acking messages going to multiple nodes in a Mesh. Which node should ACK? What node should the transmitter wait for? All of them? What will happen then if there are a thousand nodes? That would definitely flood the network.
My suspicion is that the nodes don't ACK because the message contains several messages, and the nodes will not ACK until all the messages are sent. When the transmitter has some delay between each packet, then you will see this delay. When you only send a short message, the slaves can ACK immediately after receiving it. However, I still think 4 seconds sounds like a lot. 64 bytes should be around 6 packets, but I don't think there should be a delay of 0.5 seconds between each packet from the transmitter.
Hi!
I needed to get acknowledge to know the time of a round-trip and to get RSSI for my tests. I will disable them later. I was just wondering is this kind of latency is normal but i think that it's quite impossible for the Client to be sure that every device in the group received the message. So this latency is there for "security".
I test with a payload of 5 (1 packet), 15 (2 packets), 23 (3 packets) and the latency is more and more important so it confirm the previous theory.
To reproduce this, you only needed to increase the payload cause i didn't modify a lots of things in model files.
Sincerely
