WL1837MOD: Bluetooth latency higher than expected

Robert Finger

Part Number: WL1837MOD
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 4^th one, 27 ms after the 5^th one and 27 ms after the 6^th 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

over 1 year ago

0 RogelioD over 1 year ago

TI__Genius 9465 points

Hi Robert,

I am looking into this, I should have a proper answer for you tomorrow.

Kind Regards,

Rogelio

0 RogelioD over 1 year ago in reply to RogelioD

TI__Genius 9465 points

Hello Robert,

You can change to connection to guaranteed, I recommend you checking out HCI_VS_Configure_DDIP (0xFD55) in the VS HCI Commands.

Its hard to say what exactly is causing this delay. I do know the L2CAP checks the validity of the echo request, im looking more into it to see if theres a way to mitigate the delay from when the request is recieved and the response is sent out. I will keep you updtated.

BR,

Rogelio

0 Robert Finger over 1 year ago in reply to RogelioD

TI__Genius 16182 points

Hi Rogelio,

Thanks for your suggestions! Unfortunatly it didn't help:

I had no success, to change the connection to guaranteed:

I tried the HCI_VS_Configure_DDIP command:

# hcitool cmd 3F 155 60 60 02 07 02 01 01 FF FF
< HCI Command: ogf 0x3f, ocf 0x0155, plen 9
60 60 02 07 02 01 01 FF FF
> HCI Event: 0x0e plen 4
01 55 FD 00

As far as I understood the command did succeed, however just configured the percentage for ACL during page, inquiry and continuous Bluetooth low energy scans for both best-effort and guaranteed to 96% and the poll period to 2. It does not change the service type of a connection. There was no effect on the measured latency:

2022-10-13 16:32:28.973230 < ACL data: handle 1 flags 0x00 dlen 52
    L2CAP(s): Echo req: dlen 44
2022-10-13 16:32:28.989491 > HCI Event: Number of Completed Packets (0x13) plen 5
    handle 1 packets 1
2022-10-13 16:32:28.991926 > ACL data: handle 1 flags 0x02 dlen 52
    L2CAP(s): Echo rsp: dlen 44

The echo response took 16 milliseconds to be sent and the response was received within 2 milliseconds.

Furthermore, I tried the QoS setup command, in order the setup the connection used for l2ping to be guaranteed:

2022-10-13 16:28:43.782223 < HCI Command: QoS Setup (0x02|0x0007) plen 20
    handle 1 flags 0x00
    Service type: 2
    Token rate: -1
    Peak bandwith: -1
    Latency: 6
    Delay variation: 0
2022-10-13 16:28:43.783997 > HCI Event: Command Status (0x0f) plen 4
    QoS Setup (0x02|0x0007) status 0x00 ncmd 1
2022-10-13 16:28:43.784159 > HCI Event: QoS Setup Complete (0x0d) plen 21
    status 0x27 handle 1 flags 0
    Error: Requested QoS Not Supported

So the QoS Setup Complete Event says, that the service type is not supported. I tried different parameters however none were accepted.

Can you help, what parameters I need to setup in order to get a guaranteed connection?

Thanks,
Robert

0 Robert Finger over 1 year ago in reply to Robert Finger

TI__Genius 16182 points

Hi Rogleio,

I got further feedback/questions:

Did you mean the HCI_VS_Configure_DDIP (0xFD55) command, which is described in chapter 4.1.1.9 in this document?

https://www.ti.com/lit/ug/swru442b/swru442b.pdf

The commands description states:

This command configures the bandwidth allocation between ACL (best effort or guaranteed connection)
and Inquiry/Page/Bluetooth low energy scans. …

The command does not have a parameter for a connection handle, so I assume it does configure bandwidth allocation in general. As it has two parameters for ACL percentage for best effort ACL and guaranteed ACL during page/inquiry/low energy scans, I understand that the command does configure the percentage of both best effort ACL and guaranteed ACL vs page/inquiry/low energy scans.

I cannot find anything about switching the connection type between best effort and guaranteed.

In contrast the HCI_Flow_Specification and the HCI_QoS_Setup both support to specify a service type, being best effort or guaranteed, for a connection (however I get a QoS not supported replay whenever I try to set the service type to guaranteed, as written before).

Could you confirm that I understood the meaning of these commands correctly?

I also applied the HCI_Write_Scan_Enable command with parameter 0 to make sure that there is no page/inquire scan activity (no effect on the latency).
Same about HCI_LE_Set_Scan_Enable – there was no effect neither.

In order to check, that no other Bluetooth devices do have any influence, I performed the measurement inside an EMC chamber (= faraday cage) with no other wireless devices being active:

I got the exact same result as before, that the L2CAP echo takes between 5 and 30 ms with an average of over 20 milliseconds.

A new observation is, that the delay until the Number of Completed Packets Event does change, when I perform a role change.

The Bluetooth devices having the master role, has a delay of 3 to 4 milliseconds from a L2CAP packet being sent until the Number of Completed Packets event is received. But the slave device has a delay varying between 5 and 27 milliseconds.

And there is no other connection beside the one used for L2CAP echo measurements.

I know that a Bluetooth slave is not able to send data at any time. But a delay of about 20 milliseconds with only 1 connection and no scan activity seems to be far to high.

I did understand, that BlueZ stack is not supported. However, I do observe HCI commands, events and data in order to check if there is anything contradicting a low latency.

Using the l2ping command of BlueZ I can see the following HCI commands being issued:

HCI_Create_Connection 0x0405 which is responded with a Command Status Event, a Role Change Event (the remote device being slave) and a Connect Complete event
HCI_Read_Remote_Supported_Features 0x041B responded by a Command Status, a Max Slots Change (5) and a Read Remote Supported Feature Event (ff fe 2d fed b ff 7b 87 = almost everything supported)
HCI_Read_Remote_Extended_Features 0x041C responded with a Command Status Event and a Remote Extended Features Complete Event
HCI_Remote_Name_Request 0x0419 responded with a Command Status Event and the Remote Name Request Complete Event
ACL packet with L2CAP command Information Request (Extended Features) responded with a Number of Completed Packets Event and an Information Response packet
ACL packet with L2CAP command Information Response (Extended Features) due to a remote Information Request (+ a Number of Completed Packets Event)
ACL packet with L2CAP command Information Request (Fixed Channels) responded with a Number of Completed Packets Event and an Information Response packet
ACL packet with L2CAP command Information Response (Fixed Channels) due to a remote Information Request (+ a Number of Completed Packets Event)
ACL packet with L2CAP echo request responded with a Number of Completed Packets Event and a L2CAP echo response

I attached the described communication as record in btsnoop file format.

Do you recognize some command/setup which is missing or wrong, in order to get a low latency connection?

Could you provide a HCI command sequence (or btsnoop record or something similar) that shows a connection setup and multiple L2CAP echoes with a small latency?

Thank you for your analysis.

Attachments: l2ping1_echo.btsnoop

l2ping1.log

mon # l2ping -i hci1 74:E1:82:2C:90:63
Ping: 74:E1:82:2C:90:63 from C8:DF:84:4E:4F:D5 (data size 44) ...
44 bytes from 74:E1:82:2C:90:63 id 0 time 7.62ms
44 bytes from 74:E1:82:2C:90:63 id 1 time 21.09ms
44 bytes from 74:E1:82:2C:90:63 id 2 time 10.07ms
44 bytes from 74:E1:82:2C:90:63 id 3 time 15.49ms
44 bytes from 74:E1:82:2C:90:63 id 4 time 29.62ms
44 bytes from 74:E1:82:2C:90:63 id 5 time 29.56ms
44 bytes from 74:E1:82:2C:90:63 id 6 time 9.69ms
44 bytes from 74:E1:82:2C:90:63 id 7 time 8.40ms
44 bytes from 74:E1:82:2C:90:63 id 8 time 19.70ms
44 bytes from 74:E1:82:2C:90:63 id 9 time 29.56ms
44 bytes from 74:E1:82:2C:90:63 id 10 time 25.91ms
44 bytes from 74:E1:82:2C:90:63 id 11 time 20.78ms
44 bytes from 74:E1:82:2C:90:63 id 12 time 8.59ms
44 bytes from 74:E1:82:2C:90:63 id 13 time 24.38ms
44 bytes from 74:E1:82:2C:90:63 id 14 time 19.68ms
44 bytes from 74:E1:82:2C:90:63 id 15 time 19.58ms
44 bytes from 74:E1:82:2C:90:63 id 16 time 22.12ms
44 bytes from 74:E1:82:2C:90:63 id 17 time 7.13ms
44 bytes from 74:E1:82:2C:90:63 id 18 time 30.88ms
44 bytes from 74:E1:82:2C:90:63 id 19 time 28.48ms
44 bytes from 74:E1:82:2C:90:63 id 20 time 29.76ms
44 bytes from 74:E1:82:2C:90:63 id 21 time 22.10ms
44 bytes from 74:E1:82:2C:90:63 id 22 time 8.34ms
44 bytes from 74:E1:82:2C:90:63 id 23 time 29.62ms
44 bytes from 74:E1:82:2C:90:63 id 24 time 28.43ms
44 bytes from 74:E1:82:2C:90:63 id 25 time 27.26ms
44 bytes from 74:E1:82:2C:90:63 id 26 time 19.63ms
44 bytes from 74:E1:82:2C:90:63 id 27 time 19.65ms
44 bytes from 74:E1:82:2C:90:63 id 28 time 22.16ms
44 bytes from 74:E1:82:2C:90:63 id 29 time 29.69ms
44 bytes from 74:E1:82:2C:90:63 id 30 time 29.64ms
44 bytes from 74:E1:82:2C:90:63 id 31 time 20.87ms
44 bytes from 74:E1:82:2C:90:63 id 32 time 8.42ms
44 bytes from 74:E1:82:2C:90:63 id 33 time 30.89ms
44 bytes from 74:E1:82:2C:90:63 id 34 time 29.66ms
44 bytes from 74:E1:82:2C:90:63 id 35 time 28.45ms
44 bytes from 74:E1:82:2C:90:63 id 36 time 20.90ms
44 bytes from 74:E1:82:2C:90:63 id 37 time 8.40ms
44 bytes from 74:E1:82:2C:90:63 id 38 time 30.82ms
44 bytes from 74:E1:82:2C:90:63 id 39 time 29.61ms
44 bytes from 74:E1:82:2C:90:63 id 40 time 28.47ms
44 bytes from 74:E1:82:2C:90:63 id 41 time 13.30ms
44 bytes from 74:E1:82:2C:90:63 id 42 time 20.78ms
44 bytes from 74:E1:82:2C:90:63 id 43 time 24.63ms
44 bytes from 74:E1:82:2C:90:63 id 44 time 29.65ms
44 bytes from 74:E1:82:2C:90:63 id 45 time 29.69ms
44 bytes from 74:E1:82:2C:90:63 id 46 time 20.89ms
44 bytes from 74:E1:82:2C:90:63 id 47 time 8.40ms
44 bytes from 74:E1:82:2C:90:63 id 48 time 7.22ms
44 bytes from 74:E1:82:2C:90:63 id 49 time 27.12ms
44 bytes from 74:E1:82:2C:90:63 id 50 time 30.88ms
44 bytes from 74:E1:82:2C:90:63 id 51 time 19.54ms
44 bytes from 74:E1:82:2C:90:63 id 52 time 8.46ms
44 bytes from 74:E1:82:2C:90:63 id 53 time 32.12ms
44 bytes from 74:E1:82:2C:90:63 id 54 time 27.17ms
44 bytes from 74:E1:82:2C:90:63 id 0 time 29.67ms
44 bytes from 74:E1:82:2C:90:63 id 1 time 22.13ms
44 bytes from 74:E1:82:2C:90:63 id 2 time 8.41ms
44 bytes from 74:E1:82:2C:90:63 id 3 time 30.94ms
44 bytes from 74:E1:82:2C:90:63 id 4 time 27.36ms
44 bytes from 74:E1:82:2C:90:63 id 5 time 29.36ms
44 bytes from 74:E1:82:2C:90:63 id 6 time 20.88ms
44 bytes from 74:E1:82:2C:90:63 id 7 time 8.40ms
44 bytes from 74:E1:82:2C:90:63 id 8 time 30.93ms
44 bytes from 74:E1:82:2C:90:63 id 9 time 28.40ms
44 bytes from 74:E1:82:2C:90:63 id 10 time 29.73ms
44 bytes from 74:E1:82:2C:90:63 id 11 time 20.86ms
44 bytes from 74:E1:82:2C:90:63 id 12 time 8.49ms
44 bytes from 74:E1:82:2C:90:63 id 13 time 29.41ms
44 bytes from 74:E1:82:2C:90:63 id 14 time 29.65ms
44 bytes from 74:E1:82:2C:90:63 id 15 time 29.65ms
44 bytes from 74:E1:82:2C:90:63 id 16 time 14.66ms
44 bytes from 74:E1:82:2C:90:63 id 17 time 19.60ms
44 bytes from 74:E1:82:2C:90:63 id 18 time 25.91ms
44 bytes from 74:E1:82:2C:90:63 id 19 time 30.81ms
44 bytes from 74:E1:82:2C:90:63 id 20 time 27.17ms
44 bytes from 74:E1:82:2C:90:63 id 21 time 20.91ms
44 bytes from 74:E1:82:2C:90:63 id 22 time 8.47ms
44 bytes from 74:E1:82:2C:90:63 id 23 time 29.85ms
44 bytes from 74:E1:82:2C:90:63 id 24 time 29.36ms
44 bytes from 74:E1:82:2C:90:63 id 25 time 29.08ms
44 bytes from 74:E1:82:2C:90:63 id 26 time 22.39ms
44 bytes from 74:E1:82:2C:90:63 id 27 time 8.42ms
44 bytes from 74:E1:82:2C:90:63 id 28 time 28.39ms
44 bytes from 74:E1:82:2C:90:63 id 29 time 29.60ms
44 bytes from 74:E1:82:2C:90:63 id 30 time 29.62ms
44 bytes from 74:E1:82:2C:90:63 id 31 time 20.92ms
44 bytes from 74:E1:82:2C:90:63 id 32 time 9.58ms
44 bytes from 74:E1:82:2C:90:63 id 33 time 28.49ms
44 bytes from 74:E1:82:2C:90:63 id 34 time 30.86ms
44 bytes from 74:E1:82:2C:90:63 id 35 time 30.83ms
44 bytes from 74:E1:82:2C:90:63 id 36 time 19.62ms
44 bytes from 74:E1:82:2C:90:63 id 37 time 7.16ms
44 bytes from 74:E1:82:2C:90:63 id 38 time 14.64ms
44 bytes from 74:E1:82:2C:90:63 id 39 time 22.12ms
44 bytes from 74:E1:82:2C:90:63 id 40 time 26.99ms
44 bytes from 74:E1:82:2C:90:63 id 41 time 21.16ms
44 bytes from 74:E1:82:2C:90:63 id 42 time 8.34ms
44 bytes from 74:E1:82:2C:90:63 id 43 time 30.90ms
44 bytes from 74:E1:82:2C:90:63 id 44 time 28.45ms
44 bytes from 74:E1:82:2C:90:63 id 45 time 29.56ms
44 bytes from 74:E1:82:2C:90:63 id 46 time 22.15ms
44 bytes from 74:E1:82:2C:90:63 id 47 time 8.36ms
44 bytes from 74:E1:82:2C:90:63 id 48 time 29.68ms
44 bytes from 74:E1:82:2C:90:63 id 49 time 28.36ms
44 bytes from 74:E1:82:2C:90:63 id 50 time 29.59ms
44 bytes from 74:E1:82:2C:90:63 id 51 time 20.83ms
44 bytes from 74:E1:82:2C:90:63 id 52 time 29.58ms
44 bytes from 74:E1:82:2C:90:63 id 53 time 8.45ms
44 bytes from 74:E1:82:2C:90:63 id 54 time 29.63ms
44 bytes from 74:E1:82:2C:90:63 id 0 time 29.67ms
44 bytes from 74:E1:82:2C:90:63 id 1 time 22.09ms
44 bytes from 74:E1:82:2C:90:63 id 2 time 9.63ms
44 bytes from 74:E1:82:2C:90:63 id 3 time 27.23ms
44 bytes from 74:E1:82:2C:90:63 id 4 time 30.89ms
44 bytes from 74:E1:82:2C:90:63 id 5 time 28.39ms
44 bytes from 74:E1:82:2C:90:63 id 6 time 20.88ms
44 bytes from 74:E1:82:2C:90:63 id 7 time 8.43ms
44 bytes from 74:E1:82:2C:90:63 id 8 time 29.69ms
44 bytes from 74:E1:82:2C:90:63 id 9 time 13.43ms
Send failed: Connection reset by peer
mon # l2ping -i hci1 74:E1:82:2C:90:63
Ping: 74:E1:82:2C:90:63 from C8:DF:84:4E:4F:D5 (data size 44) ...
44 bytes from 74:E1:82:2C:90:63 id 0 time 4.51ms
44 bytes from 74:E1:82:2C:90:63 id 1 time 22.26ms
44 bytes from 74:E1:82:2C:90:63 id 2 time 30.89ms
44 bytes from 74:E1:82:2C:90:63 id 3 time 20.89ms
44 bytes from 74:E1:82:2C:90:63 id 4 time 19.67ms
44 bytes from 74:E1:82:2C:90:63 id 5 time 33.50ms
44 bytes from 74:E1:82:2C:90:63 id 6 time 29.64ms
44 bytes from 74:E1:82:2C:90:63 id 7 time 9.65ms
44 bytes from 74:E1:82:2C:90:63 id 8 time 22.23ms
44 bytes from 74:E1:82:2C:90:63 id 9 time 24.50ms
44 bytes from 74:E1:82:2C:90:63 id 10 time 32.26ms
44 bytes from 74:E1:82:2C:90:63 id 11 time 17.05ms
44 bytes from 74:E1:82:2C:90:63 id 12 time 29.70ms
44 bytes from 74:E1:82:2C:90:63 id 13 time 34.71ms
44 bytes from 74:E1:82:2C:90:63 id 14 time 29.68ms
44 bytes from 74:E1:82:2C:90:63 id 15 time 10.86ms
44 bytes from 74:E1:82:2C:90:63 id 16 time 17.21ms
44 bytes from 74:E1:82:2C:90:63 id 17 time 7.17ms
44 bytes from 74:E1:82:2C:90:63 id 18 time 26.97ms
44 bytes from 74:E1:82:2C:90:63 id 19 time 29.88ms
44 bytes from 74:E1:82:2C:90:63 id 20 time 33.54ms
44 bytes from 74:E1:82:2C:90:63 id 21 time 17.01ms
44 bytes from 74:E1:82:2C:90:63 id 22 time 28.44ms
44 bytes from 74:E1:82:2C:90:63 id 23 time 19.68ms
44 bytes from 74:E1:82:2C:90:63 id 24 time 19.66ms
44 bytes from 74:E1:82:2C:90:63 id 25 time 34.60ms
44 bytes from 74:E1:82:2C:90:63 id 26 time 17.15ms
44 bytes from 74:E1:82:2C:90:63 id 27 time 9.77ms
44 bytes from 74:E1:82:2C:90:63 id 28 time 28.45ms
44 bytes from 74:E1:82:2C:90:63 id 29 time 28.39ms
44 bytes from 74:E1:82:2C:90:63 id 30 time 33.54ms
44 bytes from 74:E1:82:2C:90:63 id 31 time 15.78ms
44 bytes from 74:E1:82:2C:90:63 id 32 time 29.69ms
44 bytes from 74:E1:82:2C:90:63 id 33 time 22.25ms
44 bytes from 74:E1:82:2C:90:63 id 34 time 19.50ms
44 bytes from 74:E1:82:2C:90:63 id 35 time 30.90ms
44 bytes from 74:E1:82:2C:90:63 id 36 time 17.05ms
44 bytes from 74:E1:82:2C:90:63 id 37 time 29.67ms
44 bytes from 74:E1:82:2C:90:63 id 38 time 33.53ms
44 bytes from 74:E1:82:2C:90:63 id 39 time 30.91ms
44 bytes from 74:E1:82:2C:90:63 id 40 time 33.39ms
44 bytes from 74:E1:82:2C:90:63 id 41 time 25.89ms
44 bytes from 74:E1:82:2C:90:63 id 42 time 19.71ms
44 bytes from 74:E1:82:2C:90:63 id 43 time 33.47ms
44 bytes from 74:E1:82:2C:90:63 id 44 time 29.65ms
44 bytes from 74:E1:82:2C:90:63 id 45 time 33.52ms
44 bytes from 74:E1:82:2C:90:63 id 46 time 25.89ms
44 bytes from 74:E1:82:2C:90:63 id 47 time 22.06ms
44 bytes from 74:E1:82:2C:90:63 id 48 time 33.46ms
44 bytes from 74:E1:82:2C:90:63 id 49 time 28.34ms
44 bytes from 74:E1:82:2C:90:63 id 50 time 33.40ms
44 bytes from 74:E1:82:2C:90:63 id 51 time 25.87ms
44 bytes from 74:E1:82:2C:90:63 id 52 time 20.88ms
44 bytes from 74:E1:82:2C:90:63 id 53 time 9.65ms
44 bytes from 74:E1:82:2C:90:63 id 54 time 28.38ms
44 bytes from 74:E1:82:2C:90:63 id 0 time 33.38ms
44 bytes from 74:E1:82:2C:90:63 id 1 time 25.89ms
44 bytes from 74:E1:82:2C:90:63 id 2 time 19.67ms
44 bytes from 74:E1:82:2C:90:63 id 3 time 19.69ms
44 bytes from 74:E1:82:2C:90:63 id 4 time 20.89ms
44 bytes from 74:E1:82:2C:90:63 id 5 time 32.15ms
44 bytes from 74:E1:82:2C:90:63 id 6 time 25.85ms
44 bytes from 74:E1:82:2C:90:63 id 7 time 20.92ms
44 bytes from 74:E1:82:2C:90:63 id 8 time 8.33ms
44 bytes from 74:E1:82:2C:90:63 id 9 time 8.50ms
44 bytes from 74:E1:82:2C:90:63 id 10 time 29.65ms
44 bytes from 74:E1:82:2C:90:63 id 11 time 25.75ms
44 bytes from 74:E1:82:2C:90:63 id 12 time 19.67ms
44 bytes from 74:E1:82:2C:90:63 id 13 time 34.80ms
44 bytes from 74:E1:82:2C:90:63 id 14 time 13.41ms
44 bytes from 74:E1:82:2C:90:63 id 15 time 25.97ms
44 bytes from 74:E1:82:2C:90:63 id 16 time 24.62ms
44 bytes from 74:E1:82:2C:90:63 id 17 time 20.97ms
44 bytes from 74:E1:82:2C:90:63 id 18 time 33.52ms
44 bytes from 74:E1:82:2C:90:63 id 19 time 25.93ms
44 bytes from 74:E1:82:2C:90:63 id 20 time 12.34ms
44 bytes from 74:E1:82:2C:90:63 id 21 time 25.84ms
44 bytes from 74:E1:82:2C:90:63 id 22 time 21.01ms
44 bytes from 74:E1:82:2C:90:63 id 23 time 34.63ms
44 bytes from 74:E1:82:2C:90:63 id 24 time 28.32ms
44 bytes from 74:E1:82:2C:90:63 id 25 time 34.70ms
44 bytes from 74:E1:82:2C:90:63 id 26 time 25.94ms
44 bytes from 74:E1:82:2C:90:63 id 27 time 19.68ms
44 bytes from 74:E1:82:2C:90:63 id 28 time 33.50ms
44 bytes from 74:E1:82:2C:90:63 id 29 time 29.62ms
44 bytes from 74:E1:82:2C:90:63 id 30 time 33.54ms
44 bytes from 74:E1:82:2C:90:63 id 31 time 25.85ms
44 bytes from 74:E1:82:2C:90:63 id 32 time 20.94ms
44 bytes from 74:E1:82:2C:90:63 id 33 time 27.15ms
44 bytes from 74:E1:82:2C:90:63 id 34 time 19.69ms
44 bytes from 74:E1:82:2C:90:63 id 35 time 25.90ms
44 bytes from 74:E1:82:2C:90:63 id 36 time 24.79ms
44 bytes from 74:E1:82:2C:90:63 id 37 time 19.74ms
44 bytes from 74:E1:82:2C:90:63 id 38 time 19.67ms
44 bytes from 74:E1:82:2C:90:63 id 39 time 19.60ms
44 bytes from 74:E1:82:2C:90:63 id 40 time 33.49ms
44 bytes from 74:E1:82:2C:90:63 id 41 time 25.77ms
44 bytes from 74:E1:82:2C:90:63 id 42 time 20.88ms
44 bytes from 74:E1:82:2C:90:63 id 43 time 33.19ms
44 bytes from 74:E1:82:2C:90:63 id 44 time 29.88ms
44 bytes from 74:E1:82:2C:90:63 id 45 time 33.35ms
44 bytes from 74:E1:82:2C:90:63 id 46 time 25.96ms
44 bytes from 74:E1:82:2C:90:63 id 47 time 19.64ms
44 bytes from 74:E1:82:2C:90:63 id 48 time 19.68ms
44 bytes from 74:E1:82:2C:90:63 id 49 time 22.00ms
44 bytes from 74:E1:82:2C:90:63 id 50 time 32.17ms
44 bytes from 74:E1:82:2C:90:63 id 51 time 25.88ms
44 bytes from 74:E1:82:2C:90:63 id 52 time 19.62ms
44 bytes from 74:E1:82:2C:90:63 id 53 time 33.25ms
44 bytes from 74:E1:82:2C:90:63 id 54 time 29.94ms
44 bytes from 74:E1:82:2C:90:63 id 0 time 33.42ms
44 bytes from 74:E1:82:2C:90:63 id 1 time 25.88ms
44 bytes from 74:E1:82:2C:90:63 id 2 time 22.07ms
44 bytes from 74:E1:82:2C:90:63 id 3 time 33.41ms
44 bytes from 74:E1:82:2C:90:63 id 4 time 28.36ms
44 bytes from 74:E1:82:2C:90:63 id 5 time 33.39ms
44 bytes from 74:E1:82:2C:90:63 id 6 time 25.92ms
44 bytes from 74:E1:82:2C:90:63 id 7 time 20.86ms
Send failed: Connection reset by peer

l2ping1.btsnoop

0 Robert Finger over 1 year ago in reply to Robert Finger

TI__Genius 16182 points

Hi Rogelio,

I got further feedback from the customer. There is some success when WL18x talks to another BT device, but no success between WL18x devices:

On our side I have carried out a series of further tests, but unfortunately I have not yet achieved a breakthrough, but rather a confusing/worrying result. We have not been successful in getting the Bluetopia stack up and running.

We did get ready BeagleBone blue boards on which the TI WL1835MOD is populated so we can do independent testing . I was able to recreate the exact same behavior with this board , so the more I understand that the issue is within the TI Bluetooth module firmware and not within the operating system.

In addition, we performed a number of tests directly on the HCI interface to eliminate the Bluetooth stack as a source of error.

Finally, I made some progress in configuring the Bluetooth communication quality of service. This has enabled me to get an average latency of 8 ms (L2CAP echo request/response with 10% output in the range of 25 ms) – we would be completely satisfied with a latency of less than 15 ms.

However, this works with only a TI WL1837MOD and another Bluetooth module. As soon as I have a connection between 2 TI WL1837MOD modules, I get the Quality of Service configuration confirmed, but the latency remains 25 to 30 ms.

I have to make further attempts here.

The results were much more confusing when it came to investigating the latency between different Bluetooth modules.

Although the TI WL1837MOD part had connections with just under 30 ms latency, with virtually no outlier. Sometimes the latency changes, though, is short in the range of 8 ms and then again at 30 ms.

Depending on the attempt, I get different patterns in latency, although here I only repeat the same command that establishes a connection and measures the latency using L2CAP echo:

This experiment has turned out to be much more extreme between the TI WL1337MOD and an Intel Bluetooth module.

There I also performed a master-slave switch during the existing connection, which has understandably changed the latency pattern.

But depending on which module is used to build the initial connection, the latency and oscillation of the latency is extremely different.

It's the TI Bluetooth module, where I can see these vibrations repeatedly in different combinations with other Bluetooth modules, while the connections between the other Bluetooth modules almost always have a constant latency with few trips.

With one way to record the commands at the level of the Link Manager protocol of a Bluetooth connection, I could not detect any significant differences between the modules, the connection process continues to be identical.

At the moment, I cannot explain where the vibrations or the large outliers come from and why they are so extreme.

But this is just a minor issue, but hopefully it will show you how difficult the investigations are.

It would be helpful if TI had an application note that shows how to use TI modules to connect to Bluetooth low latency and what parameters this latency depends on.

Alternatively, a explanation of how the TI firmware configures the communication slots between the Bluetooth modules. The HCI_VS_CONFIGURE_DDIP command your co-worker mentions that there is a split between the Inquiry/Page Scan times, ACL communication, and SCO communication. Slots for low energy communication will also be reserved.
However, since I have switched off low energy communication and any scans that are not other communication (and turning off deep sleep does not affect), TI firmware seems to play another – unknown to me.

Thanks,
Robert

0 RogelioD over 1 year ago in reply to Robert Finger

TI__Genius 9465 points

Thank you for the new information. I am going to try to replicate it on my side using bluetopias version of l2ping.

Kind Regards,

Rogelio

Wi-Fi

Wi-Fi forum

WL1837MOD: Bluetooth latency higher than expected