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.