WL1831: Unable to connect to WH-1000XM3 headset

Hi Jeremy,

I'll get back to you on this shortly.

Thanks,
Jacob

Hi Jacob,

Thanks for your reply. I was just wondering if you had any update?

Kind regards,
Jeremy

Hi Jeremy,

I looked at your sniffer files, thank you for providing those. Can you point me to the place where you see the TI controller's 0x02 and the headset's 0x00 WeSCO parameters? I am having trouble finding that exchange.

Best regards,
Jacob

Hi Jacob,

Thanks for your reply. Please see screenshots below showing the WeSCO parameter negotiation sequence, and screenshot from the trace itself (packets 8318 to 8372).

Kind regards,

Jeremy

Hi Jeremy,

Thank you for the update. I'll provide some information here tomorrow.

Thanks,
Jacob

Hi Jeremy,

In order to give you a better response, I need to follow up with another team member. Please give me until next Tuesday to provide insight here.

Thanks,
Jacob

Hi Jeremy,

When I try to open your .cfa, I am unable to see packets 8,318 - 8,372 in the LMP tab:

I can see them in the Baseband tab, but no negotiation parameters are present there:

Can you verify that you are able to view these packets from the files you sent me? Also, can you provide a picture of the not_accepted_ext packet from the negotiation sequence you mentioned? I'd like to see the error code associated with the negotiation:

If I understand your table correctly, the eSCO sets occasionally change from S3 to S1 on our WL1831?

Thanks,
Jacob

Hi Jacob,

Thanks for your message. I think the issue is you need to enter the Link Key in order for the analyzer to decode the LMP packets (see "resw27200 link key.txt" for the link key in the original zip).

If you select View->Security to view the security window, paste the link key into the security window, then click 'Analyze'. The viewer will then repass the log and the LMP packets should be decoded correctly.

It's also worth mentioning our eSCO negotiation sequence comes from the parameter set values coded in our BlueZ Linux stack:
a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -39,6 +39,8 @@ structsco_param {
};

static const struct sco_param esco_param_cvsd[] = {
+ { EDR_ESCO_MASK & ~ESCO_2EV3| ESCO_EV3,
+ 0xffff,0x01 }, /* Be tolerant: EV3 or 2EV3*/
{ EDR_ESCO_MASK & ~ESCO_2EV3, 0x000a, 0x01 }, /* S3 */
{ EDR_ESCO_MASK & ~ESCO_2EV3, 0x0007, 0x01 }, /* S2 */
{ EDR_ESCO_MASK | ESCO_EV3, 0x0007, 0x01 }, /* S1 */

where:
struct sco_param {
u16 pkt_type;
u16 max_latency;
u8 retrans_effort;
};

Note: We've added an additional entry here to the standard implementation, to be more tolerant to EV3/2EV3 devices, but have tested the Sony headset with and without these changes. To summarize our host's request sequence, please see 'Setup Synchronous Connection' requests in the following HCI log snippet:

< HCI Command: Setup Synchronous.. (0x01|0x0028) plen 17  #139 [hci0] 51.006369
        Handle: 1
        Transmit bandwidth: 8000
        Receive bandwidth: 8000
        Max latency: 10
        Setting: 0x0060
          Input Coding: Linear
          Input Data Format: 2's complement
          Input Sample Size: 16-bit
          # of bits padding at MSB: 0
          Air Coding Format: CVSD
        Retransmission effort: Optimize for power consumption (0x01)
        Packet type: 0x0380
          3-EV3 may not be used
          2-EV5 may not be used
          3-EV5 may not be used
> HCI Event: Command Status (0x0f) plen 4                 #140 [hci0] 51.012190
      Setup Synchronous Connection (0x01|0x0028) ncmd 1
        Status: Success (0x00)
> HCI Event: Synchronous Connect Complete (0x2c) plen 17  #141 [hci0] 51.027346
        Status: SCO Interval Rejected (0x1c)
        Handle: 257
        Address: 94:DB:56:6F:04:34 (OUI 94-DB-56)
        Link type: eSCO (0x02)
        Transmission interval: 0x00
        Retransmission window: 0x00
        RX packet length: 0
        TX packet length: 0
        Air mode: CVSD (0x02)
< HCI Command: Setup Synchronous.. (0x01|0x0028) plen 17  #142 [hci0] 51.027679
        Handle: 1
        Transmit bandwidth: 8000
        Receive bandwidth: 8000
        Max latency: 7
        Setting: 0x0060
          Input Coding: Linear
          Input Data Format: 2's complement
          Input Sample Size: 16-bit
          # of bits padding at MSB: 0
          Air Coding Format: CVSD
        Retransmission effort: Optimize for power consumption (0x01)
        Packet type: 0x0380
          3-EV3 may not be used
          2-EV5 may not be used
          3-EV5 may not be used
> HCI Event: Command Status (0x0f) plen 4                 #143 [hci0] 51.031656
      Setup Synchronous Connection (0x01|0x0028) ncmd 1
        Status: Success (0x00)
> HCI Event: Synchronous Connect Complete (0x2c) plen 17  #144 [hci0] 51.052218
        Status: SCO Interval Rejected (0x1c)
        Handle: 257
        Address: 94:DB:56:6F:04:34 (OUI 94-DB-56)
        Link type: eSCO (0x02)
        Transmission interval: 0x00
        Retransmission window: 0x00
        RX packet length: 0
        TX packet length: 0
        Air mode: CVSD (0x02)
< HCI Command: Setup Synchronous.. (0x01|0x0028) plen 17  #145 [hci0] 51.075987
        Handle: 1
        Transmit bandwidth: 8000
        Receive bandwidth: 8000
        Max latency: 7
        Setting: 0x0060
          Input Coding: Linear
          Input Data Format: 2's complement
          Input Sample Size: 16-bit
          # of bits padding at MSB: 0
          Air Coding Format: CVSD
        Retransmission effort: Optimize for power consumption (0x01)
        Packet type: 0x03c8
          EV3 may be used
          2-EV3 may not be used
          3-EV3 may not be used
          2-EV5 may not be used
          3-EV5 may not be used
> HCI Event: Command Status (0x0f) plen 4                 #146 [hci0] 51.079876
      Setup Synchronous Connection (0x01|0x0028) ncmd 1
        Status: Success (0x00)
> HCI Event: Synchronous Connect Complete (0x2c) plen 17  #147 [hci0] 51.099465
        Status: SCO Interval Rejected (0x1c)
        Handle: 257
        Address: 94:DB:56:6F:04:34 (OUI 94-DB-56)
        Link type: eSCO (0x02)
        Transmission interval: 0x00
        Retransmission window: 0x00
        RX packet length: 0
        TX packet length: 0
        Air mode: CVSD (0x02)
< HCI Command: Setup Synchronous.. (0x01|0x0028) plen 17  #148 [hci0] 51.099791
        Handle: 1
        Transmit bandwidth: 8000
        Receive bandwidth: 8000
        Max latency: 65535
        Setting: 0x0060
          Input Coding: Linear
          Input Data Format: 2's complement
          Input Sample Size: 16-bit
          # of bits padding at MSB: 0
          Air Coding Format: CVSD
        Retransmission effort: Optimize for power consumption (0x01)
        Packet type: 0x03c4
          HV3 may be used
          2-EV3 may not be used
          3-EV3 may not be used
          2-EV5 may not be used
          3-EV5 may not be used
> HCI Event: Command Status (0x0f) plen 4                 #149 [hci0] 51.104368
      Setup Synchronous Connection (0x01|0x0028) ncmd 1
        Status: Success (0x00)
> HCI Event: Synchronous Connect Complete (0x2c) plen 17  #150 [hci0] 51.106716
        Status: Command Disallowed (0x0c)
        Handle: 1
        Address: 94:DB:56:6F:04:34 (OUI 94-DB-56)
        Link type: SCO (0x00)
        Transmission interval: 0x00
        Retransmission window: 0x00
        RX packet length: 0
        TX packet length: 0
        Air mode: u-law log (0x00)

Kind regards

Jeremy

Thanks Jeremy,

I'll look into this next week.

Thanks,
Jacob

Hi Jeremy,

Apologies for the delay, I'll follow up here on Monday.

Best,
Jacob

Hi Jeremy,

So sorry for the delay. I'll give you more information this week.

Thanks,

Jacob

Hi Jeremy,

Thank you for the patience. Now that I can view the eSCO_link_req, I see that every time the eSCO connection is attempted, the connections are not accepted. As you see in your logs, this is due to either latency violation or unsupported parameters.

It looks like the initial negotiation tries to use 2-EV3. What happens if you limit your headset to only supporting this packet type? 

This related thread may be of use to you.

Thanks,
Jacob 

Hi Jacob,

Thank you for your reply.

When you say 'limit your headset to only support 2-EV3', presumably you mean 'limit your host'? We're obviously using a third-part headset and don't have control over this from the device side.

I'm happy to gather the logs as suggested and should be able to get back to you later this week. My only reservation is what impact this might have? The first 6 requests we make during the connection are all with a 2-EV3 packet type, so I wonder if this test might only result in a subset of attempts from the existing log? But happy to explore this avenue.

Kind regards,

Jeremy

Hi Jeremy,

Before you try that test, I will reach out to another team member to see if there are any other tests we can try. If there are no other tests, we can try limiting the connection negotiation to 2-EV3 only.

Thanks,
Jacob

Hi Jeremy,

Is it possible for you to take air-sniffer logs as you did before, but with a controller that succesfully connects to your Sony WH-1000XM3 headset? I think the WeSCO and TeSCO parameters need to match, but I want to see if there is anything else required for a successful connection.

Thanks,
Jacob

Hi Jacob,

Please see below for a snippet of an Ubuntu laptop connecting the Sony headset (i can provide the full log if you need further details).

This is using the same parameters as packets 8318 and 8321 in sniffer log from our controller, accept the connection is obviously accepted in this case in packet 7816 in the screenshot below.

If you have any further questions, please let me know.

Jeremy

Hi Jeremy,

From the pictures you provided, it does not appear that DeSCO, TeSCO, and WeSCO need to match for a successful connection. Can you also provide a screenshot packet 7,816 or the logs?

Thanks,
Jacob

Hi Jacob,

Sure, please see below for packet 7816. I'm struggling to re-attach another zip to the thread.

Jeremy

Hi Jeremy,

Very sorry to ask you for more screenshots, but could you also include the screenshots for packet 7,812 and 7,815? I think the max slot request may provide the successful connection. 

Thanks,
Jacob

Hi Jacob,

No problem, the packets are as per screenshots below. 

To give a bit more context I've uploaded a copy of the log here: https://insync.druva.com/home/link/browser?ll=AAAENQAej34AAEaJN4BNFCYoq2xwiZ1rWmZmzJghR6M%3D. You can access the log with password "c^vqpLygd8mj". The link will expire in a few days, but if you have any problems let me know. 

It looks like the LMP max_slot_req requests are repeated a few times throughout the session, but appear to be rejected with a 'Reserved Slot Violation'.

Jeremy

Thanks Jeremy, I'll review the logs and get back to you soon. What's strange is that I do not see a packet where the parameters (WeSCO, TeSCO, DeSCO, Max Slots, etc.) match between central and peripheral. I'm still looking to see where the successful negotiation parameters are located.

Thanks,
Jacob

Hi Jeremy,

Apologies for the delay, I am still searching for an answer for you. In reviewing your previous logs, I referenced the Bluetooth v5.3 Core Specification. There are a few conditions where an LMP_not_accepted_ext can be generated in relation to eSCO logical transport. 

From section 4.6.2.5:

I can work through these rules (2,3,4,7, and 8) and identify where the problem might be.

Thanks,
Jacob

Hi Jacob,

Just a quick status update to say I'm looking try this with our headset over the next few days. I'll get back to you early next week. For reference, using HCO_VS_Read_SCO_Configuration, our default configuration is as follows:

< HCI Command: ogf 0x3f, ocf 0x0211, plen 0

> HCI Event: 0x0e plen 16

  01 11 FE 00 00 B4 04 D0 02 01 00 B4 04 D0 02 01

===>

  01    = HCI command packet

  11 FE = Command HCI_VS_Read_SCO_Configuration (0xFE11)

  00    = Status (Command Succeed) (Valid Range 00 ->255)

  00    = Channel 0 Connection Type (CODEC Connection) (Valid Range 0 ->1)

 B4    = Channel 0 TX Buffer Size (180)  (Valid Range 1->255)

 04    = Channel 0 Number of Buffers (04)  ((Valid Range 0->255))

 D0 02 = Channel 0 TX Buffer Maximum Latency (720) (1-> 720)

 01    = Channel 0 Accept packet with bad CRC (Accept Packet with bad CRC)  0x00-> 0x01)

  00    = Channel 1 Connection Type (CODEC Connection) (Valid Range 0 ->1)

 B4    = Channel 1 TX Buffer Size (180)  (Valid Range 1->255)

 04    = Channel 1 Number of Buffers (04)  ((Valid Range 0->255))

 D0 02 = Channel 1 TX Buffer Maximum Latency (720) (1-> 720)

 01    = Channel 1 Accept packet with bad CRC (Accept Packet with bad CRC)  0x00-> 0x01)

Hi Jeremy,

Thanks for this. I think understanding the max latency here is the most important here for connection attempts between the headset and the WiLink.

Thanks,
Jacob

Hi Jacob,

Apologies for the slow reply. I carried out some further testing last week, and have a few questions please, as I was unable to resolve the issue with different max latency values.

1. In the HCI_VS_Write_SCO_Configuration screenshot above, are these values known to work with the Sony headset? (I gather TI may have the same headset to help debug the issue).
2. Is the 'TX buffer maximum latency' in the 0xFE10 HCI_VS_Write_SCO_Configuration command, the same parameter as 'Max_Latency' in the standard 0x0028 HCI_Setup_Synchronous_Connection? We always call HCI_Setup_Synchronous_Connection to establish the connection, and I was wondering if this was overwriting any previous settings using HCI_VS_Write_SCO_Configuration.
   
   As an experiment I tried different Max_Latency values in HCI_Setup_Synchronous_Connection  but ended up with the following:
   
   
   
3. I notice looking at the HCI_VS_Write_SCO_Configuration documentation that 'TX buffer maximum latency' may only apply if flow control is disabled? Could this be why the latency measurements aren't having an effect?

Thanks for your help and support,

Jeremy

Hi Jeremy,

1. I am not sure of the exact parameters you need to specify to ensure connection to the Sony headset. TI does have access to this headset on a remote site. 

2. HCI_Setup_Synchronous_Connection could potentially overwrite the latency value specified in HCI_VS_Write_SCO_Configuration. Have you tried calling one command before the other, and vice versa? Maybe HCI_VS_Write_SCO_Configuration needs to be called after HCI_Setup_Synchronous_Connection for setting the max latency correctly.

3. Can you specify how you configure the WiLink over UART? Are you using 4-wire UART with flow control (H4 protocol), or are you using 3-wire UART (H5 protocol)?

Thanks,
Jacob