Bluetooth and the BBC
Microbit Introducing Young
People to an Unthinkably
Connected World

Part 2 of my BBC micro:bit series takes a much closer look at its Bluetooth^® capabilities and describes the way in which the micro:bit’s default Bluetooth profile was designed. Check out part 1, where I described the background to the micro:bit, it’s hardware features and architecture.

Designing the micro:bit Bluetooth profile

My first BBC micro:bit meeting was in the spring of 2014 and involved the BBC plus micro:bit partners Lancaster University, ARM and Samsung. We talked about the micro:bit. I talked about Bluetooth with low energy functionality and the potential it offered. In short, we got ourselves orientated. Prior to this meeting, the idea of having a predefined Bluetooth profile for the device had not yet been recognised. So the primary outcome of that meeting was not only would the micro:bit need a default profile but it would fall to me to lead the work of bringing it into existence.

We went on to have two more meetings where we brainstormed ideas for what we’d like to make possible using Bluetooth and the micro:bit. One of the things we had in abundance was ideas. Oh, and enthusiasm!

I generally went away after these meetings to pore over my notes and make sense of them against a backdrop of my own ideas, best practice and knowledge of technical feasibility.

Bluetooth Developer Studio

At this time, Bluetooth^® Developer Studio was in beta. I realised I had a great opportunity to put the tool through its paces by using it to help me design the profile for the BBC micro:bit. It proved a great time saver, allowing me to make design changes easily while giving me a framework within which to systematically define the various aspects of the profile, from the list of Bluetooth services down to the field-by-field breakdown of the various characteristics and their values.

I needed to share the design as it progressed through its iterations with the rest of the team and for that, I quickly put together a series of Developer Studio plugins which generated HTML reports from my profile design, at various levels of detail. The ability to quickly write plugins to meet my own special requirements was a great benefit and those plugins have since been adopted within the product and are now available by default to anyone who wishes to use them.

Profile Implementation

Dr. Joe Finney of Lancaster University implemented the profile design within the micro:bit runtime. He and I became “micro:bit partners in crime,” talking regularly and kicking about possible ways of improving the profile—in the light of the memory constraints of the micro:bit—to make communication more efficient or to make aspects of the profile easier to use. There was sometimes a trade-off between those two last issues as you can imagine.

In this way, the profile design went through a few iterations with various improvements made as we progressed. The version which finally shipped was not hugely different from the design I started out with but it did have some improvements. Notably, it was easier to set the micro:bit 5 x 5 LED display to a given pattern, albeit at the cost of “wasting” a few unused bits in the way LED patterns were encoded. In the initial design I’d left-shifted the bits which represented the state of each LED and saved myself an octet. In the end, it seemed more important to make it easier to work with than to fully optimise the design.

Implementation involved Joe using the ARM mbed API which itself was using the Nordic Semiconductor nRF51 APIs. One of the benefits of ARM mbed is that it acts as an abstraction layer. In theory, the micro:bit runtime could be used on another mbed device with relative ease.

The Profile

The micro:bit profile as included in initial shipments of the BBC micro:bit consists of eleven GATT services including the mandatory Generic Access and Generic Attribute services. Of the other nine, one is a SIG adopted service (Device Information) and one is a custom service defined by Nordic Semiconductor. The latter is the DFU (Device Firmware Update) Service which allows firmware to be flashed over Bluetooth low energy connections. This capability is used by the Samsung micro:bit Android application  which allows you to write code for the micro:bit on your phone or tablet and then flash it to your micro:bit over Bluetooth. That’s right. You can write micro:bit code without a desktop or laptop computer!

The other seven services were custom designed for the micro:bit to allow connected devices such as smartphone applications to remotely leverage the micro:bit’s various capabilities. Let’s take a quick guided tour using screen shots from Developer Studio of each service definition together with its characteristics.

A connected application can enable notifications on the Accelerometer Data characteristic and will receive notifications at a frequency controlled by the Accelerometer Period characteristic which itself may be written to. By applying a low pass filter to the accelerometer data, you get nice smooth motion data as frequently as once every 20ms if required.

The Magnetometer Data characteristic can deliver notifications containing X, Y, and Z values which describe the current bearing as a 3D vector:

• X is the magnetic field strength in the direction of magnetic north
• Y is the magnetic field strength in the direction of magnetic east, i.e. 90 degrees from magnetic north
• Z is the magnetic field strength vertically down

From the X, Y and Z vector values it’s then possible to calculate the direction of magnetic north and its strength in microteslas.

To make life easier for simple use cases, we also included the Magnetometer Bearing characteristic which uses notifications to deliver data but this time the values are compass bearing measurements in degrees from North.

Magnetometer Period configures the frequency with which data is acquired from the magnetometer itself.

The micro:bit has two buttons on the front panel, imaginatively named Button A and Button B. We decided each could be in one of three states; Not Pressed, Pressed or Long Press. The latter state is entered whenever a button is pressed and held down for at least 2 seconds. These states are represented by values 0, 1 and 2 respectively. Peer devices can read the current state or more usually will enable notifications and be informed proactively whenever the associated button state changes.

The IO Pin service allows a peer device to read and write digital and/or analogue values from/to any of the pins exposed on the micro:bit edge connector, including the 3 main ring ports. It’s arguably a little more complicated than the other services. Here’s how the characteristics are used:

• The Pin AD Configuration characteristic contains a bit mask which allows each pin to be configured for analogue or digital use. Bit n corresponds to pin n where 0 <= n < 19. A value of 0 means digital and 1 means analogue.
• The Pin IO Configuration characteristic contains a bit mask which allows each pin to be configured for input or output use. Bit n corresponds to pin n where 0 <= n < 19. A value of 0 means output and 1 means input.
• The Pin Data characteristic is used to read values from one or more pins concurrently via Bluetooth read operations or write data to pins using Bluetooth writes. Notifications are also supported as a means of receiving input data.

Relatively complicated but it’s also remarkably useful. Peer Bluetooth^® devices can control electronics projects physically connected to the micro:bit and can acquire data from connected items like sensors and this can be done with multiple connected things, all simultaneously. Take one micro:bit, connect some electronic things, add a sprinkle of Bluetooth low energy technology and a smartphone or other IP connected device and you have a nice recipe for an IoT education project!

The micro:bit has a 5 x 5 LED display which can be set to arbitrary patterns or it can scroll text across itself at a given speed. This service allows patterns to be set by writing to the LED Matrix State characteristic and short text strings can be sent to the micro:bit by writing to the LED Text characteristic. The Scrolling Delay characteristic is used to control text scrolling speed of course.

To make life as easy as possible, the LED matrix state is represented by a bit pattern in an array of 5 octets where each octet corresponds to a row in the matrix and bits 0 – 4 correspond to an LED in that row. A value of 1 means ON and 0 means OFF. In my Android code, I used a byte array and included comments as shown to make this clear.

In the architecture section of part 1 of this series, you can see a box labelled “Message Bus.” This component of the architecture allows various system components to listen for events created by other components and to respond to them. An event is represented by data which has a type or “source” and a value, each of which is a 16-bit number.

The Event service extends this idea to a connected peer over Bluetooth^®, giving rise to a bidirectional event communication mechanism. A connected peer can send an event object to the micro:bit by writing to the Client Event characteristic and a micro:bit can inform a connected peer of an event of interest using notifications from the MicroBit Event characteristic. The two “requirements” characteristics allow subscription to events types/values of interest. So, for example, a connected peer like a smartphone can tell micro:bit it wants to receive a notification whenever an event of type 0x0025 with any associated value occurs by writing 0x25000000 to the Client Requirements characteristic. Yes, little endian ordering is used. Well spotted!

A temperature, derived from the die temperature of the nrf51822 CPU, is available and can either be read from the Temperature characteristic or reported to a connected peer using notifications at a frequency controlled by Temperature Period.

Security

Part of the profile specification deals with security. Since micro:bit is a programmable device with an inestimable number of uses, I thought about its use in classrooms and how we should inform the choices made for the micro:bit’s default security settings. I discussed my thoughts with the BBC, who were keen to ensure there were appropriate safeguards in place.

Consequently for most uses, micro:bit needs to be paired with another device (like a phone or tablet) and the link encrypted. Passkey authentication is used during pairing and accept listing is used so that connection requests are only accepted from peers that have paired.

Videos

There’s no substitute to actually seeing the profile in action. I’ve a growing collection of videos which demonstrates micro:bit and Bluetooth. Take a look and you’ll see every one of the services I’ve described here in use in some way.

Profile Evolution

The profile as described relates to the micro:bit as it was initially shipped earlier this year. Since then, James Devine of Lancaster University added an implementation of Nordic Semiconductor’s UART service which provides a simple serial data communications capability. I hear rumours that HID will be added too at some point. But, of course, the point is that micro:bit is programmable so if you have the inclination and the know-how you can equip your micro:bit with whatever Bluetooth^® services you want.

Reference Documentation

Documentation for the micro:bit profile can be found here:

http://lancaster-university.github.io/microbit-docs/ble/profile/

Check the Bluetooth^® menu for access to a page dedicated to each service.

In Part 3, I’ll review the many and varied ways in which you can program the micro:bit and peer applications.