Studio Bluetooth Forum Discussions

Hi,

Does the customer come with an EZ-SERIAL FW to purchase CYBT-333032-02?

The customer mounts CYBT-333032-02 on the mounting board,

connects a coaxial cable to pin 26 (ANT), and confirms the output of 2.4 GHz with a Spectrum Analyzer,

but the output level is quite low at -30 dBm.

I would be grateful if you could give me some advice.

-----------------------------------------------

[Command used]

-----------------------------------------------

・ Mbt radio_tx_test (BDaddr) 2441 1 4 1 15 65535 0

-----------------------------------------------

[BT module connection status]

-----------------------------------------------

・ The power supply, reset, and recovery terminals are processed in the same way according to

     the circuit diagram of "CYBT-343026-EVAL Board". Send MBT tool via HCI UART.

Thanks,

Yang

Hello,

I am using WICED SDK 6.4 on 20706 based module, integrated Audio Gateway based on the hci_audio_gateway demo app. When testing with Airpods, I see SCO session is terminated whenever user takes out the non-default earbud (headset). It appears this device has an implicit "default" earbud (of the pair in Airpods) where the SCO (and RING) is delivered. When user takes out the other (non-default) earbud first from the charging case, on the Audio Gateway we are seeing a break in SCO, with the event BTM_SCO_DISCONNECTED_EVT. As long as user takes out the "default" earbud first from the charging case, the connection stays and HFP works fine.

Any clue what may be going on here? Is there a recommendation to interface with such headsets of wireless earbuds?

Thankyou
Praveen

Hello,

I am using WICED SDK 6.4 for 20706. The application is HFP audio gateway. Created out of the demo hci_audio_gateway. Testing against Jabra Boost v1.1.0. On some occasions when I power off the headset and power on, the peer initiated rfcomm is getting disconnected at some point during the AT cmd-responses. This occurs almost 50% of the repetitions when tested against with this specific model of the headset.

The callback  wiced_bt_port_mgmt_cback_t reports these messages as a server:

Satus = 19, Port Handle: 0x0001

On the occasions I see the Success, HCI traces are showing following order of RFCOMM channels:

When Headset is powered up:

• Signalling Channel Open
• AG Channel Open

When peer is powered down:

• AG Channel Close
• Signalling Channel Close

On the occasions the SDK callback wiced_bt_port_mgmt_cback_t reports Status 19, I see the following order of HCI traces.When Headset is powered up:

• Signalling Channel Open
• AG Channel Open
• Signalling Channel Close

I suspect that coinciding with the above signalling channel close callback reports status 19. Can anyone comment what may be an issue?

Thankyou
Praveen