Wednesday, 21 December 2016

Bitty Software and Preparing Youngsters for the Age of the IoT

Bitty Software is the name I use for my micro:bit smartphone/tablet applications project. At the time of writing, there are 5 Bitty Software applications for each of iOS and Android in their respective app stores. In each case, micro:bit coding tutorials are available, the idea being that to use the smartphone applications, you have to program your micro:bit. For those who don't want to, or who are simply too impatient to get started, pre-built hex files are also available.

The idea behind Bitty Software was to create resources for education and fun which shine a light on communications technology and the micro:bit rather than just on coding. Bluetooth is of course my communications technology of choice.

Why emphasise communications? Well, given one of the primary goals of the micro:bit project is to educate youngsters in coding and making things and to prepare them for potentially becoming the next generation of technology entrepreneurs and leaders (or simply to make a living from their technical skills), communication between devices is an essential thing to know about, and here's why.

Goldman Sachs released a report in 2014 which discussed the Internet of Things (IoT). In that report, they characterised the internet as evolving through three major phases.

1. The 1990s. 1 billion devices are connected to the internet. These are largely desktop computers and servers. People use modems that make a quaint bleeping sound.

2. The 2000s. 2 billion devices are connected to the internet. This is the age of the smartphone.

3. The year 2020. It's forecast that by 2020 there will be <drum roll> 28 billion devices connected to the internet. This is a phenomenal figure. And those devices? Computers, smartphone and tablets. Obviously. But also light bulbs, manufacturing equipment, sensors of every conceivable type and much more besides.

The IoT is why youngsters need to be educated in communications as well as coding. At the "edge tier" of any IoT architecture, you'll generally find smaller devices, often equipped with microcontroller units (MCUs). The BBC micro:bit is an MCU. And they will very typically communicate wirelessly with each other and with the internet via entities known as "gateways".

There are various wireless technologies. Some of them are categorised as "low power wireless technologies" meaning that they use relatively small amounts of power to communicate data. Bluetooth low energy is one example and this is the Bluetooth technology on the micro:bit. Low power use is critical in many IoT scenarios. Consider a smart building. It can only be "smart" in any meaningful sense of the word if we have lots of data about its various aspects and from every nook and cranny of the building, let alone every room; temperature, light levels, water levels, security status of windows and doors, occupancy of rooms and so on. Data can be accrued, aggregated and analysed. It can form the basis of intelligent automation and reveal hitherto unknown things about the building (is this building energy efficient compared to other, similar buildings?) but this can only be achieved with the right type and quantity of data, acquired at the right time.

To obtain this magical data requires sensors. Lots of sensors. Everywhere. Placing sensors in wall spaces, attics and under the ground becomes untenable if they need their batteries changing every few weeks. Devices have to run for many years on a single battery or better still, require so little power that energy harvesting techniques which generate power from ambient light, temperature changes, mechanical vibration or naturally occurring radio in the environment, can be used instead of batteries.

Its ubiquity (over 3 billion Bluetooth devices shipped in 2015 alone), wide platform support, developer friendliness and very low power requirements have made Bluetooth the low power communications technology of choice for the IoT.

So those youngsters we have such high hopes for, they need to be immersed in communications as well as coding and learn about creating systems of devices, not just creating the code for one device.

Bitty Software and Bluetooth. Doing their bit. OK, I nearly finished on a pun there!

Wednesday, 16 November 2016

micro:bit support

The 'micro:bit foundation' has arrived and is charged with looking after the future of the micro:bit. It's also a great place to go for technical support. We've lacked a central place to find answers to questions or to get assistance until now, so this is a big step forwards.

Here are some handy support resources for you:

1. If you need help with a Bitty Software application or tutorial

Send a message to @bittysoftware on Twitter. If you can, post more extensive details on a blog or similar and include a link to these details in your tweet.

2. Anything else micro:bit related

Email or go to and open a support ticket.

That's it!

Tuesday, 15 November 2016

micro:bit Blue - open source at last!

Most of the micro:bit demos involving a smartphone shown on my micro:bit page involve an Android application I wrote and which I eventually decided to call "micro:bit Blue". It was initially put together to help me to test the Bluetooth profile I'd designed for the micro:bit. Then, as I started to have ideas, it transformed into a series of demos.

But I always had the aim that it be released as open source, so I also did my best to provide educational documentation in the helps screens so that people who are new to Bluetooth could get the hang of the primary concepts.

A few months ago I loaded the application into Google Play so that other people could find and install it easily.

 It's right here:

Meanwhile, releasing the source code was delayed by a variety of rather uninteresting issues. And then some more. To cut a long story short and at the same time apologise for having taken so long over this, today I'm delighted to say that the source code is now available!

The new microbit foundation have kindly offered a home for the code and their home being more palatial than my own github home, I gratefully accepted their offer.

I hope those people who have been waiting for this are pleased and that everyone and anyone with an interest in writing smartphone apps for the micro:bit finds this useful.

Here it is:

 Enjoy :-)

Thursday, 10 November 2016

Bitty Data Logger V1.2.0

Yesterday, Bitty Software released a new version of the Bitty Data Logger application. If you're unfamiliar with the app, check it out at the Bitty Software web site.

The new release makes the following improvements:

  1. A new "Results" screen lists up to 30 data files.
  2. Data can now be uploaded at any time.
  3. New "Extra Data" screen provides the opportunity to add a time and distance value after a test run has completed. A speed value is automatically calculated.
  4. The Activate / Deactivate button is now named Start / Stop and is coloured green and red.
  5. The Settings screen now allows a Project Name and a Team Name to be entered.
Bitty Data Logger is currently being evaluated for use in the Bloodhound model rocket car competition for schools, Race for the Line. This is of course, *very* exciting!
Bitty Data Logger is free and available for both iOS and Android. The code needed for the micro:bit is available as a hex file from the Bitty Software web site or you can create it yourself, with guidance available in the form of a couple of coding tutorials, one for C/C++ and one for the PXT tool.

The application is great for school or personal projects:
Spice up your science lessons with the @bittysoftware #microbit data logging app for Android & iOS: #edchat

Here are some screenshots of the new release. 

Ready to start data logging!

And we're off....

After capturing data we can record extra, optional data

Up to 30 data files are kept. NEW files have not yet been uploaded
After uploading, you can download to your computer from the URL provided

Data file details include the URL which was allocated when uploading

Tuesday, 1 November 2016

micro:bit proximity beacons

One the big growth areas for Bluetooth is in "beacons". Bluetooth beacons broadcast data which can be used by another device to deduce roughly where it is. This can be in terms of a particular location or perhaps in terms of proximity to an object of interest.

ABI predict that by 2020, there will be 400 million Bluetooth beacons shipping each year.

Beacons work by using Bluetooth "advertising" to broadcast a small amount of data, which can be received and acted upon by anyone in range with a suitable device and software, typically a smartphone and application.

There are various beacon message formats, which define the way Bluetooth advertising packets are used as containers for beacon data. iBeacon is Apple's beacon message format. Eddystone comes from Google.

Google have a very interesting project called the Physical Web and it in large part, is all about how Bluetooth beacon technology, coupled with software on smartphones and tablets, coupled with the web, can enable people to more easily discover and interact with physical things in the environment.

Believe me. This is going to be BIG.

I just helped add Eddystone beacon capabilities to the BBC micro:bit. Kudos to Thomas Beverly for having kicked things off by implementing support for Eddystone URL messages in the micro:bit's "runtime". I tagged along for the ride and added support for UID messages over the weekend and it's now pretty easy to use a micro:bit for a wide range of beacon scenarios.

I have a couple of videos on my Bitty Software web site. The first shows the UID Eddystone message type in use and the second uses the URL message type. Take a look at them now to get the idea, especially if you're not already familiar with beacons.

Don't forget, you don't need to make a Bluetooth connection to a beacon to use it... you just have to be near enough to it to receive its broadcast data and as I've noted elsewhere in this blog, micro:bits can have a range of hundreds of metres when using Bluetooth at full power. 

So you could place micro:bit beacons all over (say) your school, and with a suitable application on phones and tablets, provide information pertinent to each location or some other response, automatically on someone simply coming into range of the micro:bit's beacon broadcasts.

Right now, turning your micro:bit into a beacon requires you to do some C/C++ programming. I'm hoping though that Microsoft's awesome PXT tool will end up with a "Bluetooth Beacon Block" in the future so that making micro:bit beacons is as easy as can be.

The microbit-samples repo will soon have Eddystone beacon code examples in it and I've also submitted updates to the Lancaster University micro:bit documentation on the subject.

Meanwhile, to whet your appetite, here's some code:

#include "MicroBit.h"

MicroBit uBit;

char URL[] = "";
const int8_t CALIBRATED_POWERS[] = {-49, -37, -33, -28, -25, -20, -15, -10};

uint8_t advertising = 0;
uint8_t tx_power_level = 6;

void startAdvertising() {
    uBit.bleManager.advertiseEddystoneUrl(URL, CALIBRATED_POWERS[tx_power_level-1], false);
    advertising = 1;

Saturday, 29 October 2016

Bitty Software

Bitty Software is a relatively new endeavour which concentrates on smartphone apps for use with the BBC micro:bit and offers free coding tutorials where you can learn to write the micro:bit code which is needed to make a micro:bit work with one of the Bitty Software apps. Tutorials are available for both C/C++ developers and those who prefer a visual programming language. In the latter case, Microsoft's excellent PXT is used.

The ethos behind Bitty Software is that in this emerging age of IoT, learning to code is just one dimension of the technology journey which youngsters need to take; learning about connectivity and communications is essential too. Hence the focus on systems which involve one or more micro:bits, a smartphone or tablet and in the middle, enabling the whole thing to work, Bluetooth.

Despite being such a relatively new concern, the Bitty Software web site is rapidly accruing a really useful collection of micro:bit programming resources, including some great videos.

Take a look.... the bitty data logger application demo and the micro:bit Eddystone beacon demos are particular favourites.

Bitty Software already have 4 applications for micro:bit, all of which are available for both iOS and Android. There are more in the pipeline. Watch this space!

Bitty Data Logger and a Speeding Vehicle

I thought it would be interesting to see how well the new Bitty Software application Bitty Data Logger would handle capturing accelerometer data from a micro:bit attached to a moving vehicle. So.... that's what I set out to discover.

The first challenge was how to attach a micro:bit to my car! I'm no structural engineer. As you'll see. But with some good sticky tape, some glue, some rolled up cardboard and of course a piece of Lego, anything's possible :-)

There were some practical issues associated with planning this project. One person would need to drive and another hold the smartphone and operate the app whilst standing at the side of the road. I'd need a suitable stretch of road where I could drive fairly fast without breaking the law or having a horrible accident. And of course "smartphone operator" and driver would need to be able to communicate so that the driver would know when the app was connected to the micro:bit and data capture activated in the the bitty data logger app.

My long suffering wife got the job of smartphone operator, with me behind the wheel of my car. We'd devised a system of hand signals she could use to indicate she was ready and I could start driving (none of which were rude!) and I dropped her at a suitable point on a local A road, drove to the end of the road and came back around the roundabout ready to drive past her. I awaited her signal as she scanned for and connected to the micro:bit mounted on my car's wing mirror and activated data logging.

When the signal came, I immediately put my foot down and accelerated up the road in her direction. For about 2 seconds. I immediately got stuck behind another car. Yes, there was a lot of traffic about, and I did wonder what effect all those large metallic objects might have on Bluetooth radio communications.

I pulled out past the slower vehicle and put my foot down again. About 2 seconds later I was at 60mph and held that speed until the next set of traffic lights forced me to decelerate.

Don't worry - this was taken by my passenger before we started data logging!

Had the experiment worked? Had we captured any data?

Happily the answer was a big yes! The plan had been for my wife to start capturing data when I was at the roundabout about 50 metres away and driving towards her and then deactivate when I was an estimated 100 metres past her. It looks like everything worked a treat. Here's the resultant data in chart form with a manually drawn trend line which shows broadly how things panned out.

Y axis - forward acceleration

Note that this data is completely raw. The micro:bit accelerometer generates data that is somewhat "rough" and it's best used by applying a low pass filter to it to smooth out its roughness. Maybe a later release of Bitty Data Logger will give you the option to have it do this for you.

I was predominantly interested in the Y axis which represents forward motion, given how I'd mounted the micro:bit on my car, but just for good measure, here's the X (sideways) and Z (up and down) data:

X axis - sideways acceleration
My guess is, the sudden deceleration and then acceleration shown near the start of the chart correspond to me having to pull out and overtake the car that was blocking my way. After that, the general trend shows constant x axis acceleration, averaging around 0.

Z axis - up and down acceleration
The Z axis just shows vibration and general bumpiness I think!

I think I can declare today's little experiment a success!

Friday, 19 August 2016

How to switch off the need to pair your micro:bit when using Bluetooth

Pairing is the bedrock of all Bluetooth security. If you pair your micro:bit with your phone, for example, from that point on, only you can connect to and interact with your micro:bit. Imagine you were using your phone with my micro:bit Blue application to drive a  micro:bit controlled Kitronik buggy. You wouldn't want someone else connecting to it and driving it away, would you?

But not all applications need security. And pairing definitely impacts user experience. Furthermore, currently, whenever you flash a new hex file to your micro:bit, the pairing data gets wiped off your micro:bit so you have to 'forget' the pairing details on your phone and go through the entire pairing process again. Not great when you're performing develop/test cycles frequently.

Note: some changes are planned in this area. USB firmware is to be changed so that data on micro:bit, including pairing keys, will persist when new hex files are flashed. I'm also aiming to have a Block in Microsoft's PXT that lets you choose whether you want pairing or not and if you do, whether it should be based on the passkey system or Bluetooth's "Just Works" method. Watch this space for updates on both these developments.

If you're a micro:bit C/C++ developer, you can get under the hood in ways in which users of other tools often cannot. And this includes the ability to create a hex file which will result in your micro:bit not needing to be paired. Here's how.

In your project folder's root, you should have a file called config.json. All you need to do is ensure there's a property of the bluetooth json object called 'open' which has a value of 1. open=1 means 'no security'. Here's the first part of my config.json file:

    "microbit-dal": {
        "bluetooth": {
            "enabled": 1,
            "pairing_mode": 1,
            "open": 0,
            "dfu_service": 0,
            "event_service": 0,
            "device_info_service": 1
        "gatt_table_size": "0x700"

And that's it! Run 'yt clean' followed by 'yt build' and the resultant hex file will remove the need for your microbit to be paired when using Bluetooth.

Even with applications that need security, this is useful. You can do development and test cycles with pairing switched off, and enable it when you come to do your final testing and release build. The best of both worlds.

Use responsibly! :-)

Code it. Connect it. Bitty Software.

Saturday, 6 August 2016

micro:bit and Bluetooth range testing #2

How far can a BBC micro:bit transmit data using Bluetooth? I still don't know.

Yesterday, I went to a larger local park, primarily because there might be more Pokemon there but also because it would give the opportunity to perform another micro:bit Bluetooth range test.

Once again though I ran out of park.

This time I got to...... <drum roll>........

354 metres and my phone was still receiving data!


I stopped when I would have had to turn a corner and go out of line of sight from the micro:bit, held once again by my Trusty Assistant. To be clear.... Bluetooth does not require line of sight. Radio signals pass through objects including walls. But for optimum conditions, line of sight is best and optimum conditions is what you want when investigating maximum range.

I had started to notice that I wasn't getting all data that was being transmitted. Bluetooth accelerometer data was being transmitted by the micro:bit regularly but I could tell from my phone, not all were arriving. So 354 metres is probably close to the maximum range. That said, I walked slightly down hill and then up hill so line of sight to the micro:bit was almost at floor level and there were quite a few people using the path in between me and the micro:bit as well. So I think a bit more range can be squeezed out of the micro:bit in ideal conditions. I'll certainly test again to see if I can find that so far illusive limit.

and just for good measure, here's what I could see of Trusty Assistant at the end of the path 354 metres from me.

Yes, 354 metres is a long way!
More importantly, I caught a couple of Haunters and a few Ghastlys!

The hunt for Pokemon and micro:bit Bluetooth maximum range continues ......

Friday, 5 August 2016

micro:bit and Bluetooth range testing

How far can a BBC micro:bit transmit data using Bluetooth? I don't know. But I intend to find out.

A couple of days ago I was testing code I'd written for a Kitronik buggy which allows me to control it from my Android phone over Bluetooth and took the buggy for a spin on a local road. The changes I'd made to this release of the micro:bit code included the ability to drive in reverse and the automatic stopping of both motors if the Bluetooth connection between the smartphone and micro:bit was lost, for example if the buggy went out of range. I know that the range which Bluetooth can achieve is way further than most people think but ultimately it depends on many factors and will vary considerably from product to product so I didn't know what to expect with the BBC micro:bit.

I set to driving the buggy away from me, steering with my phone. At about 40 metres I couldn't really see the buggy very well anymore and didn't want to cause a horrible accident so I threw it into reverse and brought it back to me. I paced to the spot where I'd abandoned to verify the distance which was just under 40 of my long, approx 1 metre strides. Very scientific, I know!

Spot the buggy. It's there if you look carefully and not yet out of Bluetooth range!
A good test of my new reversing functionality but the question of the micro:bit's maximum Bluetooth range had still not been answered.

Last night my wife and I went for a walk up to our local park. The primary objective and reason for our walk was of course to hunt for Pokemon. The secondary objective was to perform another range test on the sports field in the park. Or was it the other way around? No matter :-)

The sports field is pretty big, plenty big enough for this test. This time I didn't use the buggy. It doesn't drive on grass. So instead I used my micro:bit Blue application and the micro:bit accelerometer. I set the micro:bit to transmit accelerometer data every 640ms (polling frequency set by writing to the Accelerometer Period characteristic) and walked over to one side of the sports field with my wife, or "Trusty Assistant" as I shall now refer to her. Trusty assistant was asked to stand still, holding the micro:bit by the edge connector and to avoid covering the Bluetooth antenna on the other edge. I fired up micro:bit Blue and went into the Accelerometer screen which looks like this (screenshot taken the day after the test):

See my micro:bit Bluetooth capabilities video to see this screen in action by the way.

With Trusty Assistant in position, I started my GPS Sports Watch so I could get it to measure distance for me and proceeded to pace away towards the opposite side of the field, holding my phone so I could see the screen but to the side of my body so it had line of sight to the micro:bit. I used my approx. 1 metre long paces and counted.

At 50 paces I was still receiving accelerometer data, which didn't surprise me.

At 75 paces I was still receiving data. Still not enormously surprised but definitely feeling pleased.

At 100 paces I was pleased and perhaps a little surprised and beginning to wonder if Trusty Assistant's patience might be beginning to wear out! I was also getting funny looks from other people in the park. Not surprising really, given the silly way I was walking. One woman, with her daughter even asked me "What are you doing?!" with a concerned look on her face. "I'm attempting to measure the maximum distance a BBC micro:bit can transmit data using...." (trailing off as I realise what a geek/crazy person I sound like!)  ".....errrr ... Bluetooth". The woman and her daughter noticeably quickened their pace at this point and sped off into the distance without looking back!

I'll cut this short.

At 200 paces I was still receiving data! At that point I was noticed by a bunch of approximately 13 year old girls. "Are you catching Pokemon, mate?!" one asked. "No, actually I'm attempting to...... errrr yes! That's right, I'm catching Pokemon!". I think I got away with it :-)

At more than 200 paces I ran out of park. It becomes woodland at that point and I wanted line of sight for optimum conditions so I stopped. I was still receiving data though.

GPS indicated I'd walked 0.14 miles or 225 metres and I was still receiving data. 

GPS data from my test. 0.14 miles - 225 metres!
The maximum range has therefore not yet been established and I'll return to this another day. But wow, what a result!

Surprised? Amazed? Pretty cool, huh?!

My Trusty Assistant deserves a special commendation for her patience. Here's a photo of her, taken at the 225 metre mark where I'd decided to give up the test.

Yep, 225 metres is a long way. She's over by the tree-line, honest!
When Bluetooth 5 comes along it will quadruple the maximum range by the way!

Oh and as to the primary objective.... amongst other things I did catch a Machop :-)

Technical footnote: The transmission power is one variable in the range which can be achieved. On a BBC micro:bit this can actually be controlled from software. There's a build variable in config.json called "tx_power" which takes a value of 0 (lowest power) to 7 (highest power). A default build produced using one of the editors at has tx_power set to 0 (a BBC decision) so you won't get the same range I achieved. A build created using Microsoft's PXT has it set to 6. If you use mbed or Yotta to code in C/C++ you can set it yourself though and of course I had it set to 7.

Code it. Connect it. Bitty Software.

Friday, 29 July 2016

Sending 'commands' from a micro:bit over Bluetooth

I got asked how you might use Bluetooth to send 'commands' from a micro:bit to another Bluetooth enabled device.

First read my blog on what kind of Bluetooth device can 'talk' to what kind of other device.

micro:bit has the concept of "events" which are things we can use as though they are numeric commands. An event has an ID and a value. Each are 16 bits in length so an event is a total of 32 bits long.

The micro:bit has something called the Event Service and this allows events to flow in either direction between the micro:bit and something else like a smartphone.

The Microsoft PXT tool lets you create your own event values and trigger them from anything you like in your code.

So these are our basic ingredients.

Let's walk through an example.

First, check out this application I created in PXT

You can fork the code itself here:

You can see I create an event ID of 9010 and two associated event values of 1 and 2. I also keep track of whether or not we have a Bluetooth connection in a variable called 'connected'

Then, if the user presses button A we create an event with ID 9010 and event value 01. If the user presses button B we create an event with ID 9010 and event value 02.

That's all we need to do on the micro:bit side of things.

On the other device we have to send the micro:bit the event ID and values we're interested in being notified about if they occur.

Here's what the micro:bit Bluetooth Event Service looks like. It will help when we look at how to test this code from a smartphone next.

The blobs are called "characteristics" and they're like data items or variables that have particular purposes. Client Requirements contains a list of one or more event IDs and event values that the client (i.e. the other device) has said it's interested in. MicroBit Event contains the event ID and value of the most recent event that has happened on the micro:bit.

There's a great smartphone app for Android and iOS that lets you explore and test Bluetooth communication called nRF Connect. I'll walk through how I tested my PXT code using screenshots to illustrate:

Note: I've paired my micro:bit and phone. This is essential as at the time of writing both PXT and the tools produce code which requires your micro:bit to be paired if you're going to use Bluetooth. Here's how to pair with an iOS device and here's how to pair with Android.

There's nRF Connect on my Android phone. I launch it and it automatically scans for advertising Bluetooth devices and finds my micro:bit.

I click CONNECT to have the phone connect to the micro:bit.This gives me the next screen which shows the Bluetooth services on the micro:bit. Most were custom designed for the micro:bit so nRF Connect does not know their names.

The UUIDs are unique identifiers. The highlighted one is the event service. You can see the UUID shown here is the same as the one in the Event Service graphic above. Selecting the service causes it to expand so we can see its characteristics:

The two we're interested in are highlighted in green. 9775 is the MicroBit Event characteristic. 23C4 is the Client Requirements characteristic. The next job is to write to the Client Requirements characteristic using nRF Connect. This will transmit the value we enter to the micro:bit, effectively saying "Hey, if one of these events happens, please tell me". You start a Write operation by selecting the upwards pointing arrow icon next to the characteristic and this causes a dialogue to appear:

The second field is a drop down data type selector. I have it set to BYTE ARRAY. The value is in hex and needs some explanation. The first two bytes are the event ID of 9010. The second is the event value but 0000 means "any event values with the specified event ID". 9010 is not 0x3223 in hex though, it's 0x2332! micro:bit, in common with many other devices likes its data to arrive or be sent over comms links in 'little endian format'. So the least significant bytes come first as we read left to right and this is why we're sending 0x3223.

Now that the micro:bit knows what we're interested in, we also have to switch on "notifications" relating to the MicroBit Event characteristic. This just tells Bluetooth on the micro:bit to send the phone a message if its value changes. And it will change if one of the events we just said we were interested in happens.

Notifications are enabled by selecting the icon with multiple downward pointing arrows next to the MicroBit Event characteristic as shown.

All that's left now is to test! Pressing first button A and then button B causes the value of the MicroBit Event characteristic to change as the data is received over Bluetooth from the micro:bit. Your own code on a phone or other Central mode Bluetooth device could respond to these events anyway you choose.

That's the result of pressing Button A. Event ID 0x3234 (9010) and Event Value 0x0100 which of course is ID 9010 and value 01 in little endian format.

And button B produces....

the same result but this time the value is 02.


Code it. Connect it. Bitty Software.

micro:bit and Bluetooth 'roles'

Bluetooth devices will play one of 4 possible Bluetooth roles as defined by that masterpiece, the Bluetooth core specification. The four roles are called
  1. Peripheral
  2. Central
  3. Broadcaster
  4. Observer
These terms are part of "GAP", the Generic Access Profile, which is a part of the Bluetooth architecture.

A Peripheral advertises, inviting and (perhaps) accepting connections from Central devices. 'Advertising' means transmitting small amounts of data, quite frequently, which other Bluetooth devices can receive and act upon if they think the advertising device is of interest.

A Central device scans, looking for advertising packets and based on their content, may decide to connect to a device it thinks is suitable.

A Broadcaster is like a peripheral in that it advertises but it does not accept connections. It's sole purpose is to advertise.

An Observer scans and processes advertising packets but never tries to connect to another device.


The BBC micro:bit is a Peripheral.

A smartphone is typically a Central but some newer devices can also act as Peripherals with the right application software running.

A Bluetooth beacon (iBeacon, AltBeacon, EddyStone and so on) is a Broadcaster.

A beacon application on a smartphone which alerts you to special offers broadcast by beacons for example, is an Observer.

A Peripheral cannot create connections, only accept them. Therefore a Peripheral cannot connect to another Peripheral. A Peripheral cannot scan for advertising packets from other devices, only transmit them. Therefore two Peripherals cannot interact using advertising data only.

The outcome of this is that one micro:bit cannot talk to another micro:bit *directly* using Bluetooth. You'd need a Central mode device acting as a hub and relaying messages between micro:bits.  My Heart Rate Monitor video shows a smartphone acting as a Central hub which is connected to two Peripherals, a BBC micro:bit and a heart rate monitor.

Technically, a device like the BBC micro:bit could have the ability to be either (or both) a Peripheral and a Central but there's just not enough memory available on the micro:bit to squeeze the larger Bluetooth stack that would be required to support both GAP roles. Maybe as and when there's a 32K micro:bit (complete conjecture / wishful thinking!) this will happen.

That's it. An introduction to Bluetooth GAP roles and their relevance to BBC micro:bit. Amaze your friends at your next dinner party ;-)

Code it. Connect it. Bitty Software.

Implementing a Buggy controller using Microsoft's PXT tool

Ages ago I wrote the code needed to control a Kitronix buggy with a micro:bit which is itself being sent commands over Bluetooth from my microbit Blue Android application. You can see it and the C/C++ code here.

Microsoft released their amazing PXT tool fairly recently. It's fantastically flexible and you can fully exploit Bluetooth very easily. I reimplemented by buggy controller code using PXT and the results are here.

In fact I also published the project so if you want to fork it and have play, here's the URL:

Saturday, 18 June 2016

micro:bit Blue

One of the things my work with the BBC micro:bit produced is an Android application with which you can experience many of the types of things you can do with Bluetooth on the micro:bit. In the beginning I wrote the initial versions of the application to allow me to test the Bluetooth profile as it was being implemented by Lancaster University. But bit by bit (no pun intended!) it took on a life of its own and I use it all the time now to demonstrate just how much fun you can have with micro:bit and Bluetooth and in fact how much you can learn. I even used it recently as part of a Bluetooth technical training course I was involved in delivering for Bluetooth SIG in Berlin, micro:bit is not just for kids :-)

Today I renamed my application 'micro:bit Blue' and published it in Google Play. If you want to load it onto your Android phone or tablet head over to

Each page has a help menu by the way and there's lots of information in there about what you can do and how things work.


Code it. Connect it. Bitty Software.

Friday, 27 May 2016

Programming the BBC micro:bit directly from your phone

One of the things I love about the BBC micro:bit is that with great development tools from Microsoft, the Samsung micro:bit Android application and a little help from Bluetooth, you can program your micro:bit right from your phone or tablet with no PC or laptop needed at any stage.

My latest micro:bit video shows me creating code which turns my micro:bit into a Bluetooth remote control with which to control the music player on my Android phone.

Saturday, 7 May 2016

Using ARM mbed to create Bluetooth enabled micro:bit applications

The code editors available at at best give you only very limited access to the extensive Bluetooth capabilties of the BBC micro:bit based on predefined use cases like starting a song on your smartphone (provided you're running the Samsung companion application for micro:bit). Python on micro:bit has no access to Bluetooth at all. So how do you get the most out of Bluetooth on micro:bit? The answer is to use ARM's mbed system, either the online version via or the offline variety called Yotta.

My latest video talks about the Bluetooth capabilities of the micro:bit, shows you how to use ARM mbed to use them, explains the potential issues and how to work around them.

Thursday, 5 May 2016

Bluetooth advertising and micro:bit

The BBC micro:bit has a special "pairing mode" which it needs to be in for you to be able to pair it with another device such as your smartphone. When not in pairing mode it's in... well let's call it "normal mode". I published a video showing how to pair with your micro:bit some time ago.

When a micro:bit is not in a Bluetooth connection with another device it will be broadcasting small packets of data over Bluetooth called "advertising packets" (provided it has been paired with at least one device at some point - if you've not yet paired your micro:bit with anything it will not be advertising when in "normal mode").

Advertising is the Bluetooth mechanism which allows other devices like a smartphone to discover your micro:bit.

There are important differences between the advertising (ADV) packets which are broadcast when in pairing mode vs those which are broadcast when in normal mode however and this may have an impact on how the Bluetooth settings screen of your smartphone or tablet behaves.

Here's an ADV packet from when my micro:bit was in pairing mode:

The LE General Discoverable Mode flag is set and this means other devices can regard the micro:bit as willing to be discovered. This is not a security mechanism by the way, it's an expression of intent of sorts.

When a previously paired micro:bit is in normal mode however, the ADV flags look like this:

Neither of the discoverable mode flags are set and the micro:bit is said to be "non-discoverable". It's there of course and it's advertising. Other devices can see those advertising packets as plain as day but they're being politely asked to pretend they can't see it. In practice what this means is that if you've not paired your micro:bit with your smartphone it may not be listed in the smartphone's Bluetooth settings screen under "Available devices". Here's a screen shot from my Nexus 9 tablet which I have *not* paired with my micro:bit which is currently on and advertising:

My micro:bit is not listed despite the fact that it is in range and is advertising because this device has not paired with it and the advertising packets are indicating that the micro:bit does not want to be discovered by random devices it has never been introduced formally to.

On the other hand. my Nexus 5 smartphone has been paired with the micro:bit and so it is listed in the Bluetooth settings screen.

The moral to this story? If you can't see your micro:bit listed on your phone's Bluetooth settings screen and you think it should be, check the description of micro:bit's expected advertising behaviour that I've given here. Hopefully all you need to do is pair your micro:bit.

Thursday, 28 April 2016

micro:bit Bluetooth UART service and Animal, Vegetable or Mineral

James Devine (@James_A_Devine) of Lancaster University recently implemented Nordic Semiconductor's UART service for Bluetooth low energy on micro:bit. At the time of writing the code hasn't yet been released into the world of mbed but it will, have no fear.

The UART service provides a simple emulation of serial data communications over Bluetooth low energy. It's great for exchanging arbitrary byte arrays in either direction between peer devices. In our case one of those peers is the marvellous BBC micro:bit of course.

I tested and will be documenting the new service on Lancaster University's micro:bit runtime site and have just finished implementing a classic two player guessing game "Animal, Vegetable or Mineral" for Android which makes use of the service. It worked a treat and you can see a video of the application in action on my micro:bit page.

Friday, 15 April 2016

The micro:bit digital compass over Bluetooth

The BBC micro:bit contains a digital compass or "magnetometer". You can obtain magnetometer data including the direction the micro:bit is currently facing, measured in degrees, over a Bluetooth connection. Want to see what this looks like? Of course you do!

Wednesday, 6 April 2016

BBC micro:bit Bluetooth security

The BBC micro:bit uses standard Bluetooth security. It requires devices such as smartphones to have paired with it before the majority of interactions are permitted. Pairing uses "passkey authentication" which means that during the pairing process, the micro:bit will display a 6 digit random number which has to be keyed into the smartphone. Having paired, all Bluetooth characteristics become available for access, Characteristics support some combination of read, write and notify and in the greater majority of cases, the security rules stipulate that these must take place over a secure (i.e. encrypted) link. An attempt to perform such an operation without having paired should cause the smartphone OS to initiate the pairing process automatically.

I've created a video showing how to pair with your micro:bit:

Tuesday, 22 March 2016

BBC micro:bit launch at the London Stock Exchange

It was both an honour and a thrill to be present at the official launch of the BBC micro:bit at the London Stock Exchange today. A lot of people worked very hard to get to where we are today. Here's to the future!

I had the honour to hold the macro micro:bit for the photo

Friday, 18 March 2016

Rune It!

Like the Bluetooth logo? As you probably know it's a Nordic bind rune. See

Well, you can make your own rune using a fun feature at 

Here's mine:

Thursday, 17 March 2016

Bluetooth World 2016

I've been out in sunny California this week for Bluetooth World 2016. OK... in fact on arrival it was rainy and foggy but don't let me spoil the mental image I was going for! Happily the weather did change for the better just in time for The Bluetooth SIG's primary event to kick off in style in the Levi Football Stadium. Note to Brits: 'Football' meaning 'American Football' :-)

I was super-busy on day 1, battling through sleep deprivation and jet lag to deliver two sessions in the packed 'developer hub' and then closing the day by moderating a panel discussion on IoT and mesh. The panel members did an amazing job and delivered an engaging and interesting discussion. Members were from Cypress Semiconductor, Texas Instruments, Ilumi and ABI and between them brought a range of perspectives and opinions. Happily those opinions were not always aligned which always makes for a better discussion!

Amongst the highlights of day 2 was a meeting I had with the CEO and CTO of Evothings. They showed me a pretty impressive demo of their HTML based SDK for mobile IoT connected application development. Looked like a super fast way to create apps and I look forward to learning more about it.

Thursday, 25 February 2016

Embedded World 2016

It's my second time here in Nuremberg at the enormous Embedded World conference and exhibition. Yesterday I talked about and demonstrated using Bluetooth Developer Studio. In 30 minutes I designed a custom profile for a home-made Arduino controlled LED lighting panel with Bluetooth low energy interface, generated and completed code for it, tested it, generated a complete and fully working Android application for the same profile and showed it controlling the lighting device with no manual coding required and produced a few reports from the tool. In 30 minutes.

Hopefully this was a pretty good proof of the power of the tool for my audience :-)

The Arduino + Bluetooth Controlled LED Panel

Bluetooth Developer Studio Virtual Testing

Thursday, 4 February 2016

BBC micro:bit

We're on the home straight and one million 11 and 12 year old British youngsters will be receiving their very own BBC micro:bit later this year!

I've been creating videos showing the micro:bit in various Bluetooth related scenarios on Vimeo. To make them easier to find I've collected them all together on the BBC micro:bit page which you should see a link to on the right of this page.

 If you have any questions about BBC micro:bit check the BBC site or ask me on Twitter: @bluetooth_mdw Enjoy