Monday 12 May 2014

Welcome to ThoughtWorks Subscribers!

You may have come to this blog from my article just published on ThoughtWorks' Insights page, "CoAP and a Web of Things Watching Things". Welcome!

This blog is actually my ThoughtWorks 60-day Internet of Things project - my main blog is "What Not How". I summarised my progress in this project after 30 days and after 60 days. These two pages briefly describe, and link to, each day's page for the preceding month.

There are three main articles to read here that explain the Object Network approach to the Internet of Things:
I also have three articles that mention CoAP:
You can contact me on Twitter if you want to discuss anything about what you see here or on my main blog.

Friday 14 February 2014

Moving off Blogger..

This is my last post on this blog. Blogger and Google have been a bit of a disappointment, so this seems like a good time to wrap up and find an alternative.

What I want in a blog service:
  • bug-free editor - I don't actually need WYSIWYG if it's that hard to do; HTML would be fine
  • reliable server to save mid-edit to, and which doesn't push down the whole page - that I'm in the middle of editing - with a message telling me that once again it failed to auto-save
  • a preview with links that work, so I can test them there
What I want from Google's search services:
  • if they run a service like Blogger, they should put the pages from it in their index, preferably when they're published
  • for "" to work
I'm also looking for alternatives to Feedly, the feed reader that pulls in new pages in less than a second, but then stubbornly refuses to acknowledge updates from then on.

You don't know what you do want, until you know what you don't want. I now know more about what I want. So thanks, Google, for that!

And for giving me a free blog, which wasn't so bad, really.

Thursday 13 February 2014

Concluding my 60 Days of Things

I'm now nearly at the end of my 60 Days of Things. As I said when I was half-way: "I started this blog on the 14th of December last year, without intending to blog every day. But I happened to have something to say every day, and once I'd established that regularity, I decided to keep it up. I do have rather a lot to say about the Object Net, and my other blog is full of me saying it in long posts. This way I get to write shorter posts, yet more often."

It's been a lot of fun, doing the coding and hardware stuff and writing these posts. I almost never knew what I was going to write as I sat down every evening, but never once failed to find inspiration.

So here's another summary in two parts. First, what I achieved for NetMash:

Rather more articles in the "general" category this time:

I also went on a short trip to Venice. and linked to some snaps.

I'm not sure if I'll continue the pleasant discipline of daily blogging, now that my 60 days are up, but I do hope to.

I'll certainly keep blogging on the Augmented Reality Internet of Things manifested by the Object Network.

I've only just started...

Wednesday 12 February 2014

Amazing Innovation at Raspberry Pi and Arduino Meetup

Tonight I attended the Surrey Geeks Meetup in the lovely offices of the generous Kyan in Guildford. The topic was essentially anything to do with Raspberry Pi and Arduino.  There was some pretty innovative stuff being talked about.

The organiser, Jon Nethercott, kicked off talking about the Arduino boards and the projects he had constructed, including an amazing capacitance meter that required no additional hardware. You could push a capacitor into two A-D pins and the display shield would quickly tell you what value it had, from 1pF up to hundreds of uF.

It has two ways of calculating the value: from 1pF to 1nF it measures the ratio of the capacitance of the test capacitor against the residual 25pF capacitance of the internal circuitry! I've done a lot of electronics in my early life (really early life - I built my first computer in 1977 using the 1802 CMOS microprocessor), but I've never, as far as I recall, had to work out the voltage distribution of two capacitors in series!

Jon explained it to me, and it actually works out quite intuitively - the bigger capacitor develops the smaller voltage, as from an electron point of view, it is similar to a lower resistance, as it has more "space" for electrons to flow into it.

Above 1nF, which is very large relative to the 25pF residual capacitance, Jon switches to an alternative technique using an internal pull-up resistance to charge the test capacitor, then measure the developed voltage and time taken to reach it. Once again, not a scrap of extra external circuitry since it relies this time on an internal resistance. Cool.

Related to the work I've been doing, Richard Jelbert showed us his Pi for cars with a BLE beacon attached. This could be used to drive an app on the driver's phone to pick up a small number of events broadcast from the Pi, including from sensors. For example: when the driver enters the car, starts it, stops it .. or crashes it! This could be used to reward clean drivers with lower insurance, without any inconvenience to the driver, who otherwise has to keep messing with the app controls at the start and end of the journey.

Richard also showed us his prototype for a Bitcoin vending machine. Seriously: a Bitcoin vending machine. You put in some cash and get a printed slip with two QR codes on it: the public and the private key for your entry on the blockchain.

My colleague in government and another meetup organiser, David Carboni, told us of his plans to enhance local neighbourhood safety with an automatic number plate recognition system. Every participant in a street would have Pies tracking cars via its camera. They could share the information to track stranger cars. The approach would involve quite a bit of image processing to normalise the image then extract the characters. There is this software which may be interesting to look at.

Next up, a Research Assistant from Guildford University, James Mithen, told us of his plans to get into ARM code and write another operating system for the Pi, as a fun exercise...

Finally, I stood up and told everyone about the Augmented Reality Internet of Things idea, with a mention of Minecraft house-modelling to get them all thinking I'm a nutter. It worked. They did.

We all talked more than we hacked or wired, which was great - and there's always next time to play with kit.

Really exciting stuff. And great pizza and great beer. Thanks to the organisers and hosts.

Tuesday 11 February 2014

Seamlessly copying data between adjacent machines

This morning on the train I wanted to work on a document that was in a draft email that I could access from Google by 3G on my Android phone. But I wanted to work on the document on my laptop, which doesn't have 3G.

After my 25 minutes journey was done, I still hadn't solved the problem - how do I easily and reliably move data from the device in my hand to the one six inches below it?

Even the fact that I had to think about all the ways means it's just not something you do in any instinctive way.

I'm not asking for answers, by the way, I know about all the options (Bluetooth, hotspot, tethering). It's their reliability and ease of use that's part of the problem.

On the way back, there was a massive video advert in Waterloo station for the Audi car company. It said (I think; I was rushing past) "Number of Audi drivers in the station: 4567", and it was slowly incrementing. I presumed that they made that up - it seemed high - or used Twitter or something.

Then I thought, well, it'd be fun to offer iPhone-using Audi drivers an app which could be a beacon saying: "I'm an Audi driver!". Then if they were told to walk past the advert, well, you get the idea.

These two incidents got me thinking about commodity technologies for easy and reliable proximal data exchange.

And it's really still too hard to seamlessly move data between machines and devices that are right next to each other!

In our workplace, faced with the need to get a file from one PC to the one next to it, even techies have been known to send the data across the Atlantic via the US, because it's easier to email it thousands of miles than figure out a direct route of three feet.


I've listed some commodity wireless technologies already: Bluetooth, Wifi and Mobile data. You could add QR codes, NFC and RFID to those, of course, but they are still less common.

Now I've got a low tolerance for poor usability, but surely everyone hesitates before considering the buggy and unreliable, and cognitively complex Bluetooth approach. I can't even think how I'd do it, to be honest. I know it involves some kind of "pairing", and lots of failed transfers.

Wifi requires you to be logged in to a network with complex passcodes, and even then you'll probably need to play with IP numbers to do local file transfer.

Mobile data is not always available, is slow and unreliable when it is, and requires some or other proprietary intermediary.


So, back to the Audi example: what if it was as easy as (a) being near and (b) setting the intent to share something, anything?

I should be able to pull up the draft email I had on my phone, hit "Copy to adjacent device .." and enter a 3-digit number (to prevent others being able to see it casually; say only one transfer is possible and it times out after a minute, to make it even more secure).

Now if I hit "Look for local data" or something on the other machine (laptop), I just need to enter the 3-digit number and it's there in seconds.

Similarly: PC #1: right click on file "Copy to adjacent device .. ". 3-digit number. PC #2 "Look for local data". 3-digit number. It's there.

The 3-digit number would be all you needed to confirm the particular transfer, perhaps when others were active around you, you wouldn't need to see or choose the filename being offered or anything.

I should be able to pull up a photo of myself that I use in public, or enter details into a profile document - including the car I drive - the hit "Publish to adjacent devices ..". No 3-digit number this time, of course. The peer device will "Look for local data" and suck it all in, then filter out the interesting stuff to stick up onto that 12-foot screen.

That should be built into every single smart device we use.

We could implement it in BT 4, WiFi Direct, whatever. It just needs to always be there, always work, and be that simple.

Monday 10 February 2014

Seven uses of the Raspberry Pi Camera

My Christmas Pi came with a 5Mp (2592x1944) f/2.9 camera module, which I intend to use as my light level sensor. I also want to use it to detect the colour of the ambient light, so that my light Things can match it.

Further along, I expect I can use it for motion detection and to recognise QR codes, car number plates and faces. And to take pictures; almost forgot. But, baby steps..

For light level and ambient colour temperature, I'd need to point the camera at a sheet of white paper.

The challenge I face is to arrange one of the following:

(a) get the exposure - which I presume corresponds to shutter speed in some way, as it's a fixed aperture - and AWB colour value, set in the EXIF

(b) disable auto-exposure and auto-AWB, and do my own sampling of the exposure to find out how much light there is, then take the average colour of the image.

(c) get the exposure and disable AWB or vice-versa, depending on the EXIF

I've been looking at the documentation and sources for information today, but it's quite hard to find what I want. For option (b), I think --shutter and --awb should allow me to set the series of shutter speeds and to turn AWB off, respectively.

It's possible that I need to do (c) - there's something in the EXIF called Light Value but I can't see a colour temperature parameter.

On Wednesday, a group of us are getting together to hack some stuff, so perhaps I'll experiment then.

PS The title today is a dig at those awful traffic-hunting titles you see these days..