This article originally appeared on rand(alex).

Vacation, hot sun, swimming pool, relaxing walks, no distractions… what better time todo some hacking. And I know just the project: an Eddystone beacon. I was looking for a cheap Eddystone™ beacon but most of the current vendors do have a tight coupling to their proprietary cloud platform and are damn expensive for one beacon, certainly with shipping. But luckily the Eddystone protocol is completely open and license free and I had a BLE board lying around anyway, so I could start making my own.

Eddystone Logo But what is Eddystone™ and why am I so excited about it? Well Eddystone is a protocol specification that defines a Bluetooth low energy (BLE) message format for proximity beacon messages. Think of it as an iBeacon™ on steroids, but open. All the scenarios where you think an iBeacon (with it’s unique id per beacon) would be applicable an Eddystone beacon would fit. But it adds 2 important features and those are discoverability and fleet management.

Without discoverability a classic beacon without an app installed on your phone is just a meaningless id that is being broadcasted to it’s surroundings. The Eddystone URL message adds discoverability by sending the URL of the service that's associated with the beacon.

The second addition is the telemetry message. That message contains information about the health of the beacon itself, like temperature, battery voltage and uptime. With this information you can manage all the beacons that you have deployed knowing when to replace the battery or the beacon in your fleet.

This is only the beginning, I see a lot more message types being added to the spec in the future. For more information go read on the spec at https://github.com/google/eddystone.

That was the spec, now on to the implementation. The first thing you need is a Bluetooth developers board. After playing around with BLE chips from other vendors I now swear with the nRF5x System-on-a-Chip series from Nordic Semiconductors. Not only are they the most powerful BLE chips, they also have great developer support with good documentation, a great stack overflow style forum and dev-boards. Important for me is the support for the gcc compiler with the soft drivers. Soft drivers are full BLE stacks in software that you flash on the chip. The support of gcc makes it possible to start programming without spending a fortune on a bad embedded IDE. Now I can use Jetbrains CLion (IntelliJ style IDE for C/C++) for writing my code and build my program with the gcc toolchain.

The board I used was the nRF51-DK kit. It’s a full board build around the nRF51 and a SEGGER-debugger chip. It also has Arduino Shield support having instant access to a lot of Arduino compatible hardware and it comes with the usual buttons and leds. If you want to play with Bluetooth Low Energy this is the board to get. As soon as the nRF52-DK (the successor) is out of preview I certainly order that kit as well. The nRF52 is even more powerful and energy efficient and adds NFC support.

With the board, the SDK and my IDE I could start building the Eddystone implementation. I started with the example of a classic beacon included in the nRF51’s SDK. In a few hours I had the UID frame implemented. Because the folks for Nordic Semi already had support for Eddystone frames in one of their Android debugging apps (nRF Master Control) I could validate the correctness of the frame. Once I got the UID frame, it was trivial to implement the URL and TLM (telemetry) frames. Having the frames it was just a matter of interleaving the messages at the correct interval. The code is actually only a few hundred lines of code. You can find the implementation at https://github.com/alex.../eddystone_nrf5x_beacon.

Now I have my own implementation I can start experimenting on Android and I’m ready for all the Eddystone frames that will come out in the future. No need to wait for a vendor to implement them.

Building an Eddystone™ beacon