we are designing a fairly compact PCB for a communications device. We are looking at using BLE as a link for voice to a separate microphone, and BT Classic to be paired with a smartphone. We are using pre-certified modules, and they will located on the PCB about 20mm away from each other (can extend this to 40mm if need be). Is there a risk of interference between the 2? We are transmitting audio in both cases so interference would be particularly noticeably. They both operate at 2.4GHz, but I understand they have different frequency hopping techniques, and hoping this will allow for coexistence.
Electronic – BLE and Bluetooth Classic Coexistence
bluetoothbluetooth low energyRF
Related Solutions
I have also been playing around with BLE, and decided to go with the Nordic nRF8001 chip because it looked easier to work with and didn’t require expensive IAR tools. nRF8001 is slightly cheaper than the CC2540 part in BLE112, but it is slave-only.
I bought Nordic’s nRF8001 development kit for $99, which includes nRF8001 samples and several nRF8001 boards (one with a trace antenna and one with an SMA connector) with standard 0.1" header for easy interfacing with your microcontroller development board. The documentation assumes that you have the $399 nRFgo development board and want to use the included nRF8200 microcontroller. I didn’t, so instead I wired an nRF8001 board directly to an Arduino.
You speak SPI to nRF8001, but basically with 2 different slave select-like pins. One pin (REQN) is a traditional slave select which is brought low to indicate that the master (you) want to send a message. The other pin (RDYN) is for the slave (nRF8001) to indicate that it received something over RF that it wants to send to the master, or that it is ready to receive a command from master. Master then brings REQN low and starts receiving.
The protocol is very concise and well documented (in the Product Specification PDF provided by Nordic) and I wrote an Arduino sketch to setup the nRF8001 and have it talking to my iPhone 4S in an afternoon. The format is basically one length byte, one command byte, and then optional command-specific arguments.
You will need Nordic’s nRFgo Studio software to create a configuration specifying the services your device will support; it will then include a services.h file containing the setup messages you need to send to nRF8001. I finally managed to emulate a heart rate monitor and display numbers in Nordic’s iOS demo app.
One big benefit of nRF8001 compared to BLE112 is that, apart from the proprietary setup messages generated by nRFgo Studio, you only deal with a well documented serial protocol. No firmware upgrades! It’s very cool that the CC2540 has an on-board 8051 microcontroller, but you’ll either need to pay thousands of dollars for the IAR tools or deal with the limitations and annoyances of BlueGiga’s software stack. A raw CC2540 is cheaper than nRF8001 plus a microcontroller, but BlueGiga’s boards are not cheap.
(There is a UART on the nRF8001 that is brought out on the boards included in the development kit, but it’s only for Bluetooth’s Direct Test Mode and isn’t ordinarily used.)
BLE is very unsuitable for even medium bandwidth streaming (audio or video), because it is designed for transfer of few and small data packets with lots of sleeping time in between. This is why it is called 'low energy' and not 'low power' - it reduces the amount of picojoules per bit for small packets with respect to competing standards. Other standards mostly use more power not because they have less efficient radios, but because at least the receiver is constantly powered up even when there are comparatively huge lulls in radio traffic, and because a significant portion of the transferred bits are not payload but instead overhead - protocol headers, checksums, even just blanking space. BLE eliminates most of these unnecessary power draws. But mind you, it doesn't magically improve power use of the transceivers when they are active. And when doing video transfer, the transceivers are constantly powered up. You lose the biggest advantage of BLE.
This design choice reduces overhead to essentially as little as you like, but also makes it that it does not have any streaming facilities built-in natively like packet recombination, delayed acknowledgement and asynchronous transfers. You actually don't have anything built in, BLE is as raw as you can get to a wireless interface, barring maybe nRF24 and TI CC2x00. As a result, you'll need to do this in software (either on a microcontroller or on your user device) and this uses incredibly much more energy than if you use a purpose-built protocol with hardware facilities for this like Bluetooth 3.0 EDR or WiFi.
This leads to the somewhat counterintuitive notion that once you start getting into audio-type data rates and above, Bluetooth Low Energy becomes, depending on your implementation, about 2x less efficient than Bluetooth 3.0, and when you get into the megabit range it is substantially less efficient than WiFi. This is why WiFi exists - that and arguably wireless range, although nowadays transceivers for both standards are very much equivalent. WiFi just has optional MIMO and diversity.
So even when not taking into consideration the - at least for video - very restrictive bandwidth and range limits that Bluetooth imposes, you may not achieve the goal of low power video transfer with this method.
Best Answer
They do not interfere with each other for most use cases. I've used them together in two different projects. I never had any issues.
Other people have pointed out that BLE might not be right for your application. I would definitely agree with them. With that aside though, for your more general question, yes you can definitely use them at the same time without worrying too much about interference.
When you use Classic and BLE at the same time, they complement each other. Typically, a product would use BLE for control. This results in the occasional transmission of small amounts of data. If a product integrated Classic as well, it would use Classic to transmit large amounts of data at a higher throughput. The device would see-saw back and forth between the two stacks. In that situation, they wouldn't interfere with each other. If you tried to transmit large amounts of data through both channels at the same time, that might result in poor performance for more reasons than just a shared frequency spectrum. They would also share the same antenna and processor.
Both stacks use some shared resources to keep the links alive, but Bluetooth doesn't require much to maintain connections by design.