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
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
Hi !
I think i got the point of my problem. when i send an unsegmented messgae, the TID value is actualize (+1 every time). But, with the same code, when i send a segmented one, the TID value is always 27.
But the problem is i don't know where this value come from and how could this be corrected.
Do you know how to correct this ?
Best regards
Hi !
I think i got the point of my problem. when i send an unsegmented messgae, the TID value is actualize (+1 every time). But, with the same code, when i send a segmented one, the TID value is always 27.
But the problem is i don't know where this value come from and how could this be corrected.
Do you know how to correct this ?
Best regards
again, I am no mesh expert. So where do you get this TID, and do you know what it is short for? Transaction ID? Where is it set to 27?
