Friday, 6 November 2015

A Quick Note About Developer Boards

When I speak at conferences I often demonstrate Bluetooth Low Energy applications using some kind of developer board and I get asked questions by people who are new to the subject and keen to get 'hands on' about what I use and why.

There are lots of ready made Bluetooth developer kits out there, often from Bluetooth chip manufacturers. There are also plenty of options for 'Bluetooth-enabling' your favourite small/medium/large computer as well. In either case, your aim is the same; to acquire a programmable Bluetooth Low Energy platform you can use for prototyping new device ideas, for testing your client applications or maybe to accomplish the complete and final implementation of device firmware before flashing the code to the final product hardware.

At the recent Oredev event in Sweden for example, I used a Bluegiga DKBLE dev board to act as a programmable Bluetooth beacon since this was a convenient approach to being able to vary beacon advertising packet content without needing to have lots of separate beacons in different physical locations for testing purposes. In short I could do all my testing sat at my desk and could change beacons by tweaking my code and flashing it to the board. Very convenient and fast,

Bluegiga DKBLE programmed to be an AltBeacon

Dev kits typically include some hardware which will either be a programmable microcontroller unit (MCU) or full computer system complete with an O/S like Linux. The Bluetooth low energy controller (hardware part of the stack) will either be an integral part of the board in the form of a 'system on a chip' or it will be a separate component you plugin. In the latter case it might be a USB dongle or maybe an expansion or daughter board of some sort. I sometimes use an Arduino for example and to Bluetooth-enable it I plug in a Bluetooth Low Energy 'shield' and install the related Arduino Bluetooth Low Energy library to program against.

There are lots of different Bluetooth dev kits out there and in fact often it's an option to simply use your favourite computing platform rather than a specialised board. I sometimes use my Raspberry Pi or my Intel Edison for example. In either of these cases, both devices being Linux based, I install BlueZ, the Bluetooth stack for Linux and plug in a Bluetooth Low Energy dongle into one of the USB ports and I'm away.

Arduino Uno (on the right) with Redbear Labs Bluetooth shield controlling a Neomatrix LED panel

There are a number of factors to consider when choosing a dev kit or other programmable platform to add to your development environment. The most important one I think is the GAP roles you need supporting. If all you want to do is implement devices which advertise, accept connections and expose GATT services, characteristics etc then you need to make sure the GAP Peripheral role is supported. If GAP Peripheral is supported (means you can advertise and accept connections) then GAP Broadcaster almost certainly is as well (advertises but will not accept connections). Beacons often use the GAP Broadcaster role. If you want to be able to scan, discover and connect to other devices from your board then you need GAP Central. For maximum flexibility you want a board/kit that supports both sets of roles. Some kits let you choose this according to the software library you install or link against. For example the Nordic nRF51 uses libraries which Nordic call 'soft devices'. The S110 gives you Peripheral mode, the S120 gives you Central and the S130 gives you both.

You'll also need to consider the programming language used. Most but not all boards from Bluetooth chip manufacturers use C or C/C++. The one exception I can think of is the Bluegiga kit I use (Note: Bluegiga are now called Silicon Labs having been recently acquired and they have a new kit that looks nice called the Gecko). The Bluegiga boards use a scripting language called BGScript which is a bit like BASIC and very easy to learn.

Computers as opposed to boards may offer other options. On my Raspberry Pi and Intel Edison I tend to use node.js with libraries BLENO and NOBLE. Python has some support though I haven't found a library that I regard as complete. This is something I'm currently looking into.

Your board will be most useful, especially if you're new to this if it comes with lots of sample code which you can flash to the board to turn it into any one of the many types of device which have standard profiles as defined by the Bluetooth SIG. I also use my Bluegiga as a heart rate monitor device sometimes, with the heart rate measurement values generated internally in software rather than being acquired through a sensor. This makes testing and demonstrating really easy as I can vary the heart rate which is transmitted to my smartphone app just by turning a dial on the board.

Some kits come with sensors or other I/O capabilities that you might find useful. Having a collection of readily available sensors can be great especially when the board has some standard firmware you can flash and which makes the sensor data available via suitable Bluetooth GATT services. I gave away some Texas Instruments SensorTag kits in my Oredev sessions and these are a great example of this as there's also a standard smartphone app you can install and you can be up and running and watching sensor data appear over Bluetooth on your phone in a matter of minutes.

Finally, look for any special features you might have in mind. I recently got a Cypress CY8CKIT which supports capacitive sensing which opens up all sorts of wonderful possibilities for making Bluetooth Low Energy controller devices which make other devices respond to you touching things like.... errrr..... potatoes.... plugged into the Cypress board!

Cypress board as Bluetooth potato MIDI controller!

The new (at time of writing) Gecko board from Silicon Labs has an ethernet port as well, which is intriguing.

Gecko - Spot the ethernet port!

That's about it. There's lot of choice and kits are generally not expensive. They're fun to have, a great way to learn and in my opinion an essential ingredient in any Bluetooth developer's dev environment!

Note on terminology: 'Bluetooth Smart' is the brand name for 'Bluetooth Low Energy' Technically they're the same thing.

Thursday, 5 November 2015


Oredev is Scandinavia's largest dev conference and is held in Malmo in Sweden. And an excellent conference it is too; very diverse in terms of subjects and some fine speakers from all over the world. I delivered two sessions on two separate days and they were both videoed.

Bluetooth Beacon Applications and Real World Developer Issues


Creating the Edge Tier of the IoT with Bluetooth Smart

Wednesday, 28 October 2015

The Potato Orchestra

Bluetooth Low Energy. MIDI. Apple iPhone. Cypress deb board with capitive sensing. Potatoes. Yes, POTATOES!

Not the most musical thing I've ever created but the potato is a very difficult instrument to master. Takes years of practice!

Bluetooth Potato Orchestra from Martin Woolley on Vimeo.

Qt World Summit and more

I'm speaking at lots of developer events through to the end of the year. The first in the current "wave" of events was the Qt World Summit in Berlin, an excellent conference for developers who work with the Qt framework for cross platform development. I had nearly an hour and filled it with lots of Qt and Bluetooth loveliness!

I was brave and tried to demonstrate *live* an Arduino controlled LED lighting matrix with a Bluetooth Low Energy interface all from a Qt application on my Android phone. Sadly the soldering had taken a bit of punishment and the demo failed spectacularly. The audience were great though. Nobody threw anything at me anyway :-)

You can watch the whole recorded session here:

Last week I was in Munich at the "IoT from Sensor to Cloud" conference talking about the Bluetooth roadmap. And next week I'm in Sweden speaking at Oredev.

Tuesday, 28 July 2015

The BBC micro:bit

I haven't had time to blog for ages. One of the reasons is that I've been involved in an absolutely brilliant project, helping the BBC make the micro:bit a reality.

The official launch event for the BBC micro:bit was held a few weeks ago at the BBC HQ in London. It seemed like all the world's press and TV were there watching the slick launch presentations from the BBC and partners. Dara o'Briain MC'd and Stephen Fry made an appearance by video. I also got to meet Maggie Philbin who is involved with the project via her TeenTech company.

I confess I was rather thrilled to be in the "micro:bit partners" photo the BBC had taken for their archives. I'm in there somewhere, honestly!

Rather than restate what's already been written about quite what I got up to in the project, here are a couple of write ups which tell the story well enough, one written by me for the Bluetooth SIG blog and the other, an interview conducted with me by Electronics Weekly.

BBC micro:bit in the Bluetooth SIG blog

Electronics Weekly interview

I'm really looking forward to seeing the impact micro:bit has when it finds it's way into UK schools later this year!

Friday, 12 June 2015

Bluetooth Developer Studio Training in Berlin

I was in Berlin this week training 120 developers about Bluetooth Smart (AKA Low Energy) and the new developer tool from the Bluetooth SIG, Bluetooth Developer Studio. It seemed to go well judging by the feedback forms and the comments made directly to me by various attendees. People had come from far and wide to attend and there were people from (at least) Germany, UK, Austria, Italy, Spain, Slovenia and Israel present. Now there's commitment :-)

Explaining the Bluetooth Developer Studio internal object model
I'll be delivering the same course again in London in September if you'd like to come along, just before Bluetooth World where I'll be moderating a panel session and also presenting one of the sessions.

Berlin is a really cool city. It's a major European capital and yet manages to feel like a small, quiet and friendly city. I made the most of a couple of spare hours before I was due to fly home by taking a long walk in and around the lovely Tiergarten park and took some fairly pathetic selfies and other photos en route :-)

Saturday, 11 April 2015

Droidcon Italy

The many faces of Torino

Droidcon Italy was the 3rd of the Droidcon events that I've attended and once again, it was a high quality event, with about 680 attendees and 70 speakers. It was held in Torino, a beautiful, historic city within sight of the Alps. Wonderful!

I did my usual thing, talking about Bluetooth Low Energy as the killer enabler for the IoT and walked the attendees of my session through the primary APIs for the Android platform.

I gave away a Texas Instruments SensorTag, a Broadcom WICED Sense and a Red Bear Lab BLE Shield for Arduino to three attendees as a reward for my three favourite tweets.

Prize Winning Tweets
The event organisers treated all the speakers to a meal at a nice restaurant Tre Da Tre near to the amazing Mole Antonelliana. Excellent pizza and one of the best Tiramisu I ever tasted!

Mole Antonelliana

A great event in a lovely location. Next stop Bluetooth World in Santa Clara, California!

Oh and here are my presentation slides.

And wow, you can relive the whole thing by watching a video recording of my session which the organizers made and uploaded to YouTube!

Thursday, 12 March 2015

The Bluegiga DKBLE development kit

I was given a Bluegiga DKBLE development board by Bluegiga and have recently been using it in support of some work I'm doing. I hadn't used a Bluegiga board before and so had to learn how to use it and I thought I could share my experience and the things I learned here.

The Kit
The kit consists of a main DKBLE board and several "carrier boards" which can be plugged into the main board. These are small boards containing a particular Bluegiga module. There are 4 in total; 1 x BLE112-A, 1 x BLE113-A, 1 x BLE113A-M256K and 1 x BLE121LR-A-M256. The latter is Bluegiga's long range module which their web site says has a range of up to 450 metres. Pretty impressive.

The main board has pins at one edge which allow one carrier board to be plugged into it. It also includes an LCD display, a temperature sensor, an accelerometer, an altimeter, a potentiometer and a USB to UART converter.

Project Configuration
A Bluegiga project consists of a number of different files, one of which is the project configuration file. It has an extension of ".bgproj" and defines the target hardware and the names of other key project files, such as the name of the XML file which defines the GATT services, the name of the hardware definition file, the name of the primary bgscript file and the name of the output image file to be created by the compiler.

 <?xml version="1.0" encoding="UTF-8" ?>  
   <gatt in="gatt.xml" />  
   <hardware in="hardware.xml" />    
   <script in="course_project.bgs" />  
   <image out="out-ble113.hex" />   
   <device type="ble113" />  
      <boot fw="bootuart" />  

Defining GATT Services
This is a straightforward task and similar to other boards I've worked with from Nordic Semiconductor and CSR for example, in that it involves using XML to describe services, characteristics and descriptors in a logical, intuitive way. There's no GUI to help with this so your tool is your favourite text editor. There are lots of examples that come with the SDK so it's easy to get started.

I had a custom profile I wanted to implement which included 4 services. The first was an adopted service called the Battery Service. The other three were all custom services; the counter service and random number service are those I used for my Texas Instruments SensorTag hacking and the Personal Naming service was a new one I came up with which allows you to give a custom name to your device. Yes, a "pet name" is what I had in mind :-)

 <?xml version="1.0" encoding="UTF-8" ?>  
   <service uuid="1800">  
    <description>Generic Access Profile</description>  
    <characteristic uuid="2a00">  
     <properties read="true" const="true" />  
     <value>Innovation Series Device</value>  
    <!-- APPEARANCE = unknown -->  
    <characteristic uuid="2a01">  
     <properties read="true" const="true" />  
     <value type="hex">0000</value>  
       <!-- Battery Service -->  
       <service uuid="180f">  
     <characteristic uuid="2a19" id="xgatt_battery">  
       <properties read="true" />  
       <value length="1" type="user" />  
   <!-- Counter Service -->  
   <service uuid="3E099914-293F-11E4-93BD-AFD0FE6D1DFD" advertise="true">  
     <!-- Counter -->  
     <characteristic uuid="3E099915-293F-11E4-93BD-AFD0FE6D1DFD" id="xgatt_counter">  
      <properties read="true" write="true"/>  
      <value length="1" type="user" />  
   <!-- Random Number Service -->  
   <service uuid="3E099916-293F-11E4-93BD-AFD0FE6D1DFD" advertise="true">  
     <!-- Random Number -->  
     <characteristic uuid="3E099917-293F-11E4-93BD-AFD0FE6D1DFD" id="xgatt_random">  
      <properties read="true" notify="true"/>  
      <value length="2" type="user" />  
   <!-- Personal Naming Service -->  
   <service uuid="3E099918-293F-11E4-93BD-AFD0FE6D1DFD" advertise="true">  
     <!-- Personal Name -->  
     <characteristic uuid="3E099919-293F-11E4-93BD-AFD0FE6D1DFD" id="xgatt_personal_name">  
      <properties read="true" write="true"/>  
      <value variable_length="true" length="20"/>  

The id attribute defines a name for the GATT attribute which can be used to reference it from code. The file attributes.txt maps these ID values to GATT handle values.

 xgatt_battery 8  
 xgatt_counter 11  
 xgatt_random 14  
 xgatt_personal_name 18  

Developing for the Bluegiga DKBLE
The first thing that strikes you as different when it comes to developing for this board is the programming language. Their API does allow C to be used but in addition, Bluegiga have their own scripting language called bgscript. I liked working with bgscript. It's reminiscent of the BASIC programming language, the first language I ever learned, over 30 years ago! It's pretty quick to develop with as well.

Coding for Bluegiga involves implementing event handlers which receive call backs from the system, generating events by making API calls and writing and calling your own custom procedures, which are like functions which cannot return a result (i.e. they're similar to functions which have a return type of void). When you call a system API, you generally (perhaps always) receive a call back once your event has been handled, so there's a symmetrical request/response pattern working with the event system.

If all you want to do is expose simple characteristics whose values can be read or written to, you don't need to do much coding. The characteristic values lives in the device's attribute table and the framework gives access to it without you having to write any bgscript. If reading or writing to a characteristic requires more processing than this though, then you must implement code inside the appropriate event handler. This was the case for my counter service. Reading from the counter value characteristic required the value to be incremented before returning it to the GATT client. As such, I had to mark the characteristic as having a type of "user" in the gatt.xml file.

   <!-- Counter Service -->  
   <service uuid="3E099914-293F-11E4-93BD-AFD0FE6D1DFD" advertise="true">  
     <!-- Counter -->  
     <characteristic uuid="3E099915-293F-11E4-93BD-AFD0FE6D1DFD" id="xgatt_counter">  
      <properties read="true" write="true"/>  
      <value length="1" type="user" />  

Requests to read characteristics of type user result in system calls to the event handler called attributes_user_read_request. A simplified version of my implementation appears next:

 # Listen for GATT read events  
 event attributes_user_read_request(connection, handle, offset, maxsize)  
   if handle = xgatt_counter then  
    call attributes_user_read_response(connection, 0, 1, counter)  
    counter = counter + 1  
    if counter > 255  
      counter = 0  
    end if  
   end if  
   if handle = xgatt_random then  
    # swap from little endian (Bluegiga internal format) to big endian for GATT  
    random_be(0:1) = random(1:1)  
    random_be(1:1) = random(0:1)  
    call attributes_user_read_response(connection, 0, 2, random_be(0:2))  
   end if  
   if handle = xgatt_battery then  
                #start measurement, read VDD/3, 9 effective bits   
                call hardware_adc_read(15,3,0)  
   end if  

Note that bgscript supports simple variables and types of variable known as buffers. These are essentially byte arrays and they're addressed using name(start:length) notation.

After dealing with a simple read request, you call attributes_user_read_response which causes the attribute protocol response to be returned to the client.

In the case of the Battery Service, this requires interaction with the hardware APIs and in this case a call to hardware_adc_read. This in turn, causes a callback to an event handler called hardware_adc_result once the operation has completed. My full source code appears below.

The Random Number service generates a 16 bit random number when its characteristic is read and generates and returns a random number once every second as a GATT notification whenever notifications are enabled. The bgscript has no random number function so I coded my own implementation of a simple Linear Congruential Generator algorithm, which is the basis of the random number function in a lot of programming languages. See .

 # Random number generation  
 export dim rseed(4)  
 export dim m  
 export dim a  
 export dim c  
 dim x  
 dim r  
 dim mod_result  
 procedure mod(number, divisor)   
  x = number / divisor  
  mod_result = (number - (x * divisor))  
 procedure genRandom()  
  # Xn+1 = (aXn + c) mod m  
  r = (a * rseed(0:4) + c)  
  call mod(r,m)  
  rseed(0:4) = mod_result  

To seed the random number sequence I used a temperature reading from the board's temperature sensor.

I used a timer to generate a fresh random number each second and write it to the GATT attribute table. If the client had enabled notifications then the framework automatically generated a notification message with the new value in it. I didn't have to explicitly code this which I rather liked.

 event hardware_soft_timer(handle)  
   call genRandom()  
   random(0:2) = rseed(0:2)  
   # swap from little endian (Bluegiga internal format) to big endian for GATT  
   random_be(0:1) = random(1:1)  
   random_be(1:1) = random(0:1)  
   # update characteristic value (will push data if client has subscribed to notifications/indications)  
   call attributes_write(xgatt_random, 0, 2, random_be(0:2))  

The only thing I didn't like about the Bluegiga SDK was how difficult it seemed to be to use the LCD display. The LCD is really useful and I had it displaying the random numbers my timer was generating once per second and displaying a visual acknowledgement of GATT operations such as read requests. This was very useful and reassuring to see during development. But the API is really low level and I can't help but wish a set of higher level wrapper functions had been made available to bgscript to make this easier. A minor point given how great the kit is in every other way.

I have a simple Android client application which I used with the board. It shows the random number service working very nicely!

My full project can be downloaded from here, possible/probably bugs and all. This is yours for educational purposes. No responsibility is accepted for anything you find to be wrong :-)

Droidcon Tunisia

I just got back from my very favourite event of the year so far. That event was Droidcon Tunisia which was held in the beach resort of Hammamet, an hour from Tunis! It was my first time in Tunisia and in fact my first time in Africa so this made the trip all the more exciting. Of the event itself, I really wasn't sure what to expect but it turned out to be excellent.

I had the keynote and talked about the major technological developments of the last three decades, highlighting IoT as the most significant development of our time, one which historians will write about in years to come. IoT is unquestionably the biggest opportunity that developers of all sorts have had in a long time and certainly the biggest opportunity mobile developers have had since the smartphone was invented. Naturally, this being Droidcon I also "got technical" and showed the audience how the Android APIs can be used to create applications which exploit Bluetooth Smart, the killer enabler of IoT.

The audience were wonderful. The room was wonderful. Attendees were mostly university students and there was over 700 in total with standing room only during the keynote.

I also had the honour of meeting Tunisia's Minister of Communication Technologies and Digital Economy, Mr Noomane Fehri and enjoyed watching his rather inspiring opening speech. There's a good deal of positive patriotism and national pride in Tunisia which given recent history is not surprising. There's an optimism too and a determination to succeed, and Mr Fehri's speech exemplified this. I met some *really* bright young people at the event so there's every reason to believe Tunisia has an equally bright future.

The Droidcon franchise is well supported by an informal group of respected speakers and I had the pleasure to meet some impressive and very likeable people from amongst the speakers. I expect to meet some of them again, beginning with Droidcon Italy next month.

It wasn't all work either. I had the opportunity to see Carthage and to wander around a Medina in old Tunis and drink lots of delicious mint tea :-)

And I also managed to take a short walk to the beach about 100 metres from the venue and marvelled at the highly obedient... possibly not completely real.... cats in the trees inside the venue :-)

That's it! Hopefully I'll be lucky enough to be invited back next year. I hope so.

Saturday, 28 February 2015

Embedded World

Embedded World is Europe's foremost conference and exhibition for people interested in embedded systems and runs for 3 days in Nuremberg, Germany. It prides itself on being a serious, technical event with high calibre speakers who are respected authorities in their field. So why I was there and why I was possibly the only person presenting two sessions, I really have no idea!

But I was there and I did speak. Twice.

Obligatory photo of me presenting

I also had a good wander around the enormous (but not quite CEBIT sized) exhibition. Some was interesting and for me, some considerably less so. We all have our thing I guess.

My first session "Creating the Edge Tier of IoT with Bluetooth Smart" sought to clearly position Bluetooth Low Energy (AKA Bluetooth Smart) with respect to IoT architectures and patterns and then proceeded to explore the practicalities of developing both device firmware, using an Arduino based system as the example, and smartphone applications, using Android.

My second was arguably more interesting and consisted of a 30 minute and reasonably technical guided tour of the newest capabilities and features of Bluetooth Low Energy as well as a close look at things that will be released imminently. I also talked briefly about the standardisation of Mesh networks on Bluetooth Low Energy about which the Bluetooth SIG issued a press release a few days ago, a very exciting development which will have a substantial impact in sectors such as the Smart Home, the commercial building sector and the industrial internet of things.

I got asked a good question at the end of my second session and I'd like to make sure my answer is clear as I suspect it was not. The question concerned the fact that at version 4.2 of the Bluetooth core specification, resolution of private resolvable addresses has moved from the host to the controller. Since the controller is hardware, this implies correctly that only new devices will be able to support this particular feature. What is does *not* mean however is that only devices with new hardware can be 4.2 compliant. None of the new features of 4.2 are mandatory and so only if a manufacturer opts to implement the new privacy architecture will this mean they need a 4.2 compliant controller. And it has no impact on devices compliant with 4.0 or 4.1 either. Advertising packets are advertising packets and a 4.0/4.1 device can still process advertising packets emitted by a 4.2 device, containing a private resolvable address instead of the old style not resolvable reconnection address type. In short, 4.2 is backwards compatible with earlier 4.x versions.

PDF versions of the slides from both my sessions are available for download:

Session 1 - Creating the Edge Tier of IoT with Bluetooth Smart

Session 2 - What's New in Bluetooth Smart?

And.... if you really want to, you can watch a video of my second session as well. Enjoy.

25th Feb 2015 - Embedded World - What's New in Bluetooth Smart?

Thursday, 5 February 2015

Women Who Code

Women Who Code is a non-profit organisation, dedicated to helping women excel in technology careers. Their headquarters is in San Francisco but they have operations in 15 countries around the world, including in the UK. I was fortunate to meet the Women Who Code London leader, Gen Ashley (Twitter: @coderinheels) at Droidcon in London last year. We got talking and the result was an opportunity for me to speak at one of the group's regular meetups.

I spoke at last night's meetup and talked about the rise of Bluetooth Smart, it's background as a key, low power wireless technology that was designed for the Internet of Things (IoT) and moved on to show the attendees what's involved in creating Bluetooth Smart devices and how to develop corresponding applications for Android smart phones. Much of this was based around a resource for developers called the Bluetooth Smart Starter Kit. You can download it from the Bluetooth SIG developer web site and then go through its various projects to learn to develop Bluetooth Smart devices using an Arduino platform or Bluetooth Smart applications for iOS, Android, Windows Phone or BlackBerry 10.

Explaining the Bluetooth Smart Starter Kit

One of the key topics covered before getting into the coding concerned recent and imminent new capabilities of Bluetooth Smart which allow devices to interact with the internet i.e. internet or IP connected devices in a variety of ways.

I also did a demo of a smart lighting product and described how it worked in terms of its client / server architecture, its use of Bluetooth Smart and the role of its embedded firmware.

There was a quiz at the end which posed three questions based upon the content of the session and the lighting demo in particular. I was delighted to be able to give away three prizes; a Redbear Labs Bluetooth Smart shield, a Broadcom WICED Sense and a Texas Instruments SensorTag. I'm sure they've gone to good homes and will be well looked after :-)

Quiz Time

I don't think I've every had so many good questions at the end of a talk. These gave me the opportunity to talk about beacons, about security in general and about how Bluetooth addresses privacy issues and can stop you from being tracked via your device's advertising by varying the MAC address it uses in advertising packets.

The event was hosted by Badoo and their very own Kelly (Twitter: @KtKellyTran) was a great help with the AV set up and generally making me feel welcome :-)

There was lots of nice food and I had a good chat with various people at the end. I think I might even have inadvertently let slip my plan to build a robot army out of Lego Mindstorms (Bluetooth controlled of course) but that's a whole other story. There were all sorts of somewhat more sensible ideas from other more sane people and at least one person was teetering on the brink of deciding to go and set up a start-up!

A great evening. Thanks to Women Who Code and Gen for inviting me to speak.

My presentation can be downloaded here.

Wednesday, 21 January 2015

IoT London Meetup

I was a speaker at IoT London last night. This is a really popular meetup with over 4,000 members and as is apparently the norm for this meetup, last night's event was significantly over subscribed, so we had a full house. From a poll taken, the attendees were a diverse bunch; software people, hardware people, designers, investors and press.

Kicking things off.....

The IoT London format is that you get 10 minutes to speak and 10 minutes for questions. I'd chosen to deliver a summary of new Bluetooth features from the recent 4.2 release plus a few which are imminent and one which is further down the road map but important to IoT.

I used my Thalmic Labs Myo gesture controller to control my presentation for the first time and overall it went quite well with only a couple of glitches which I'm inclined to put down to user error. It's a tool and you have to learn to use it properly. It's a nice demonstration of a Bluetooth Smart device with a custom profile too.

Gesturing with Myo to advance to my next slide!

 In summary, I talked about the ways in which Bluetooth Smart devices can now be connected to the wider internet; via the new RESTFul APIs for gateways, using the HTTP Proxy Service or by implementing 6LoWPAN over Bluetooth using the Internet Protocol Support Profile. I also talked about security improvements including the adoption of the Elliptic Curve Diffie Hellman key agreement protocol for super-secure pairing and improvements in power efficiency relating to the resolution of private MAC addresses by trusted (paired) devices. Finally I mentioned the data throughput increase that 4.2 makes possible (up to 2.5 x faster) and gave a sneak preview of the standardisation work the SIG have kicked off relating to mesh networks over Bluetooth Smart.

Kirstin Hancock from Blue Maestro followed me and gave us an update on the Blue Maestro success story! And we closed with a talk from I spent an enjoyable hour after the presentations were over, talking with a steady stream of people with all sorts of things to ask or discuss. A best of breed meetup I'd say.

Saturday, 10 January 2015

It's not just about sensors - controlling machines with Bluetooth Smart

I got sent a Securemote developer board from Delphian Systems recently. It's great for demos and includes a temperature sensor, some LED lights, a motion sensor, some relays, a water detector sensor and... a solenoid and a motor. I was messing around with the solenoid and motor this morning and thought I'd post a quick video to show the thing in action. Bluetooth Smart controlling machines. Think about that! :-)

Bluetooth Machine Control from Martin Woolley on Vimeo.

Wednesday, 7 January 2015

Controlling things with the Myo Bluetooth gesture controller

Controlling my Arduino with the Myo gesture controller

Last year I got myself a Myo gesture controller from Thalmic Labs and have enjoyed following the product's progress from beta. The firmware works well now and gestures are reliably recognised. I fully expect that Myo will be my standard means of controlling Powerpoint presentations this year.

I was thinking about IoT and the role something like Myo might play. The question was, whilst Myo is easy to use with PC applications, either using the canned capabilities it comes with or by writing your own scripts, could I use it to interact with miscellaneous inanimate objects like lights?

I did some investigation using some Bluetooth tools and discovered that Myo uses a custom Bluetooth Smart profile with a number of custom services.

Myo's GATT services

In terms of GAP roles, it's a GAP Peripheral and advertises. GATT Notifications are used to communicate movement and gesture data to a connected device.

Myo protocol trace showing notifications
 I decided it would be interesting to try to use my Myo to control LED lights on a circuit board via my Arduino. The first question I had to answer was what the architecture of my solution would be.

Thalmic Labs have not yet published details of their custom profile so writing GATT client applications which connect directly with Myo, which acts as a GATT server, is difficult unless you use one of their APIs, such as the one for Android smart phones or you write scripts for your PC which work with their Myo Connect service. I didn't really want to have an intermediate device in between the Myo and my Arduino but realistically, without spending time I don't have, trying to reverse engineer their notifications from protocol traces, I had no choice. So I decided to write an Android application using the Myo official API that the Myo device would connect to and communicate with and create a custom GATT profile of my own for the Arduino and which I could use to control some LEDs and an LCD serial display.

My solution architecture

So how does this work exactly? The Android app is connected to both the Myo and to my Arduino/BLE shield. The app receives gesture data via the Myo API, formed from GATT notifications which the Myo is transmitting. The Android app takes the gesture data and uses it to send "commands" to the Arduino, which I've equipped with a custom profile I called the Simple Controller profile. It has a custom service, the Simple Controller service, which has a single characteristic to which I can write a value, representing a command of some sort. In the service implementation in my Arduino sketch, I respond to the characteristic write events by switching on an LED according to the gesture the characteristic value represents and I write the name of the gesture to the LCD display. Simples!

The Simple Controller profile implemented in the Arduino

Whilst this isn't my first choice architecture I have to say, it does in fact work fine. I'm hoping Thalmic Labs will provide details of their custom profile at some point in the future though so I can take a second look at this use case and see if I can eliminate the Android proxy component. Not a bad start though!

Here's a video of the solution in action. Enjoy it right here or if you prefer, over in Vimeo.

Controlling things with the Myo Bluetooth gesture controller from Martin Woolley on Vimeo.