Other Parts Discussed in Thread: WL1835MOD
Team,
A customer of mine would like to achieve low Bluetooth latency in the ~6 ms range. But when testing with WL1837MOD, there is quite a big variation:
As we seek for a Bluetooth communication with a very low latency, we are using the l2ping command to measure the delay of a message between two WL1837MOD. Thereby we observe, that the l2cap echo requests are not sent immediately, but delayed for a differing amount of time.
This is an export from Wireshark of an hcidump of l2ping:
Time [s] |
Source |
Destination |
Protocol |
Length |
Direction |
Info |
0.689 |
localhost () |
TexasIns_2c:90:63 (BlueZ 5.50) |
L2CAP |
57 |
Sent |
Sent Echo Request |
0.695 |
controller |
host |
HCI_EVT |
8 |
Received |
Rcvd Number of Completed Packets |
0.697 |
TexasIns_2c:90:63 (BlueZ 5.50) |
localhost () |
L2CAP |
57 |
Received |
Rcvd Echo Response |
1.697 |
localhost () |
TexasIns_2c:90:63 (BlueZ 5.50) |
L2CAP |
57 |
Sent |
Sent Echo Request |
1.714 |
controller |
host |
HCI_EVT |
8 |
Received |
Rcvd Number of Completed Packets |
1.717 |
TexasIns_2c:90:63 (BlueZ 5.50) |
localhost () |
L2CAP |
57 |
Received |
Rcvd Echo Response |
2.718 |
localhost () |
TexasIns_2c:90:63 (BlueZ 5.50) |
L2CAP |
57 |
Sent |
Sent Echo Request |
2.725 |
controller |
host |
HCI_EVT |
8 |
Received |
Rcvd Number of Completed Packets |
2.727 |
TexasIns_2c:90:63 (BlueZ 5.50) |
localhost () |
L2CAP |
57 |
Received |
Rcvd Echo Response |
3.727 |
localhost () |
TexasIns_2c:90:63 (BlueZ 5.50) |
L2CAP |
57 |
Sent |
Sent Echo Request |
3.735 |
controller |
host |
HCI_EVT |
8 |
Received |
Rcvd Number of Completed Packets |
3.737 |
TexasIns_2c:90:63 (BlueZ 5.50) |
localhost () |
L2CAP |
57 |
Received |
Rcvd Echo Response |
4.737 |
localhost () |
TexasIns_2c:90:63 (BlueZ 5.50) |
L2CAP |
57 |
Sent |
Sent Echo Request |
4.764 |
controller |
host |
HCI_EVT |
8 |
Received |
Rcvd Number of Completed Packets |
4.767 |
TexasIns_2c:90:63 (BlueZ 5.50) |
localhost () |
L2CAP |
57 |
Received |
Rcvd Echo Response |
5.767 |
localhost () |
TexasIns_2c:90:63 (BlueZ 5.50) |
L2CAP |
57 |
Sent |
Sent Echo Request |
5.794 |
controller |
host |
HCI_EVT |
8 |
Received |
Rcvd Number of Completed Packets |
5.797 |
TexasIns_2c:90:63 (BlueZ 5.50) |
localhost () |
L2CAP |
57 |
Received |
Rcvd Echo Response |
As far as we understand the packet is sent just before the host receives the “Rcvd Number of Completed Packets” event. This is 6 ms after the first echo request is sent, 17 ms after the second one, 7 ms after the third one, 8 ms after the 4th one, 27 ms after the 5th one and 27 ms after the 6th one.
These are typical times. In longer measurement we observed a minimum of 4.5 ms, an average of 25 ms and a maximum of 34.8 ms.
These values apply if the WLAN interface is switched off.
Can you tell us what causes the delay before the l2cap packets are sent? Is there any way to configure the WL1837mod Bluetooth device in order to send the packets with a smaller delay?
We want to achieve a Bluetooth latency which is less than 10 ms in 99.99% of all cases.
Up to now we tried to configure deep sleep and retransmission number but these had no effect. I also tried to configure flow control but had no success: it seems that guaranteed service type is not supported.
Host CPU: NXP i.MX6
Linux kernel: 5.4.17
WL18x firmware: 8.9.0.0.79
Bluetooth stack: BlueZ 5.50
Thanks,
Robert