Monday, 14 August 2017

Bitty Blue on Chromebook

A new version of free application Bitty Blue was made available for Chromebook yesterday. It's now available on iOS, Android and Chromebook.

Bitty Blue lets you play with the primary Bluetooth features of a BBC micro:bit and hopefully could form part of lessons and coding club activities, prompting the question "how does that work?" at every turn.

Chromebook seems a great platform and I understand that in some parts of the world it's the standard kit to be found in classrooms.

Teachers and STEM leaders.... hope you find this useful and fun.

Friday, 4 August 2017

Bitty Data Logger 2.4.0

Bitty Data Logger 2.4.0 was just released for both iOS and Android. It adds one new feature, namely the ability to trigger calibration of the digital compass in a connected BBC micro:bit, on demand.

Capturing and charting magnetometer data is just one of the great things you can do with Bitty Data Logger. Magnetometers need constant love and attention though, if you like your magnetometer data to be accurate. Accurate data can only be obtained if you calibrate the compass in the environment you intend to use it in. On the micro:bit, the calibration procedure involves you responding to a "DRAW A CIRCLE" prompt which appears on the LED display by rotation the micro:bit in space, causing an LED light to be lit all the way around the edge of the display. Once you've lit all the edge LEDs, a smiley face appears, indicating that the calibration procedure has completed.

You can now trigger the magnetometer calibration procedure over Bluetooth from within the Bitty Data Logger settings screen. You need to be running a suitable hex file on your micro:bit of course, but luckily there's just what you need available for download from

Oh and Bitty Data Logger is no longer free of charge. Sorry about that. See the previous blog post on Bitty Controller for the reasons behind this.

Monday, 24 July 2017

Hello Bitty Controller. Goodbye Bitty Game Controller!

Bitty Game Controller is an application from my friends at Bitty Software that lets you remote control something like a Kitronik buggy from your smartphone. In fact you could use it to control anything connected to a micro:bit, provided the micro:bit is running the right code.

However, Bitty Game Controller has been withdrawn from the Google Play store and will soon also be withdrawn from the Apple App store.

Don't despair though! A rather similar application called Bitty Controller has taken its place. Bitty Controller offers a choice of the old dual d-pad game controller user interface or a new, analog touchpad controller and in the future, other UIs will be added to the application too. The point is, some types of micro:bit connected machine, are best controlled by one type of UI like the game controller, whilst others are better suited to something else. So Bitty Controller will offer a collection of controller user interfaces so that it is suitable for use with a wide range of micro:bit projects.

Bitty Game Controller was free of charge. Bitty Controller is not. It now costs GBP 1.99 in the UK, or something equivalent in other parts of the world. Why is Bitty Controller not free of charge?

Bitty Software has various costs associated with it, from web hosting and domain names, to developer accounts with Google and Apple and test equipment. Various companies are also selling commercial products, with Bitty Controller bundled with them. It's no longer possible to offer this application free of charge, therefore and so a small, fee is now payable. Bitty Software hope people understand and continue to find their applications useful and fun. On that basis, Bitty Software will be able to continue to offer smartphone applications for lovers of the BBC micro:bit.

Dual D-Pad controller interface

Analog touchpad interface - push the ball to set direction of movement

See for further details.

Tuesday, 27 June 2017

Bluetooth 5 and PHY Flexibility

Bluetooth 5 introduced two new PHYs. PHY? That's the PHYsical layer in the Bluetooth protocol stack, the bit which deals with the world of radio and the encoding of digital data in an analogue form.

In Bluetooth 4, there was only one PHY. It encoded digital data using Guassian Frequency Shift Keying (GFSK) and transmitted it at a rate of 1 mega symbol per second (ms/s).

Bluetooth 5 continues to support the Bluetooth 4 PHY and calls it LE1M. But it also added a 2 ms/s PHY called LE2M, which doubles the transmission rate at the physical layer and a long range capability, achieved when using the LE Coded PHY which uses Forward Error Correction (FEC) to allow receivers to be more sensitive, extract data from signals at a lower Signal to Noise Ration (SNR) and therefore at a greater distance from the transmitter. Cool.

But ......

1. How flexible is this?
2. Can application developers choose the PHY to be used?
3. And in an environment like a smartphone, with multiple applications running, would one application setting the PHY change it for all other applications?

Luckily the answers to these questions are:

1. Very
2. Yes if their platform provides APIs (because yes, the Bluetooth stack allows this)
3. No it would not.

To elaborate on (3):

You can set a default PHYs to be used in all subsequent connections or connectionless communication events for each of received packets (RX), transmitted packets (TX) or both.

However you can also use a different PHY for each and every packet if you really want to. That's pretty flexible!

When in a connection with another device, the Bluetooth stack lets you use the Host Controller Interface (HCI) Set PHY Command to set the PHY for your connection and you may specify a different PHY for TX and RX use on this connection.

Bluetooth 5 lets you define distinct "advertising sets" which are separate sets of advertising parameters for different applications. So in connectionless scenarios (i.e. advertising and scanning), you can specify the PHY as part of the definition of a particular advertising set. You use the HCI LE Set Extended Advertising Parameters Command to select the PHY to use when advertising and use LE Set Extended Scan Parameters Command to control scanning and the PHY or PHYs to use when handling received advertising packets.

Of course this doesn’t necessarily mean that operating systems like Android give you complete access to all of this. But we're in seems that Android O does in fact does give you pretty much everything. In summary, here's my interpretation of the revised Android O APIs which give access to Bluetooth 5 capabilities:

1. Android lets you determine which PHYs the local Bluetooth adapter supports.

2. A GATT server application can specify preferred PHYs for each of TX and RX (class: BluetoothGattServer)

3. A GATT client application can specify preferred PHYs for each of TX and RX (class: BluetoothGatt)

4. When scanning you can specify the PHY(s) to use, including “all supported PHYs” (class ScanSettings.Builder)

5. When advertising you can build advertising parameter sets, each with its own primary and secondary PHY (AdvertisingSetParameters.Builder)

Bluetooth 5 offers enormous, packet by packet flexibility and control over PHY selection and it looks like Android APIs put this power right into the hands of the developer.


Sunday, 23 April 2017

Bitty Data Logger 2.3

A new release of Bitty Data Logger from Bitty Software is now available for both Android and iOS. Check Google Play and the Apple App Store for the update.

This release aims to streamline the process of using the app for Bloodhound Race for the Line competition participants (see Key data may now be uploaded direct to the Bloodhound leader board after data has been collected.

Changes in this release are:

1. Data logging projects may now be designated as type 'Bloodhound Race for the Line' or 'Other'

2. Results from Bloodhound projects (rocket car races) may be uploaded directly to the Bloodhound Leader Board

3. Minimum and maximum acceleration in X, Y and Z directions are now recorded in results

4. Certain types of data in results may now be edited to correct mistakes prior to upload or posting to the Bloodhound Leader Board

It is recommended that you uninstall Bitty Data Logger and then install the new release from the application store.

That's it


Thursday, 20 April 2017

Making the micro:bit accelerometer available over Bluetooth

Here's a very simple C/C++ application, created using the mbed web IDE.

The project was created in the mbed IDE with the following parameters:

Platform="BBC micro:bit", Template="An example of how to use the micro:bit DAL's abstract....." and Project Name=-"microbit-ble-accelerometer"

All it does is establish event handlers for Bluetooth connect and disconnect events and adds the Bluetooth accelerometer service so that an application like micro:bit Blue or Bitty Data Logger can receive accelerometer data over Bluetooth.

#include "MicroBit.h"

MicroBit uBit;

void onConnected(MicroBitEvent)

void onDisconnected(MicroBitEvent)

int main()
    // Initialise the micro:bit runtime.

    // Insert your code here!
    uBit.messageBus.listen(MICROBIT_ID_BLE, MICROBIT_BLE_EVT_CONNECTED, onConnected);
    uBit.messageBus.listen(MICROBIT_ID_BLE, MICROBIT_BLE_EVT_DISCONNECTED, onDisconnected);

    new MicroBitAccelerometerService(*uBit.ble, uBit.accelerometer);

    // If main exits, there may still be other fibers running or registered event handlers etc.
    // Simply release this fiber, which will mean we enter the scheduler. Worse case, we then
    // sit in the idle task forever, in a power efficient sleep.

I also set MICROBIT_BLE_OPEN to 1 in microbit-dal/inc/core/MicroBitConfig.h so that pairing is not required. Much easier for testing purposes.

#define MICROBIT_BLE_OPEN                       1

After compiling to produce a hex file, copy the hex file onto your micro:bit. An application like nRF Connect on a smartphone or tablet should see a Bluetooth service with UUID which starts 0xe95d0753-. This is the accelerometer service. Enabling notifications on the first characteristic (Accelerometer Data) will result in its value updating when you move the micro:bit.

The project has been published here:

Tuesday, 7 February 2017

Pairing a BBC micro:bit with a Raspberry Pi using BlueZ

A Raspberry Pi 3 has Bluetooth low energy built in and a Raspberry Pi 2 can have a Bluetooth USB dongle plugged into it to give it Bluetooth capabilities. BlueZ, the Bluetooth stack for Linux needs then to be installed. Once done, you have a Bluetooth enabled Raspberry Pi.

But what about your BBC micro:bit? Well, the easiest way to use your Pi with your micro:bit is to install a hex file whose settings do not require it to be paired to another device before it can be used. PXT lets you pick whether or not pairing is required and if so, whether you want to use "passkey pairing", where you enter a 6 digit number displayed by the micro:bit or "just works" pairing, where all you need to do is initiate the pairing process, and the rest happens by magic.

If you opt to use passkey pairing, it's possible to have BlueZ pair your micro:bit with your raspberry Pi. After that, any communication with the micro:bit from the Pi will use that pairing information and where necessary, data will be encrypted.

Here's an example of me pairing my Raspberry Pi with my micro:bit using BlueZ from a Linux terminal session:

pi@raspberrypi:~ $ sudo hciconfig hci0 down
pi@raspberrypi:~ $ sudo hciconfig hci0 up
pi@raspberrypi:~ $ sudo bluetoothctl
[NEW] Controller B8:27:EB:C5:E9:31 raspberrypi [default]
[NEW] Device D0:F5:DF:C0:AE:95 BBC micro:bit
[NEW] Device 90:03:B7:C9:9C:D8 Flower power 9CD8
[bluetooth]# scan on
Discovery started
[CHG] Controller B8:27:EB:C5:E9:31 Discovering: yes
[CHG] Device D0:F5:DF:C0:AE:95 RSSI: -61
[CHG] Device D0:F5:DF:C0:AE:95 Name: BBC micro:bit [vuzig]
[CHG] Device D0:F5:DF:C0:AE:95 Alias: BBC micro:bit [vuzig]
[CHG] Device 90:03:B7:C9:9C:D8 RSSI: -80
[bluetooth]# paired-devices
Device D0:F5:DF:C0:AE:95 BBC micro:bit [vuzig]
[bluetooth]# remove D0:F5:DF:C0:AE:95
[DEL] Device D0:F5:DF:C0:AE:95 BBC micro:bit [vuzig]
Device has been removed
[bluetooth]# agent KeyboardDisplay
Agent registered
[NEW] Device D0:F5:DF:C0:AE:95 BBC micro:bit [vuzig]
[CHG] Device 90:03:B7:C9:9C:D8 RSSI: -89
[bluetooth]# pair D0:F5:DF:C0:AE:95
Attempting to pair with D0:F5:DF:C0:AE:95
[CHG] Device D0:F5:DF:C0:AE:95 Connected: yes
Request passkey
[CHG] Device D0:F5:DF:C0:AE:95 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
[CHG] Device D0:F5:DF:C0:AE:95 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
[CHG] Device D0:F5:DF:C0:AE:95 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
[CHG] Device D0:F5:DF:C0:AE:95 UUIDs: e95d93af-251d-470a-a062-fa1922dfa9a8
[CHG] Device D0:F5:DF:C0:AE:95 UUIDs: e95d93b0-251d-470a-a062-fa1922dfa9a8
[CHG] Device D0:F5:DF:C0:AE:95 Appearance: 0x0200
[agent] Enter passkey (number in 0-999999): 959145
[CHG] Device D0:F5:DF:C0:AE:95 Paired: yes
Pairing successful
[CHG] Device D0:F5:DF:C0:AE:95 Connected: no

I've highlighted the text I entered in red. Initially, I brought the Bluetooth adapter's HCI (Host Controller Interface) down then up. This is a handy way to reset it and in my experience, this is sometimes necessary.

I then put my micro:bit into pairing mode.

Having done so, I launched "bluetoothctl", a utility that lets me enter various commands.

Once started, I ran "scan on" to start BlueZ scanning for other devices, and as you can see, it lists the Bluetooth devices that it finds, including a micro:bit.

I then ran "paired-devices" to see what devices my Pi was already paired with. It listed my micro:bit so to start with I removed that pairing. You should always do this if you've installed a new hex file on the micro:bit since this will have caused any previous pairing information to be lost from the micro:bit and the micro:bit and the device it is paired with must both have the same pairing information.

Then I specified "agent KeyboardDisplay". This tell the BlueZ to inform other devices that it is a device with both a keyboard and a display, during the pairing process. The point here is that during pairing, the two devices exchange information about each other's IO capabilities and this is used to determine what the best way to go about pairing might be. If neither device had a keyboard, for example, there would be no point trying to perform passkey pairing.

After that, I initiate pairing with the MAC address of my micro:bit as an argument. Pairing proceeds and the micro:bit display responds with an arrow on its display, pointing at button A. I pressed button A and was prompted on the Pi to enter the passkey displayed on the micro:bit.

And that's all there is to it. There's even less to do if you load a hex file configured for "just works" pairing.