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


i'm developing stereo headset bluetooth using classic profiles (hfp, a2dp, avrcp) 1 expect ina stereo headset. however, want deploy remote control app ios, , use simultaneously other classic links, dual-mode chipset i'm working in design not behave i'd expect;

the headset setup peripheral, letting ios device act central. such, peripheral advertise ble services (with specific 128-bit uuids) , good. can browse peripheral central, when i'm not connected classic profiles (e.g., while not streaming audio).

my device not seem able advertise ble, while connected hfp and/or a2dp! however, have seen demos of same chipset acting ble central, scanning , connecting other ble peripherals, while simultaneously streaming audio via a2dp. however, in setup device acting a2dp sink connected iphone, while scanning/connecting via ble third unit acting ble peripheral. hence, not point-to-point both classic , smart bluetooth same device.

is there dual-mode constraint 1 cannot act peripheral while supporting/connecting bluetooth classic profiles? , central-mode supported in case?

fyi, i'm using csr's 8670 chipset.

update

new answer added. apologies not clarifying/cleaning-up previous answer until -- time flies!

well, after digging down specs , trying understand things more clearly, i've found answers looking for, though have preferred more optimistic answers... ;(

nevertheless, let's it; bluetooth spec 4.0 (ble) says that;

dual-mode gadgets cannot act ble peripheral , advertise presence while still being connectable in "classic" bluetooth using br/edr.

furthermore, csr source-code examples csr8670 dual-mode chipset i'm using behave in same say; ble advertisements peripheral disabled when classic bt-link connected. instead, csr source code promote device should act ble central instead, allowing other ble peripheral units advertise , connect it, doable while streaming audio (acting a2dp sink).

this not suite setup @ since;

  1. ble centrals consume more power ble peripherals, , device needs conserve energy
  2. the dual-mode "combo"-problem of combining br/edr-device ble peripheral functionality moved phone instead, not work better since cannot expect apple (or else) violate ble spec.

instead, recommended approach let stereo headset skip ble entirely , use gatt on br/edr instead, known advertising via "vanilla", makes sense really; mean, have acl-link setup between 2 devices, why should need kick sort of discovery mechanism?

again, bluetooth sig comes in handy;

https://developer.bluetooth.org/technologyoverview/pages/gatt.aspx

gatt , att not transport specific , can used in both br/edr , le. however, gatt , att mandatory implement in le since used discovering services

so, sig says "yes" using br/edr transport gatt, question instead becomes; how can access that connected br/edr device within ios-app, typical scenario use cbcentral scan, discover , connect cbperipheral? answer simple; cannot, since ios 7.0 not (yet?) support gatt br/edr;

https://www.bluetooth.org/tpg/showdeclaration.cfm?3a000a5a005c5344535d5414403b0c0d0e2405022413010e57503f202a5a72

so, sum things up; if want have peer-to-peer setup between 2 dual-mode bluetooth devices, using both bluetooth classic profiles , bluetooth smart services/characteristics, should use gatt on br/edr, no-go apple-devices, might supported android (don't know, port app android though, regardless it's not big deal android since worst-case imply fallback spp , simple byte-protocol work need done).

that's that. hope i've helped ;) /markus


Comments

Popular posts from this blog

windows - Single EXE to Install Python Standalone Executable for Easy Distribution -

c# - Access objects in UserControl from MainWindow in WPF -

javascript - How to name a jQuery function to make a browser's back button work? -