• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 51 subscribers
  • Views 650 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2564MODA: HFP unit 1.6 + WBS restrain to 8kHz when connection is intended by the unit

Alain Werck
Prodigy 220 points
Part Number: CC2564MODA

Hello everyone,

I am working on a HFP unit which integrates CC2564MODA in a non-OS environment. The point is to connect smartphones with the WBS frequency (if the smartphone is compatible obviously).
As usual HFP units or other Bluetooth devices on the market, the first connection to the unit is intended by the user on the smartphone side (through Bluetooth menu).
For the next connection, it is up to the HFP unit to connect the smartphone in range, saving BT MAC address and link-key. This process is working fine.

The issue is :
When I connect the HFP Unit to a Samsung Galaxy S7 Edge running on Android 7.0, the first connection is working fine, audio transmitting at WBS frequency (16kHz).
But when the HFP unit automatically reconnect the smartphone, the audio transmitting is limited to 8kHz.

For the same phone running on Android 8.0, there is no more issue! (16kHz in both case)
Update the phone to Android 8.0 is not an option because my client wishes to cover must of Android version on the market.

 

So, I tried to analyze the difference between the 2 cases and there is mainly one:
the HFP unit receive the etHFRE_Codec_Select_Request_Indication three time for the non-working case (connection intended by the HFP unit) and only once for the working case (connection intended by a user on the smartphone).

Is this behavior due to my HFP unit firmware? (bad response to some event, ...)
Or is it just an Android bad Bluetooth integration with no workaround?
I join the logs for the cases.

Thanks in advance for any help.
Regards,

Alain.

BTLogger.zip

  • 0
    TI__Mastermind 29291 points

    Alain,

    Alain Werck said:
    For the same phone running on Android 8.0, there is no more issue! (16kHz in both case)
    Update the phone to Android 8.0 is not an option because my client wishes to cover must of Android version on the market.

    Alain Werck said:
    Is this behavior due to my HFP unit firmware? (bad response to some event, ...)
    Or is it just an Android bad Bluetooth integration with no workaround?

    This sounds like an interoperability bug on the older android flavor on this phone. The codec negotiation is part of the HFP profile and the information regarding this does not show up in the BT firmware logs. Do you have a BT sniffer (e.g. frontline or ellisys) to capture over the air BT traffic of the two scenario?

    Alain Werck said:
    So, I tried to analyze the difference between the 2 cases and there is mainly one:
    the HFP unit receive the etHFRE_Codec_Select_Request_Indication three time for the non-working case (connection intended by the HFP unit) and only once for the working case (connection intended by a user on the smartphone).

    In addition to the etHFRE_Codec_Select_Request_Indication event getting triggered 3 times, did you notice any other difference in the type of codec requested from the remote side?

    Best regards,

    Vihang

  • 0 in reply to Vihang Parmar
    Prodigy 220 points

    Hi Vihang,

    Thank you for your reply.

    1.
    Sadly we do not have any BT sniffer to capture packet over the air.
    Is it possible to capture those packets on the phone side with a dedicated application?
    We have the knowledge to develop Android application if there are no such thing on the store.

    2.
    Yes there is a difference between the 3 requests:
    - the request 1 and 2 ask for the 16kHz frequency sampling
    - the request 3 asks for the 8kHz frequency sampling
    So I was wondering if the responses that I send to the remote were somehow bad. But the firmware follows the same HCI commands flow (based on the HFPDemo.c file) in both cases.

     

    I am still brainstorming about that issue and I was wondering if it could happen because of a wrong SDP process on the unit side?

    When the phone is the cause of the connection (working case)
    we do not pass through an SDP process in the unit firmware

    When the unit is the cause of the connection (not working case)
    the unit firmware starts SDP_Service_Search_Attribute_Request, knowing the BT mac address, until it gets an acknowledge
    then knowing the HFP port on the remote side, it starts a HFRE_Open_Remote_Audio_Gateway_Port

    Is there something wrong in this procedure?

    Regards,
    Alain.

     

  • 0 in reply to Alain Werck
    TI__Mastermind 29291 points

    Alain,

    Alain Werck said:
    1.
    Sadly we do not have any BT sniffer to capture packet over the air.
    Is it possible to capture those packets on the phone side with a dedicated application?
    We have the knowledge to develop Android application if there are no such thing on the store.

    You can capture the BTSnoop logs on Android side (may require developer mode). These BTSnoop logs can capture the profile level traffic from the phone side and may provide some more insight.

    http://www.fte.com/WebHelp/BPA600/Content/Documentation/WhitePapers/BPA600/Encryption/GettingAndroidLinkKey/RetrievingHCIlog.htm