How to run Hands-free profile (HFPDemo APP)

Hi Joseph Gigi,

Thank you so much for the reply.

As we need to test the application as early as possible
we are looking for a ready made or easy options.

We found that there are Reference Designs board "BT-MSP-AUDSINK" & "BT-MSP-AUDSOURCE" from TI,
and checking the hardware we found that CC256XQFNEM could be connected to
BT-MSP-AUDSINK, BT-MSP-AUDSOURCE thorugh I2S(1.8V) interface.

If possible could you please let me know if this is a possible connection
and what else could be required.
MSP-EXP430F5438 + CC256XQFNEM + BT-MSP-AUDSINK + BT-MSP-AUDSOURCE

Best Regards
kummi

Hi,

Thank you for the reply.
I am sorry for the confusion.

As mentioned above we need to test Hands-free profile in a short duration,
but we are confused which are hardware tools to be used....

As mentioned above the HFPDemo wiki page mentions that "An external codec MUST be
connected to the CC256x I2S/PCM interface..."
We would like to know if there are any suggestions for external Codec EVM to test the Hands-free profile.

We thought of using BT-MSP-AUDSINK & boards because
BT-MSP-AUDSINK has Audio DAC(TAS2505) which can be used for Speaker output
and BT-MSP-AUDSOURCE has Stereo ADC(TLV320ADC3101) which can be used for Mic Input.

Meanwhile we tried to do some testings with MSP-EXP430F5438+ CC256XQFNEM + BT-MSP-AUDSINK + PassiveSpeaker
and a iPhone5S as shown below. (Running HFPDemo on MSP430F5438A)

But we didn't get any audio output on the PassiveSpeaker..
We get an error on the PC Terminal saying "WBS Feature is not enabled" as shown below.

Could you please let us know what could be this error and if there is any workaround.

Best Regards
Kummi

Hello Kummi,

  You may be running into some of the same APPLE related issues we are having with the BT Stack.  It does not seem possible to initiate a HF connection from the CC2564 with TIVA BT stack.  Regardless of the Port specified, the connection either closes after a short time, or fails to open completely.  So always try to connect by using the phone itself and clicking on the device to pair and connect in the Bluetooth screen.

   Apple devices also have a problem negotiating the Software Codec (CVSD or mSBC with WBS support.  I recommend removing the HFRE_HF_CODEC_NEGOTIATION_SUPPORTED_BIT bit from the HFRE_SUPPORTED_FEATURES #define.  Then you can force whatever software codec you want to use.

   It is NOT necessary to have a hardware codec connected to the I2S/PCM bus for the software side of things to function.  You'll obviously have no audio flowing, but the IO pins will wiggle just fine. 

    We have had no problems opening the remote audio gateway on android devices and then opening an SCO connection.  This is with or without WBS enabled.

    On Apple phones it also works fine, provided the phone initiates the pair, HF connection and opening of the SCO connection.  This is unacceptable - the CC2564 must have a way to reconnect if powered down or if it goes out of range... but we've not found a work around to date.

    Hope that helps at least share our experience.  Please try disabling codec negotiation and seeing if things improve.

 - Jason 

Hello Kummi,

   Here is a log of my pairing with an BlueGiga device, opening a Remote audio gateway connection it, then opening an SCO audio connection to it.

https://drive.google.com/file/d/0B9EYwAWdSUu2RkFXaUdYM0xMYWM/view?usp=sharing

   This is a log of an Apple phone seeing the CC2564, and the phone initiating a pair, HF connection and then opening an SCO connection when a phone call is made.  Then we close/open it a few times before hanging up and disconnecting the HF connection.

https://drive.google.com/file/d/0B9EYwAWdSUu2YVFQRjJ1cjVBVFE/view?usp=sharing

   We have not found any way for the CC2564 to open a remote audio gateway with an Apple phone.  So you must always initiate the connection from the phone.  This obviously won't work for most products, but we're hoping TI can get us some support on it here soon....

    Attaching a CODEC to the CC2564 can be tricky.  Not all CODECs are compatible, and many must be properly configured through their SPI or I2C interface to present the proper I2S/PCM data.   The CC2564 must also have its I2S/PCM bus configured for the proper bitrate and frequency the CODEC is expecting.

  Looking at that CODEC, you must be sure to configure it for DSP mode.  That is the mode where WCLK is being used as FSYNC. 

  I hope this helps some.  Just takes time to get it all configured correctly.  And it would be really nice if TI could investigate the CODEC negotiation problem.  Apple support disclosed this was a problem with the Bluetopia Stack, but without paying money I couldn't learn exactly where the problem lies - and even if I did know, without the source I cannot fix it.

   Finally, please let me know how working with the Apple phones go.   We'd be really interested to know if you are ever able to have the CC2564 re-establish a HF and SCO connection after walking out of range, or after power-cycling without initiating it from the phone itself.

Thanks,

-  Jason

Jason,

Have you seen this thread?

discussions.apple.com/.../6538777

It’s 28 pages long. In iOS 8 there is a hands-free problem affecting several car manufacturers. One person’s comment even agrees with what you are saying:

“Same problem here. iPhone4S with Mitsubishi Outlander Multimedia system. Worked perfectly with IOS 7. When making a call wit IOS 8, the bluetooth connection seems to be active, but when the connection with the other caller is made, the iPhone switches to iPhone as the audio source. When I choose bluetooth manually it works. But every call I miss “the first couple of seconds and it is dangerous because I have to look at my iPhone to switch the audio source in stead of looking at the traffic around me.”

When you choose Bluetooth manually the iPhone is most likely initiating the audio connection, which you said is working. Some people reported fixes by either hard resetting, resetting network settings, or resetting everything. Others said that these didn’t make a difference.

This is a very popular problem in iOS 8, and you said that it works fine on Android phones. Have you tested it on iOS 6 or 7, do you see the same issue? If you can replicate this issue in iOS 6 or 7 then please send us a logic analyzer trace of the rx and tx lines, we can handle Saleae .logic data files or CSV rx/tx logs with the timestamp of each byte received.