Hello,
I am developing a Bluetooth Mesh application using Nordic hardware and am running into reliability issues when transmitting bursts of vendor messages.
System overview
-
Network size: ~3 nodes
-
Each node receives a “schedule” consisting of multiple events
-
Event size: 6 bytes
-
Typical schedule: 10–20 events total, split unevenly per node
-
Message type: Vendor model, unacknowledged, unsegmented
-
Sender: Android application acting as a GATT Proxy
-
Addresses: Unicast (each node receives only its own events).
The Android app provisions the nodes and sends schedules by grouping all events per destination node. It sends all events destined for the proxy node first, then sends schedules to the remaining nodes sequentially. I currently enforce a 75 ms delay between messages; sending faster than this results in dropped messages.
Observed behavior
-
The proxy node almost always receives all messages successfully, even with no delay.
-
Non-proxy nodes commonly miss 1–2 events per schedule when sending with delays shorter than 75ms .
-
When messages are dropped, the following log appears on the embedded side: <wrn> bt_mesh_transport: Replay: src 0x0001 dst 0x0006 seq 0x0002c9
My questions are as follows (sorry I know there are a lot):
Is this replay protection being triggered due to out of order delivery caused by relay congestion when sending bursts of messages? Are there recommended throughput limits or pacing strategies for unacknowledged vendor messages in BLE Mesh? Would using segmented or acknowledged messages for schedule delivery be more appropriate? Are there recommended relay/network transmit settings for this type of burst data transfer? Is it expected that the proxy node behaves more reliably since it receives messages directly over GATT?
Any help would be greatly appreciated!
