iOS Bluetooth dual-mode; connect BLE (GATT) to an already connected BR/EDR (A2DP/HFP) stereo headset simultaneously

Question

I'm developing a stereo headset with Bluetooth using the classic profiles (HFP, A2DP, AVRCP) as one would expect Ina stereo headset. However, I want to deploy a remote control app for iOS, and use it simultaneously to the other classic links, but the dual-mode chipset I'm working with in my design does not behave as I'd expect;

The headset is setup as a peripheral, letting the iOS device act as central. As such, the peripheral advertise its BLE services (with my specific 128-bit UUIDs) and all is good. I can browse the peripheral from any central, but only when I'm not connected with classic profiles (e.g., while not streaming audio).

My device does not seem to be able to advertise BLE, while connected with HFP and/or A2DP! However, I have seen demos of the same chipset acting as BLE central, scanning and connecting to other BLE peripherals, while simultaneously streaming audio via A2DP. However, in that setup the device was acting as A2DP sink connected to an iPhone, while scanning/connecting via BLE to a third unit acting as BLE peripheral. Hence, not point-to-point with both Classic and Smart Bluetooth to the same device.

Is there a dual-mode constraint that one cannot act as peripheral while supporting/connecting to Bluetooth Classic profiles? And that only Central-mode is supported in that case?

FYI, I'm using CSR's 8670 chipset.

UPDATE

New answer added. My apologies for not clarifying/cleaning-up my previous answer until now -- time flies!

Solution 1

You learn as long as you live, I suppose, and this question's answer is NOT that it's not supported which I claimed earlier (based on what I thought I knew).

The short and clean answer to dual-mode and headset development on CSR-chipsets is simply that it was a constraint in the CSR bluetooth stack on earlier SDKs.

The Bluetooth SIG has never not supported dual-mode acting as Peripheral while being connected via classic links to the same device. On the contrary, it clearly spec. how such interoperability should be carried out -- but that doesn't always mean that all BT-stack implementations out there are capable of such functionality.

Hence; Using the latest devtools and the latest Bluetooth firmwares/stacks from CSR has resolved all issues and dual-mode is now fully, and actually quite nicely I might add, supported on the CSR8670/75 chipsets.

Solution 2

Well, after digging down into specs and trying to understand things more clearly, I've found the answers I was looking for, even though I would have preferred to more optimistic answers... ;(

Nevertheless, let's get to it; the Bluetooth spec for 4.0 (BLE) says that;

Dual-mode gadgets cannot act as BLE peripheral and advertise its presence while still being connectable in "Classic" Bluetooth using BR/EDR.

Furthermore, CSR source-code examples for the CSR8670 dual-mode chipset I'm using all behave in the same say; BLE advertisements as peripheral are disabled when any classic BT-link is connected. Instead, the CSR source code promote that the device should act as the BLE central instead, allowing other BLE peripheral units to advertise and connect to it, all fully doable while streaming audio (acting as A2DP sink).

This does not suite my setup at all since;

1. BLE centrals consume more power than BLE peripherals, and my device needs to conserve energy
2. The dual-mode "combo"-problem of combining a BR/EDR-device with BLE peripheral functionality just moved to the phone instead, which will not work any better since we cannot expect Apple (or anyone else) to violate the BLE spec.

Instead, the recommended approach is let my stereo headset skip BLE entirely and use GATT over BR/EDR instead, also known as advertising via "vanilla", which makes sense really; I mean, I already have an ACL-link setup between two devices, why should I need to kick any sort of discovery mechanism?

Again, the Bluetooth SIG comes in handy;

https://developer.bluetooth.org/TechnologyOverview/Pages/GATT.aspx

GATT and ATT are not transport specific and can be used in both BR/EDR and LE. However, GATT and ATT are mandatory to implement in LE since it is used for discovering services

So, the SIG says "yes" to using BR/EDR as transport for GATT, but the question then instead becomes; how can I then get access to that connected BR/EDR device from within my iOS-app, where the typical scenario is to use CBCentral to scan, discover and connect to a CBPeripheral? The answer is simple; you cannot, since iOS 7.0 does not (yet?) support GATT for BR/EDR;

https://www.bluetooth.org/tpg/showDeclaration.cfm?3A000A5A005C5344535D5414403B0C0D0E2405022413010E57503F202A5A72

So, to sum things up; if you want to have a peer-to-peer setup between two dual-mode Bluetooth devices, using BOTH Bluetooth Classic profiles AND Bluetooth Smart services/characteristics, you should use GATT over BR/EDR, which is no-go for Apple-devices, but might be supported by Android (don't know, will port app to Android eventually though, but regardless it's not a big deal for Android since worst-case will imply a fallback to SPP and a simple byte-protocol to do the work that I need to get done).

That's that. Hope that I've helped someone ;) /Markus

Solution 3

I am also using the CSR8670 device. It have it working. Both a BLE peripheral and audio.

You need to be using ADK 4.0.0 by CSR.

Bluetooth 4.1 and Bluetooth 4.0 are different. For what you said about Bluetooth 4.0 is correct, but your chip can do Bluetooth 4.1.

4.1 allows such connections.

I also added "Dual mode" flags to the advertising packet.

There are a few conditions, such as a connection Interval of at least 90 miliseconds highly recommended so you dont mess with the audio.

Good luck!

Comments

[Paulw11]

I think that if you have to communicate with the device over classic Bluetooth then you are in MFI territory.

[Markus Millfjord]

But I'm not, really. My headset is a standard A2DP/HFP classic headset, and only connect to my iOS device for those adopted profiles, without any awareness of my iOS-app as such. But, the manufacturer of the Bluetooth chip that I'm using in the headset impl., (CSR8670) has some example code where they switch to what they call "vanilla" GATT, which is basically to simply add that GATT SDP-data to the device's service record. From what I've found, this is the way the BT 4.0 spec do things as well, but I'm not sure that Apple/iOS has implemented "GATT over L2CAP"...

[Markus Millfjord]

But yes, if all else fail, I'm looking at the MFi program for sure, but that would replace the BLE-stuff entirely and I'd just run Apple's iAP-profile in BT-classic mode instead.

[Markus Millfjord]

developer.bluetooth.org/TechnologyOverview/Pages/GATT.aspx

[Paulw11]

The only BT APIs exposed in iOS (aside from those in MFI) are those in CoreBluetooth - so if you can't discover the peripheral in BLE mode you are stuck.

[Markus Millfjord]

Just found my answer; GATT is not implmented/supported by the iOS stack, hence; hello MFi (bluetooth.org/tpg/…) ;)

[allprog]

Great that you found the solution! Please explain it in a short answer and accept it just for future documentation.

[Abilash Balasubramanian]

@MarkusMillfjord were you able to transfer data via BLE while song was playing from APP through A2DP ? i have requirement of playback through A2DP and data transfer through BLE from same APP. can i implement this way and make it to APP store ?

[Markus Millfjord]

@AbilashBNair yes, the CSR stack will help to down-prioritize LE data to allow A2DP streaming without interference. I'm actually even using dual A2DP streams simultaneously to create wireless stereo while having LE connected and used from my iOS app for EARIN as well as other products out there. It works, as long as the RF environment is not too harsh...

[Etan]

This should be possible with BT 4.1. For older devices, you can use LE Central + Classic Slave concurrently (with iOS acting as LE Peripheral).

[Markus Millfjord]

@Etan, what in the 4.1 spec would allow for this functionality? Could you point me in the right direction? Also, could you elaborate on what you mean by Classic Slave concurrency? Thx.

[Etan]

Well, the 4.0 spec only prevents using LE Peripheral while being connected via Classic BT as a slave. You can swap the LE Roles and use LE Central concurrently with Classic BT on 4.0 devices. 4.1 introduces Mesh functionality, and therefore, concurrent Peripheral and Central modes - I haven't verified if this extends properly to Classic/LE interoperability (that's why I only mention that it should be possible), but I heard that it would indeed work from other people (no hard evidence, though :) )

[Markus Millfjord]

Sounds promising @Etan! I've talked with CSR tech-support today, just after your comment and they confirmed that my use case is addressed in their upcoming 4.1 stack for the CSR8670 chipset. Only question for me is then if the 4.1 update will apply on all current 4.0 iPhones as SW-upgrade or not. I would expect 4.1 to be a SW-only-update, since CSR is working on a new stack for the 8670 chip/HW, but that's a different issue. Good news is that I should be able to get things working without MFi when 4.1 is seen on phones/chipsets. But that might take time...

[Etan]

iOS already supports concurrent LE Central / Multi-Peripheral and Classic Master / Slave connections, although this does not conform to standards.

[Markus Millfjord]

@Etan; your saying that iOS today can act as LE peripheral and establish connection to a Central, while simultaneously have Classic connections from the same iOS device to the same gadget? Could you point me in any direction for a brief spec/reference so I could look at the details? Thx!

[Markus Millfjord]

@Etan, I'd love to get a detailed description of your claim that iOS already supports concurrent LE Central / Multi-Peripheral and Classic Master / Slave connections, although this does not conform to standards. The bounty I threw out hopping that someone/you(?) could explain further will expire within 24h. Else, I'll stick to my precious conclusion; it cannot be done with BLE 4.0.

[Etan]

Yes, assuming that you have an accessory that the iPhone is connected to via Bluetooth BR/EDR, you can put a CBPeripheralManager into your app, and the accessory can discover this PeripheralManager, and can connect to it. Note that the BR/EDR connection is initiated from the iPhone side, and the LE connection is initiated from the accessory side. No need for MFi.

[Markus Millfjord]

@Etan, so you mean that iOS's "breach" in 4.0 spec is that they actually DO allow for simultaneous LE links to a BR/EDR connected accessory, letting the iPhone act as LE peripheral and advertise/connect to the accessor in LE central mode? I'm just puzzled and confused since iOS does not support GATT in BR/EDR...? Are you sure that a CBPeripheralManager can be used to connect to a LE central gadget already connected with BR/EDR? Theoretically or practically? I'll run some tests on this for sure, I'm just surprised that Apple would breach the BT 4.0 spec, that's all... ;)

[Etan]

Practically, I'm using A2DP and concurrently access the CBPeripheralManager on the same iPhone while connected. Yes, I mean that iOS's breach in spec is that they DO allow simultaneous LE links while connected via BR/EDR. They also allow concurrent LE central and peripheral links, even though the spec excludes this in v4.0.

[Etan]

Plus, Apple also breaches the BT 4.0 spec with their strange backgrounded app advertising that only is discoverable by fellow iOS devices ;)

[Markus Millfjord]

Interesting ;) one final question comes to mind before I get started testing myself; does it matter in which order the links are established? E.g., classic links establish, and THEN start you app and connect via CBPeripheralManager, or the other way around (start to stream audio AFTER the LE-link is setup)? Have you seen any difference in performance/connectability?

[Etan]

Don't have the setup here as it was for a customer's project, but afaik, it worked in both orders - can't give a guarantee on this, though. There was a case once with a certain Android version on a certain phone, that the LE connection got slowed down during audio streaming to unbearable levels - however, updating Android solved this problem.

[André Fratelli]

Great discussion, but I'm confused. How exactly do you connect using BR/EDR on the iPhone without MFi ?

[Markus Millfjord]

All classic Bluetooth (BR/EDR) links/profiles are connectable to your iPhone (given that the iPhone support the profile, obviously). No need for MFi just because you connect Bluetooth to an iPhone. The MFi program allows you to do a few more Apple-specific stuff, including establishing a serial comm link to allow for your app to comm with your gadget using your own serial protocol on top of that serial link/transport. And this is because Apple has disabled the classic Bluetooth profile SPP. Hence, the need/option to go via BLE and "tunnel" your serial link via a 20-byte characteristic instead.

[Markus Millfjord]

Furthermore, I've spend quite som time digging into this issue of dual-mode and CSR-chipsets and peer-2-peer links, and the conclusion is (confirmed by CSR) that it's actually a Bluetooth-stack restriction/limitation of the current available stack, and CSR is working on it and will support "true" dual-mode, as peripheral and/or central to the same BR/EDR-connected device, since of the SDK ADK4.0 which is scheduled for public release now in the end of June 2015.

[Paul Rolfe]

I just revisited this, because I found an issue that had not been brought up. The CSR software by default is not accepting EDR connections; which android tries if the handsfree is activated. It seems you cant always stop this, as some bluetooth protocol issues override the Software options in Android. The ADK can be tweaked to make this combination work, if anybody is interested in a solution comment on this and I can post more detail.