Blutooth mesh publish latency

[nicolas b]

Hello all,

We are currently evaluating the bluetooth mesh implementation of ST integrated in our tools and in nucleo board.

But right now, I'm facing a problem : the latency to send messages with the

MOBLE_RESULT BluenrgMesh_SetRemotePublication(..)

API is big.

Even sending one packet of 20 bytes every second seems too fast for the chip, as I quickly receive errors from the API.

What could be the problem? Maybe the encryption of the packet takes too long?

Do you have an idea of the throughput reachable with bluetooth mesh?

[DEdwi.1]

The fastest advertising interval that is available for Bluetooth mesh is 20ms. Typically I would retransmit every packet 3 times (this for a 50-100 node network), that means at least 60 ms per packet, so its reasonable to expect about 10 packets per second at best and can be worse when there are multiple hops. You are correct that software crypto for mesh will take time but that is less than 1ms so in the overall scheme of things it does not count.

What are the errors that you are receiving ? I know this is an old post but listing the errors can help you get help.

Thanks

[nicolas b]

Thanks for the answer, even if it is late.

The error was very generic, I do not remember exactly.

But we had confirmation from ST that, yes, it is expected to have a low throughput with mesh. At that time, I did not know about hops.

[DEdwi.1]

That is good to know. I would typically setup at test bed to verify the throughput and performance for the mesh to get better control on this and understand the performance envelope. Hopefully ST will also release this data on a per-release basis (on demand by customers is also ok). @EMECH​ 

20 bytes per 1000 ms should still be manageable by the mesh stack but there could be internal constraints in the stack.

Also noticed that 20 bytes may trigger the segmentation, so it will send it as multiple packets and then your performance will be ugly (it will be really bad).

Try to keep the packet at 11 bytes or below to keep the segmentation from kicking in, then I would expect the best performance for the bandwidth

Edited for clarity: 16 bytes is the lower transport PDU, we lose 1 byte for the app key index so 15 bytes for the upper transport PDU (used by the application)., of the 15 bytes we lose 4 bytes for a MIC so only 11 bytes available for application.

Application sends the data as <opcode><data>, if opcodes can be 1 byte, 2 byte or vendor specific 3 byte, so the worst case data size for a single packet is 8 bytes for application data and 3 for the opcode.

Short answer, its very likely your packets are being segmented resulting in extremely bad performance, send unsegmented packets to maximize the performance.