Many BLE devices have BR/EDR Controller Mode - LE + BR/EDR Host Mode in their Flags. Does this mean that this Device is also a classic Bluetooth device?
BR/EDR is the technical term for what you call bluetooth classic.
With "in their Flags" you probably mean in the advertisement? This would mean that the device at least reports, that it also implements bluetooth classic, yes.
I am programming a device which uses BR/EDR and BLE. BR/EDR is mostly used for audio data while BLE should work as control channel. Access to the used BLE characteristic returns a gatt_status_insufficient_authentication if and only if the central (smart phone) is not bonded. At least, that is what I want.
Moreover, if BLE bonding is triggered, I also get a BR/EDR bonding by Cross Transport Key Derivation (CTKD). Ok.
IF I do BR/EDR pairing from the phones pairing menu, this CTKD does not work. How could this work?
Or is there a way to enforce BLE pairing instead BR/EDR pairing?
Regards
In the Advertising section of a BLE, The Bluetooth SIG Define the "Flags"
which has these plus a few more.
BR/EDR Not Supported
Simultaneous LE and BR/EDR to Same Device Capable (Controller)
Simultaneous LE and BR/EDR to Same Device Capable (Host)
I am having an issue on a CSR chipset design that does not support GATT over BR/EDR.
Apple works great, as it always connects to LE.
..but android devices persistently try to connect GATT over BR/EDR if the audio is already up; therefore fail because CSR cant handle BR/EDR transport for GATT.
I am thinking these flags are at the core of the problem.
In CSR's demo code they do not set "any" of the above flags. I have had limited success with my problem on some handsets by setting the "Not Supported" flag.
The issue is the other two flags. How does Controller/ Host relate to other LE terms. For example Central/Peripheral or later Master/Slave.
I dont know what flags to set for my use case. Any suggestions welcome?
You can use a Static Random address for all LE operations. That way the Android device thinks it's a different device than when talking over Bluetooth Classic since that uses the public BD_ADDR.
Or, one variant of the connectGatt takes a transport parameter which you can set to TRANSPORT_LE to force communication over BLE.
If your device supports BLE and BR/EDR at the same time you should set these flags:
BR/EDR Not Supported=0
Simultaneous LE and BR/EDR to Same Device Capable (Controller)=1
Simultaneous LE and BR/EDR to Same Device Capable (Host)=1
If the flag data is missing completely, it's the same as if all fields are zero.
I'm wondering if Bluetooth 4.0 (low-energy) mobile phones could discover classic Bluetooth devices (3.0 and lower), and vice-versa. All I am interested in is discovering the "friendly names".
EDIT: As I have understood the replies of this post, Bluetooth 4.0 can discover classic Bluetooth devices but not the other way around. Then my follow-up question is, can a Bluetooth 4.0 device in LE mode discover classic Bluetooth devices?
The answer depends on if you mean Bluetooth v4.0 device, or BLE device, the two are not the same.
Bluetooth v4.0 = Classic Bluetooth + Bluetooth High Speed + Bluetooth Low Energy
Therefore, Bluetooth Low Energy is only a subset of Bluetooth v4.0. If your question is regarding Bluetooth v4.0 phones (generally phones are not BLE only), then the answer is Yes, Bluetooth v4.0 mobile phones can theoretically discover Bluetooth v3.0 devices and lower.
Hate to be blunt, but nope not possible (although it would be handy). 4.0 is 4.0 alone. Check out the Bluetooth Core Spec for more info
No a BLE can not discover a classic bluetooth device nor a classic bluetooth device can discover a BLE.
A device with BT V4 will discover both.
And A BT V4 will be discovered by BLE if it is advertising as BLE.
I also had same question, so I did little experiment.
I may contribute to this topic from my experiment that I did with old mobile(Nokia C5-00), New mobile(Samsung galaxy grand prime) and two bluegiga ble113 chips.
I swithched on bluetooth of all the devices and started scanning for near by devices I observed the following:
Observation1: Samsung galaxy grand prime (BT version 4 +Ble): It was showing both bluegiga ble113 chips, and Nokia C5-00 on the list.
Observation2: Nokia C5-00 (Earlier version of BT): It was showing only Samsung galaxy grand prime in the list.
Observation3: ble113: Out of the two ble113 chips one was in advertising mode and other in scanning mode at first the scanner chip was discovering only other BLE113 advertiser chip, but when I started advertising from Samsung galaxy grand prime phone using BLEBroadcast app the ble scanner chip started discovering the Samsung galaxy grand prime phone also.
Its perhaps late but just to clarify. The question in the title sounds like its asking about the interoperability of the two different Bluetooth modes, but the details of the question drift toward whether or not the mobile phone supports these two capabilities.
As far as the interoperability is concerned, as pointed out by VSingh, Classic Bluetooth discovery and Bluetooth Low Energy discovery work in opposite ways.
In classic, the endpoint [eg your Android] SEARCHING for devices TRANSMITS inquiry packets. Devices in discoverable mode, LISTEN for these packets and respond accordingly.
In Bluetooth Low energy, the endpoint [eg your Android] SEARCHING for devices LISTENS (scans) for advertisement packets. BTLE devices that are discoverable TRANSMIT these advertisement packets.
If the radio on your mobile device can do both of these things, then you can discover both classic and low energy devices.
I was thinking can we make Pebble watch to transmit signal strength over bluetooth and use it as a bluetooth advertisement device. This way Pebble itself can be used to do something that we have iBeacons doing.
Any thought about it?
No. Pebble does not provide any Bluetooth LE APIs (as of march 2014).
iBeacon is a Bluetooth LE based protocol. You will have to wait for Pebble Bluetooth LE apis to do that.