Nest Controller

I've fancied having a Nest controller for a while but they've only been available in the 'states. Then this week I found out that they are now out in the UK. It's taken a while for them to arrive here, mainly because of the differences between US and UK heating systems.

Mine arrived yesterday, complete with a set of instructions on how to install. I'm very tempted to have a go, but this would probably be a daft thing to do just before we go away for a week or so. But I think it will make a nice Easter project.  

Plenty of Bluetooth

If you want to connect your Windows Phone to any kind of hardware I can strongly recommend the HC-06 Bluetooth adapter. I've found it to be very easy to connect to and it works "right out of the box". It plays a major part in my TechDays presentations. You just connect the devices to a power supply (from 3.3 to 6 or so volts) and then your device (usually an Arduino) can talk to the adapter over a serial connection which by default is set to 9600 baud. 

The connections to the device are only supposed to work at 3.3 volt levels but I've had no problem using the 5 volts signals that the Arduino produces. 

You can change the name of the device by sending it commands, but you can pair any number of them with a single phone and then when your program runs it will connect to the first one it finds.

You can find these devices very cheaply on places like eBay. Search for "Arduino HC-06" and you should find quite a few. If you are prepared to wait for them to arrive from China you can get them very cheaply, but beware of buying ones marked as "carriers". These are very, very cheap but they actually don't have any chips on them...

Storing Constants in Arduino Programs

Welcome to another of my "I put this into my blog because otherwise I forget how to do it and have to go onto the net and find out again" posts.....

I really like writing programs for the Arduino platform. The good news is that the devices can do a lot, but the programs themselves are actually very tiny. The bad news is that you are working in an environment where there is hardly enough of every kind of resource. Particularly memory. 

In an Arduino there are two kinds of memory. There is RAM (random access memory) which is where your program stores the variables it is working on at any given time and there is EEPROM (Electrically Erasable Programmable Read Only Memory) which is where the program code lives. When you put your program into the Arduino it is stored in the EEPROM part and runs from there. If your program creates any variables, these are stored in the much smaller RAM. 

If you want things like large look up tables (which would usually be stored in the memory of your computer) then you are heading for trouble, as you only have a strictly limited space to store data values. Fortunately you can move constant data into the program memory of the device, so that it doesn't need to be stored in the precious data space.

const byte big_lookup_table [] PROGMEM= {
      0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0,  0 };

The statement above creates a big (actually not that big, but you get the picture) array of bytes that I've called big_lookup_table. I've added the modifier PROGMEM to tell the compiler I want the table to be located in program memory, not RAM. The table could be quite big (an Arduino UNO has around 28K of program memory available as I recall), you could save things like sound samples or images here if you wanted to. 

The only slight complication is that when you want to get hold of the elements in the array you can't just directly access them. Instead you have to use a macro which will do the fetching for you.

x = pgm_read_byte(&big_lookup_table[i]);

The statement above takes the element at location and fetches it into byte variable x. This also means that fetching data from program memory is a tiny bit slower than "normal" variables, but in practice you don't notice the difference. 

Rob at Tech Days 2014 NL

In a few days I'll be off on my travels again. I've done sessions at TechDays in the Netherlands for as long as I can remember, and they are always great fun. Even when all the demos fail. This year I'm doing three:

For the hardware one I've got flashing lights and all kinds of good stuff, and I'm really looking forward to telling folks about the wonders of MonoGame. And there will be special treats for the ones who turn up at the 7:45 am session to find out all about Phone to Phone communications. If you are coming along to the conference I'd love to see you.  I've even written some new jokes..

No Mr. Bond. I expect you to fry......


Feel quite a bit better today. Well enough to watch some telly. It's Sunday afternoon, and so that means that ITV will be showing a Bond movie. And they are. "The Spy Who Loved Me". One of the worst ones in my opinion. But at the very end I saw something that piqued my interest. The last part of the credits was given over to mentions of people the producers wished to thank. This is the list of sponsors who have given money for product placement. All the usual suspects were there, Lotus cars, Seiko watches, etc etc. And right at the end: "North Thames Gas Board". 

North Thames Gas Board? What on earth did they do? Perhaps they were mentioned in early drafts of the script:

Scene 67: James Bond's apartment. James and an exotic Russian spy are having a candle-lit dinner. The exotic spy (her name is not important) looks up from her caviar vol-aux-vents and speaks:

Exotic Spy: 'James?'
Bond: 'Yes, my darling?'
Exotic Spy: 'This food, it is so delicious. Did you cook it yourself?'
Bond: 'Yes, my darling.'
Exotic Spy: 'And tell me,  what is your secret to achieving such fantastic flavours?'
Bond: 'Well, er, actually, its all about the gas that you use......'

Scene 210: Evil lair. Bond and the exotic spy (her name is still not important) are tied together on the end of a long rope which is hung over an enormous, fiery pit. The evil villain (his name is not important either) addresses them from a control room full of shiny sponsored machinery and expendables in brightly coloured boiler suits:

Bond: 'You won't get me to talk you know.'
Evil villain: 'I think I will. You see that fiery pit below you...'
Bond: 'What of it?'
Evil villain: 'Do you want to know what kind of gas I'm using.......'

C4DI Hardware Meetup - With Nerf Guns

Lots of Industry

Lots of Industry

Tonight was our second hardware meetup at C4DI. I knew that things were going to go well when I arrived to find everyone had already set up and was building stuff and making it do things without us needing to do anything. Peter was in charge of the exercise tonight (you can find his lab here) and he had made really good use of the flex sensor in the SparkFun Redboard Kit to create a shooting game that you can play with Nerf guns. Which he had thoughtfully provided too....

Everyone had great fun building up the circuit, getting the software working and playing with the result. The lab was great because it shows how you can create a fully formed solution (a shooting game where you have a few seconds to hit the target three times) based on this technology. 

No Cows were harmed in the making of this game

No Cows were harmed in the making of this game

Peter had even provided a bunch of 3D printed parts that support the flex sensor target, and some cows (taken from milk cartons) to use as targets. 

Hull at the ICT Conference

Talking Pi

Talking Pi

Today Mike and I took a bunch of Raspberry Pi systems to a teachers conference for the day. Great fun. Particularly if, like me, you contrive to arrive just after all the machines have been carried in and set up. Actually we have got this off to a bit of an art now. We have a kind of Pi road show which consists of a bunch of Ikea bags containing the monitors (the heavy bits) and a couple of boxes with all the other parts that we need to run the systems. Anyhoo, we set up shop and then talked Scratch, Python, Hardware and the philosophy of education and the role of teaching programming.

Then we packed it all back into Mike's car boot and left.

If you want to find out what we were talking about, and get notification of any new courses that we are running in the future you can sign up for our newsletter at:

Careers and Networking Event Fun and Games

Warning: This picture contains images of some students in suits...

Warning: This picture contains images of some students in suits...

We had our first ever Student Careers and Internships Networking Event today. I don't think it will be our last one. Before today I was only really worried about three things: No employers would turn up, no students would turn up or nobody would enjoy the event. Turned out that things went really well on all fronts though. We had plenty of folks and they all seemed to have fun. 

The audience makes ready for the start..

The audience makes ready for the start..

We started with presentations from six companies based in the area. I think the students who had come along were extremely surprised and impressed by just how much goes on around here. And the employers seemed to be very impressed by our students. Which was nice too.

Of course I took some pictures..

Get your business cards and delegate packs here

Get your business cards and delegate packs here





I ran a tiny "Mug Survey" at the end (fill in a little evaluation questionnaire and swap it for a departmental mug) and the results were very positive. And everyone thought we should run the event again next year. So we will. And one of my worries for next time will probably be "Is the venue big enough...."


Spent a big chunk of the day in the garage. In the "Good Old Days" (tm) a garage was somewhere you kept the car. Nowadays it seems to be the place where you keep the family collection of empty cardboard boxes,bits of wood that at one time you thought you might have a use for and things that the kids once played with.

Anyhoo, I've filled the skip with stuff and covered myself with dust and nostalgia. Next stop, the loft.......

Of Garbage Man and Banjos


This year the first year students can create a game as part of their programming coursework. The game is "Alien Banjo Attack" and above you can see a screenshot of my demo version. At the top are various different types of evil banjo and your mission is to defend the earth using nothing more than your accordion which will shoot notes of music to destroy the incoming swarm.  If the banjos reach the bottom of the screen you lose the game. If you crash into a banjo you lose a life. Space Invaders with a banjo feel. What's not to love?

I want there to be loads of objects (notes, banjos etc) on the screen at the same time, which means a lot of instances of the various classes that represent the game objects. There has been some discussion about the best way to handle this, as banjos are destroyed and new ones appear.

I reckon the best way to do this is to make a banjo stateful. The banjo will contain a flag to represent whether or not it is involved in the game. If a banjo is destroyed this flag set to indicate that it is dead and the banjo plays no further part in the gameplay. When we need a new banjo we just have to find one which is marked as dead and "resurrect" it by moving the banjo to a new position and then changing the flag to bring it back to life. 

You might think that creating new instances of banjos to replace discarded ones would be another way to achieve this behaviour but I don't like that at all. If we start creating and destroying objects this will make work for the Garbage Collector who will have to come in and tidy up memory every now and then which might slow things down a bit. 

Another way to reuse objects would be to keep a list of "dead" banjos. Each time a banjo is killed we move it out of the "active" list into the list of dead ones. That way, if we need a new banjo we just have to look in the list. This is a bit more complicated than just searching for a banjo that can be resurrected, but it does have the advantage that the game never wastes time working through "dead" display objects, as these are no longer in the active list.  Many operating systems use this technique in what is called a "thread pool" where previously used threads are kept ready for use by processes that might need them.

Phil and Stuart talk iPlayer Transcoding

Phil Cluff and Stuart Hicks getting ready for the off

Phil Cluff and Stuart Hicks getting ready for the off

We love it when ex-students come back to the department to tell us what they've been up to. Phil Cluff graduated a few years ago and Stuart Hicks a couple of years after that. Since graduation they've both been working for the BBC on the iPlayer team.

If your'e not from the UK you might not appreciate just how wonderful BBC iPlayer is. It lets you consume BBC TV output on any device, in any place. All the output of the BBC channels, plus the content from BBC local TV, is made available shortly after broadcast so you really don't have to worry about missing things. The programmes are available for a number of days after transmission and they are also made available for download. It's awesome. Phil and Stuart  told us that 3% of the consumption of BBC output is now via iPlayer and it is growing rapidly. There have been around 28 Million downloads of the iPlayer apps across the various platforms,  they get around 10 million requests a day and release around 700 hours of new content a week.  Amazing stuff. 

Of course, getting all that content onto the internet is a tricky job. The original content has got to be converted into the different video formats and sizes that are consumed by the users, and this must happen as soon after broadcast as possible. Nobody wants to have to wait until tomorrow to see today's news. There are huge peaks and troughs in demand and this makes it tricky to manage the computing resource that you need for the task.

A little while back the BBC decided to move their transcoding (as this is called) activities into the cloud. Phil and Stuart described the cloud as "A collection of services that someone else runs for you, which lets you not care about hardware". Which is just what the BBC needed. So they put together a project to build a cloud based "Video Factory" from scratch in 18 months. And they did it. 

Large computing projects are notable for failing or being expensively late. The Video Factory was neither of these things. Phil put this down to the way the design was based on a number of small components, each of which performs one step in the process of getting the video into your iPhone or whatever. The workflow of the video data through the system is managed as a series of messages that are passed from one component to each other. Components take messages out of their input queue, perform their part of the process on the message and pass it on to the next component.  If things get busy and queues start to fill up the system can "spin up" extra processing resource in the form of further servers in the cloud which can run components to work on the extra elements. 

And because each component has very well defined inputs and outputs this makes testing much easier. Phil and Stuart talked about Behaviour Driven Development, which is where you express what you want to achieve in terms of business outcomes. They used a language called Cucumber which lets you express your requirements in a really easy to understand way, and will also produce a whole framework of tests you can use to prove the solution. This is very, very interesting stuff.

It was great to see Phil and Stuart again. It looks like they are doing very well. It was also really nice to hear them echo a lot of the things that we tell our students during the course.  They had some very useful things to say about the craft of development. You can find the slide deck of their presentation here. I strongly advise you to take a look at the last few slides, there are some lovely references there that you can use to find out more.

When water turns bad...

I have a love hate relationship with water. It's great for some things and I understand that it is one of the primary components of Strawberry Flavoured Milk, but I don't like the way that it lurks in my loft looking for a way out. Tonight I discovered that it had found one, courtesy of a leaking pipe connection to our cold water tank. 

I noticed this just after a shower (good water) when I found that some of the pipes in the back of the airing cupboard were damp (bad water). For half a second I managed to convince myself it was condensation, but then reality set in and I had to go up the ladder and take a look. And there it was. 

Fortunately I've got to the stage in my life where I have a collection of suitably large and scary spanners to hand which can be used to tighten things up a bit and so for now I think the leak has been sorted. And there is a Lego bucket (that is a bucket that used to contain Lego not a bucket made of Lego, that would be silly) underneath the offending joint just in case of future problems. 

The good news is that most of the water had traveled straight down the outside of the pipes towards the airing cupboard, and evaporated on the way. The bad news is that some of it stopped off in the cupboard above to ruin some bedding that we had put there. 

Oh well. At least it stopped me having a boring evening playing with computers.....