I’m currently in New York for this year’s ITP Camp, a 4 week unconference and technology playground for busy people. Held every June at ITP it brings together a diverse group of makers, artists, musicians, and creatives of all sorts—to make stuff, hear speakers at the cutting edge in technology and art, and collaborate with people they just wouldn’t normally meet.
It’s also a place to get things done that you haven’t managed to find time for and probably wouldn’t otherwise, and that was why last week I sat down—along with Tom Igoe, Don Coleman, Sandeep Mistry, Guan Yang, JB Kim and others—for a two day long Bluetooth LE doc-a-thon.
All of us have been working with Bluetooth LE devices—along with Don and Sandeep I’m writing a book for Make: on Bluetooth LE, cellphones and sensors, while Guan and JB have a startup building Bluetooth LE devices—but all of us agreed that getting started using Bluetooth LE was much harder than it should be, and that a lot of great work people were doing was getting dropped on the floor (or worse yet done again) because people didn’t know it existed. We decided to sit down and do something about that.
So as part of our doc-a-thon we gathered together documentation, videos, and code examples which we hoped would do just that.
How is Bluetooth LE different?
Bluetooth LE is very different from classic Bluetooth, in fact pretty much the only thing that is the same is the name.
Tom Igoe and Don Coleman give an overview of Bluetooth Low Energy.
You’re probably used to thinking about radios as sort of like a serial connection working similarly to a phone call between two phones—once you establish a connection, each person talks as the other listens and vice versa. They stay connected, even if neither is saying anything, until one hangs up and the call is ended.
In systems like these, data is transferred using a queue, and when data is read by the receiver, it’s erased from the queue, just as once my words reach your ears over the phone, they’re out of the communications channel. Effectively this is how “Classic” Bluetooth works.
Bluetooth LE is very different. Instead of communicating via a point-to-point connection like a phone, a Bluetooth LE radio acts like a community bulletin board, with each radio acting as either a board or a reader of the board.
If your radio is a bulletin board—called a peripheral device in Bluetooth LE parlance—it posts data on its board for everyone in the community to read. If your radio is a reader—called a central device in Bluetooth LE terms—it can read from any of the boards (the peripheral devices) that have information which it cares about.
If you don’t like that analogy, you can also think of peripheral devices as the servers in a client-server transaction. Similarly, central devices are the clients of the Bluetooth LE world because they read information from the peripherals.
But I like serial connections?
Most (perhaps all?) of the Bluetooth LE radios breakout boards available to makers right now—the RedBearLab BLE mini and the Adafruit Bluefruit LE for instance—pretend to look like serial devices for simplicity’s sake and present a UART service to the user. Effectively these radios are “faking” old style serial communication on top of the underlying bulletin board paradigm. It’s a hack, and actually not a good hack.
While it simplifies things from the Arduino side of things, by using the radio in this way you’re negating the “low energy” part of Bluetooth LE. The radios will be constantly on all the time, and if your project is battery based, that’s a big problem.
Tom Igoe and Don Coleman talk about services and Bluetooth LE.
Imagine a example where you want to control an LED connected to an Arduino board from our phone via Bluetooth LE. If we use a serial connection that connection will be open continuously, but it’s only going to get used periodically—when we send a 1 or a 0 over the air to the Arduino board to turn the LED on, or off.
As an alternative, you can heavily reduce the power consumption of your project by using Bluetooth LE like it’s supposed to be used and implementing a custom service for the radio connected to the Arduino to advertise its ability to turn the LED on or off.
Returning to our bulletin board example we’re creating a board (the service) which has a post-it note attached (known as a characteristic in Bluetooth LE parlance) which we can both read, letting us know if the LED is on or off, or write to—allowing us to control the LED.
Building a custom service
Unfortunately until recently building custom services for Bluetooth LE has actually been fairly complicated and not for the faint hearted. However it’s getting simpler as there’s now several good tools to do most of the heavy lifting for you.
In light of that we decided to look at one platform—the Nordic Semiconductor nRF8001 radio—and figure out a complete toolchain that would allow you to build a custom service for the radio, and make use of that service from an Arduino project. We picked this particular radio because it’s readily available and there is good library support.
The first thing you need to do when dealing with the nRF8001 is install Nordic’s nRFGo Studio, and while nRFGo is a MS Window’s application, it runs just fine on the Mac under OS X using Wine. This application is the tool you need to create the configuration file for the Bluetooth LE services that the radio will advertise, and as a by product it also creates a services.h header file that you’ll need as part of your Arduino project.
The “smart light switch”
We wanted to build something with multiple services, so we decided to build a “smart” light switch where you could not just turn the light on, or off, via Bluetooth LE but get the current status of the light switch (which also could independently control the light) and get notified when the switch was toggled.
Controlling a light via Bluetooth LE.
The nice thing about this example is how simple it is, beyond the Arduino board and the nRF8001 radio—we decided to use the Adafruit Bluefruit LE breakout board—you really only need a few wires, resistors and other commonly available parts.
Building the services.h configuration file using nRFGo Studio is probably the trickiest part of the whole toolchain, and we spent a lot of time figuring out the easiest way to allow you to include the generated services.h file inside your Arduino project, instead of having to include it inside the nRF8001 Arduino library.
While it meant a pull request for the library maintainer, and a few manual modifications to the services.h file, in the end we got it working, and this means that you work entirely within the Arduino IDE once you’ve generated your services configuration.
More details, and all the source code for the example projects, are available on Github as part of the documentation and code examples we put up during the doc-a-thon.
Conclusion
There now a huge number of off-the-shelf Bluetooth LE devices ranging from wearables to locks, from drones to lightbulbs—and of course the there’s always the now ubiquitous iBeacon—but there’s also a growing number of developer boards that mean making use of these off-the-shelf devices from your Arduino project (or becoming one) is also getting simpler. Hopefully our doc-a-thon is going to prove to be helpful to speed that process, and as it’s all up on Github contributions are of course very welcome.
ADVERTISEMENT
