This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

WL1831MOD: [WL1831][HFP][iphone8 ios11.2.2]The income call ringtones are different, the first time ringtone volume is too small. Another question.

Part Number: WL1831MOD


Phenomenon:

Iphone8 ios11.2.2, the first call is too small (it must be heard at this time to hear the maximum volume), after the call, cut off the mode, hang up the caller. The volume of the second calls will get bigger.

K256 SW4.9.6 + iphone8 ios11.2.2 can reproduce this phenomenon. The probability of reappearance is 100%.

Expectation phenomenon: the volume of incoming calls ringtone volume is consistent, not too small.

Analysis:

1. Bluetooth chip input: "Certification" iPhone 6C4D7303166E_to_BUICK 907065DAA1DD, is the air data, the first call and second calls in the air data and audio size of the same size.

2. Bluetooth chip output: btChip_to_audioDsp, the audio module writes the recording data directly to the file generation, the first call audio amplitude is obviously too small (0.005), the audio data needs to be heard by the headset; the second call amplitude is 0.05.

More info
1.  if don't answer the call, the incoming call ringtone volume will always be small.

2. after answered the call, the next time incoming call ringtone volume will be normally(larger than #1). 

3. If delete iphone and pair it again,  the incoming call ringtone volume will always be small again.

Conclusion:

The problem of Bluetooth chip is temporarily doubted.

For more attachment, please refer to following links:

e2e.ti.com/.../2504018

  • Sorry for the delayed response. The logs indicate that the WL18xx firmware is working as expected. Like I suggested in my older reply, the WL18xx outputs digital data in the PCM format and it is not possible to have such an issue (low volume) due to the Bluetooth controller. Please concentrate your debug on the audio data-path after the WL18xx (between WL18xx PCM interface and speakers).
    [jfq]My question is that TI chip input pcm is normal, but TI chip output pcm become small, how to explain this?
    "Please concentrate your debug on the audio data-path after the WL18xx (between WL18xx PCM interface and speakers)." is a bad suggestion.
  • Hi,

    Please refer to our discussion in the previous thread.

    user5297619 said:
    [jfq]My question is that TI chip input pcm is normal, but TI chip output pcm become small, how to explain this?

    I understand the phenomenon you have described.  

    user5297619 said:
    [jfq]"Please concentrate your debug on the audio data-path after the WL18xx (between WL18xx PCM interface and speakers)." is a bad suggestion.

    From our analysis, the WL18xxQ is working as expected. Please note that an issue like this would not be caused by some bug on the BT controller side. It may be caused by some discrepancy on the PCM interface. For example, if the PCM out of WL18xxQ is interpreted by the peer audio codec/processor with one bit offset, the volume would appear lower. Alternatively, it is possible that the data is sent with lower volume over the air. 

    Like I mentioned before, you need to focus first on the PCM interface and analyze the PCM stream with a logic analyzer to see if the PCM data captured with the logic analyzer matches with what is observed on the audio codec/processor on the other end. This will help you find out if the issue is in the PCM configuration.

    If the issue is not related to the PCM interface, compare the PCM data (captured by the logic analyzer) with the BT sniffer capture that can decode SCO/eSCO data over the air. Comparing these two will help you identify if the SCO/eSCO data is sent correctly over the air.

    Now, with the steps clearly defined, I hope you would be able to do the relevant analysis to debug this issue. 

    Best regards,

    VIhang

  • For example, if the PCM out of WL18xxQ is interpreted by the peer audio codec/processor with one bit offset, the volume would appear lower. Alternatively, 

    [jfq] The output of WL18xxQ is digital signal, do you have some theory article to support your guess "the peer audio codec/processor with one bit offset, the volume would appear lower". Otherwise, we do believe the output of WL18XXQ is wrong, and not be caused by discrepancy on the PCM interface.

    it is possible that the data is sent with lower volume over the air. 

    [jfq] BT sniffer capture  shows that the input of WL18xxQ is normal, but PCM data(captured by iMax CPU) shows that the output of WL18xxQ is very small.

    Like I mentioned before, you need to focus first on the PCM interface and analyze the PCM stream with a logic analyzer to see if the PCM data captured with the logic analyzer matches with what is observed on the audio codec/processor on the other end. This will help you find out if the issue is in the PCM configuration.

    [jfq]We think PCM data(captured by iMax CPU) is OK.  If "analyze the PCM stream with a logic analyzer', do you have any onsite support or other support to do this?

    If the issue is not related to the PCM interface, compare the PCM data (captured by the logic analyzer) with the BT sniffer capture that can decode SCO/eSCO data over the air. Comparing these two will help you identify if the SCO/eSCO data is sent correctly over the air.

    [jfq]This have been done. please refer to the former links attachment.

    e2e.ti.com/.../2504018

  • Dear user5297619,

    user5297619 said:
    [jfq] The output of WL18xxQ is digital signal, do you have some theory article to support your guess "the peer audio codec/processor with one bit offset, the volume would appear lower".

    This is not a guess. It is just how serial communication like PCM/I2S works. Please refer to PCM interface specifications and documentation for details.

    user5297619 said:
    [jfq] BT sniffer capture  shows that the input of WL18xxQ is normal, but PCM data(captured by iMax CPU) shows that the output of WL18xxQ is very small.

    OK.

    user5297619 said:
    [jfq]We think PCM data(captured by iMax CPU) is OK. 

    Thinking that something is not an issue and the WL18xx is the source of the issue is not enough. Do you have any proof to support your claim? 

    user5297619 said:
    do you have any onsite support or other support to do this?

    Please contact your local TI representative for this. 

    Best regards,

    Vihang