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
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
As I mentioned, we are really short staffed due to summer holidays. I think it will be quicker for all involved parts if you zip the project.
PaulGui said:To reproduce this, you only needed to increase the payload cause i didn't modify a lots of things in model files.
I believe that it doesn't require a lot of changes, but at this point I am not sure how to do this, so I would have to spend a few hours to read up and experiment. I can't do that, and I leave for vacation in 3 hours. I'll assign this case back in the queue, but I am sure the engineer who will be assigned this ticket will appreciate if he/she has a project that compiles in an unmodified SDK, and can reproduce what you are seeing.
Best regards,
Edvin
