Bluetooth is one of the mainstays of the mobile gadget world, allowing mobile devices to communicate easily over short distances. It’s how your wireless headset talks to your cell phone without the complexity and power requirements of WIFi. In particular, the Bluetooth Low Energy (BLE) component is interesting for those who build portable gadgets, because it requires a very small amount of power.
What Is Bluetooth LE?
Bluetooth LE, also known as Bluetooth Smart, is part of the fourth version of the Bluetooth standard. Finalized in 2010, Bluetooth 4.0 has been updated several times since, and the current version is 4.2, released in July of 2015. This version creates three different classes of device: Bluetooth, Bluetooth Smart Ready and Bluetooth Smart. The basic idea is that Bluetooth Smart indicates a device such as a pedometer or heart monitor that can only send and receive Bluetooth LE signals, while a Smart Ready device can handle LE and standard Bluetooth signals. A standard Bluetooth 4.2 device (such as a cell phone or USB dongle) can also send and receive Bluetooth LE signals.
At least, that’s the theory. Because Bluetooth has evolved over the years, actual compatibility is often difficult to determine. This isn’t helped by somewhat patchy support for Bluetooth in the operating systems of computers and cell phones: Bluetooth LE support for Android, for instance, was not included until version 4.3 (JellyBean), so there are still many Android devices out there that don’t support it. Apple has been more proactive: Bluetooth LE support was included in iOS version 6 and OSX version 10.9.
The purpose of Bluetooth LE is to open the standard up to a new class of devices: those that send small amounts of data infrequently, and run off of small batteries. Bluetooth LE runs on the same frequency band as standard Bluetooth: the 2.4GHz ISM (industrial, scientific and medical) band that does not require a licence to use. The ISM band is divided into 40 channels, and LE devices hop between these channels to avoid interference. To keep the power requirements down, Bluetooth LE has lower transmission power (between 0.01 and 10mW) than standard Bluetooth, which allows for power of up to 100mW for class 1 devices, and 1mW for class 3. Data is sent in the same way, (using gaussian frequency shift keying), but the speed of data is lower: a maximum of 1 Megabit per second (Mb/s), against the 24MB/s maximum of standard Bluetooth. Bluetooth LE devices can also switch between standby and active modes much quicker than standard ones, saving power by allowing small bursts of data to be sent.
Bluetooth classifies devices by their purpose, creating a number of profiles for things like headsets, headphones and human interface devices such as mice and keyboards. Bluetooth LE adds a new set of these profiles, called Generic Attribute (GATT) profiles. These include profiles for devices such as blood pressure monitors, and more generic profiles for devices like key fobs (the proximity profile). Most Bluetooth LE devices support a number of these profiles, with the specific profiles that are enabled being controlled by the firmware on the device.
Bluetooth LE devices use very little power, and are designed to run off batteries. The Nordic Semiconductor NRF52 series of chips, for instance, can run on a voltage of between 1.7 and 3.6V and draws just 1.2μA when the system is in idle mode. That is low enough that it could run for at least a year on a coin battery.
Bluetooth LE is definitely an interesting protocol for the hardware hacker, but it has its critics. Mike Ryan has demonstrated numerous security problems with the standard, breaking the encryption that the protocol uses and demonstrating how it is possible to remotely crash an Android phone using a Bluetooth radio.
How To Use Bluetooth LE
The easiest way to start working with Bluetooth LE is to get a development kit. These are widely available from the companies that make Bluetooth chips, such as Nordic Semiconductor, Texas Instruments and CSR. Adafruit also offers a neat breakout board based on a Nordic Semiconductor radio. For making standalone devices, the Lightblue Bean is a good place to start, as it combines a Bluetooth LE radio with an Arduino for easy programming and control.
small error, Class 3 = 1mW, not 1W
Thanks for pointing that out. Fixed.
It would be cool if HaD articles were hosted on github, so we could fork/branch and pull changes to grammar and specs even after the original author has long forgotten about the article. It would make it a good way to keep all the HaD articles technically accurate so that HaD could serve as a hacker encyclopedia of sorts
*push
That’s actually quite a nice idea, but who would supervise the pull requests and accept them?
This might be especially troublesome if there are things in the article that peolpe don’t agree on.
I don’t think I’d like hackaday to turn into a wiki.
Hmmm, thats a good point. Maybe just let HaD staff manage pull requests, so they can pick and choose the note-worthy pull requests. It would just be a nice way to open source their fact checking / researching / proof reading
I would be happy just with a skull so I have a list of articles that I thought “this could be usefull some day” nicely listed on hackaday.io
Also the maximum speed of ‘Standard Bluetooth’ is 3Mb/s, only 24Mb/s when BT3.0+HS which uses Wifi as an alternative PHY. which shouldn’t count ;-)
Still waiting for BLE mesh network
Me too. Because BT/BLE is in most new mobile devices the cost will drop dramatically and be much cheaper than other low power mesh networks.
I love the basic idea, but I’m concerned that BLE mesh won’t live up to the hype. The base protocol itself isn’t build to handle mesh well, so it feels like hammering a square peg into a round hole. ZigBee, Z-Wave, and other mesh protocols take meshing into mind with their spread spectrum schemes. BLE’s first stab at it gets around this by just using the 3 advertising channels for all of the meshing traffic. We’ll see what that does to BLE advertising of standard devices, and what it does to the throughput of BLE mesh. The second release will actually use the normal channels. I’m looking forward to seeing how they handle routing tables. Maybe they’ll solve all of these issues, but I’m a little skeptical till I see it work. In the end it’ll probably take off just because of the proliferation of standard devices with BLE radios (phones, laptops).
If we could only get the network router companies to build BLE into the routers alongside WiFi and support the BLE network profile, then the router itself could easily be a hub. (And support easy provisioning/control over BLE with mobile apps.) That wouldn’t give the RF coverage of mesh, but would give the equivalent data exchange ability of mesh networking.
Plus, the link to the LightBlue bean takes you to a 404 page. They seem to be re-arranging things there currently. http://legacy.punchthrough.com/bean/ is probably what you want
Thanks, fixed.
> a maximum of 1 Megabit per second (Mb/s), against the 24MB/s maximum of standard Bluetooth.
24Mbps. The correct capitalization and non-captializtion of units are important.
+1 I was going to post a comment just like this, but then I saw yours.
I keep having to turn off/on my bluetooth speaker and turn on/off my hand phone in order to keep them connected. That wastes my time and kills the batteries. Never mind, I’ll just plug a $0.25 jumper cable in instead. There – that’s better (sound of bluetooth speaker hitting the trash bin)…
I have the same problem with my tablet. It also pops and clicks every time a sound starts and stops. Are all Bluetooth speakers that crappy? I’m using the headphone jack now.
question for the experts: if there are security issues that are not fully solved, is this a viable protocol for remote software update on IoT devices?
any security issues scare me if you are talking about throwing an image (exe) at the device and if the image could be MitM attacked (etc) – that’s a big deal.
or, is this mostly theoretical? would it be wise or not – to design software update over BLE?
There are a number of security issues, but most are down to poor implementations. The standard its self is reasonably robust when compared to the security mechanisms Wifi implemented around the same time. *Most* of the flaws have had a human component, such as tricking the target user to re-pair so you can sniff the key exchange etc.
That aside, your second point. To keep costs down these devices are ultra embedded often running software from internal ROM with config in an EEPROM. Even devices with flash may only have a few Mbit of code. to do a local update of software you usually go into a bootloader mode, where a very small amount of code manages the reimage of the device with intelligence on the computer to recover to the original if there is a failure.
Remote update is even harder. You have to either have twice as much flash memory as you need (sometimes the most expensive component) so you can load the new image in the unused half and switch over to use the new image, falling back to the original if there is a problem. or have enough ram to load the new image, and be 100% sure is ok before committing to flash, and have a local wired bootloader to recover if there is a problem.
Bootloaders are relatively simple, remote less so due to failure recovery but what is more challenging is to get a non technical end user to understand. even with support and good documentation this is a significant risk of product returns, so rolling out updates and managing them is done typically only when needed and really only for high end products.
There have been three releases of the Bluetooth Core Specification starting with v4.0; v4.1; v4.2. Version v4. through v4.1 do have problems with secure encryption key exchange, and bonded, encrypted BLE communications can be sniffed or taken over using these older based BLE parts. In December of 2014 the Bluetooth SIG released v4.2 which uses a much better key exchange mechanism resulting in a reasonable secure connection. For more information google “LE Secure Connections”. That being said we are only just now staring to see support for v4.2 in BLE radios, by the middle of next year it should be commonplace.
The actual data rate for BLE is a few dozen bytes per second.
BLE devices are divided into ‘central’ and ‘peripheral’ categories. Central devices initiate and control connections, peripherals advertise their presence but otherwise wait for a central to tell them what to do.
The central device emits the clock signal that controls timing in a data transfer. That clock runs at 1MHz, and that value is responsible for the misperception that BLE has a 1Mbps bit rate.
BLE data transfers are packet-based, and a data packet can have up to 27 bytes of user data. Devices can only exchange packets during a ‘connection event’, and connection events can only occur at multiples of 1.25ms in the range between 7.5ms and 4s. Transfers are handled on a simple exchange pattern: the central sends a packet to the peripheral and the peripheral sends a packet back to the central. It takes about 300us to transmit a maximum-size data packet, and packets have to be separated by an inter-frame space of 150us. Each exchange of packets takes up to 900us, and the last packet in a connection event has to end at least 150us before the beginning of the next scheduled connection event.
In theory, you could set the connection interval to 4s and transmit data at a rate of about 25kBps both ways, but the central will stop transmitting if it doesn’t receive a valid packet in response to the one it sent. When that happens, you have to wait until the next connection event to try again. BLE radios are weak and highly susceptible to interference, so the more packets you send, the higher the chance of the sequence erroring out. In practice, you choose a connection interval that’s long enough to send the information you need without imposing too much latency if the exchange fails and the devices need to try again.
Real-world testing with hardware shows that you can get data transfer rates up to a couple hundred bytes per second under good conditions, dropping to maybe 20 bytes per second in a noisy environment.
Data transfer rates also depend heavily on the GATT data structures you use to encode information. A BLE device working as a wireless keyboard might only send a HID packet representing a single keypress in each connection interval.
By far the easiest system for Bluetooth LE development is the PSoC4 BLE. Bluetooth LE is horribly complicated, and there’s very little documentation to make developing things that use BLE enjoyable. The psoc actually makes this relatively easy: Cypress have reasonable documentation and their IDE allows you to easily configure all BLE-related aspects. Unfortunately, their chips are rather expensive, but the PSoC4 BLE Pioneer devkit is reasonably-priced and includes all the hardware and software to play around for quite a while.