We’ve finally put live our new blog, which unites the techblog and the labs blog into one. We’re insanely happy we’ve figured out how to use categories :-) Please let us know if you like the new blog!
So far, we’ve connected our “things” like the wine shelf in a fairly traditional way: cables from the sensors to an arduino or similar, then via another USB cable to a Raspberry PI and finally the PI was connected via an ethernet cable to the internet. When it comes to the wine shelf, that is a valid approach. But now we are exploring “things” in the retail environment, that we want to freely place in the shelf space. This means, we need to have a wireless technology in the equation. While we’ll most likely still use wires from one central hub, the “things” can now be freely be placed in a 10-20m radius. We’ve done quite some research, tried out NRF24 or even simpler wireless transmitters and it seems we’re choosing BLE in the end. While there are many other wireless prototcols out there, we believe BLE is both accessible to hackers like us and provides a robust protocol to get the job done (for example, it uses frequency hopping to make all data transmission more robust).
To begin a series about BLE, let me start with introducing the very basics of BLE. For a more detailed intro, I can recommend this book, which helped me a lot. First of all, it is a completely different protocol, not based on the former versions of Bluetooth and really only shares the name for marketing purposes (not sure if that is such a good thing though…). BLE is low energy – you’ve seen or at least heard of iBeacons, which use BLE advertisements (sent out around every second) and these last for several years with a coin-cell battery.
Every BLE peripheral, will host a number of ‘services’, identified via a UUID. Within these services, you can discover one or many ‘characteristics’, which hold the data you want to read or can be used as containers to put data in (which can then be retrieved by the peripheral). Some characteristics will also support notifications, which means your central BLE device, like maybe your phone or your PC, can get regular updates whenever the data changes (but consume little power during the phases of sleep).
When it comes to connecting your thing, let’s say an arduino or similar, you got some choices. The fun part is that they all roughly work the same. Just like with Serial on Arduino, you will find RX and TX characteristics that you can read from or write to. So you simply write your bytes and read bytes just like over Serial. Some of the boards we have tested also come with some higher-level protocols built in and then can be elegantly used via an Android or iOS API.
These are the choices we’ve taken a look at – the last one is currently my favorite:
The LightBlue Bean is currently my clear favorite, as it provides a really simple API, hooks into Arduino for easy programming plus works on a 3V coin battery. No tinkering with LiPo batteries or other power supply, it’s a pretty neat package. It also comes with an integrated accelerometer and an RGB led. It has just a few digital and analog pins, but it’s totally enough for connecting a simple sensor to an hub – and yes, all the important protocols liek I2C or SPI are supported of course.
To end this quick teaser, take a look at the picture above. You’ll see 4 lightblue beans, all connected to my mac at the same time. The beans increment an internal counter and notify the connected mac at random intervals. The next couple of days we’ll check how many we can connect to at the same time – sometimes the connection and disconnect behavior can be a bit tedious. So stay tuned for more about BLE, including code snippets for both the Bean and the client code in Node.js.