Connecting a Wifly shield to an Arduino

I’m trying to make a more mobile version of my ‘remote control’

which connects to the web in order to send commands. My first version was with a Nanode with built-in ethernet, but I also have a Arduino Duemilanove ATmega168, so I thought I’d try that with my new Wifly shield and a battery pack.

The Wifly shield is this version and I have some stackable headers to go with it. I connected the shield on top of the Arduino like this:

You can see that the USB socket means that the shield is a bit high up.

I downloaded this version of the Wifly library that’s been recently changed to work with Arduino 1.0 Library. All connected up, and running this code from the examples:

#include "WiFly.h"

char passphrase[] = "pass";
char ssid[] = "ssid";

byte server[] = { 66, 249, 89, 104 }; // Google

Client client("", 80);

void setup() {



Serial.println("finished beginning");

if (!WiFly.join(ssid, passphrase)) {
Serial.println("Association failed.");
while (1) {
// Hang on failure.


if (client.connect()) {
client.println("GET /search?q=arduino HTTP/1.0");
} else {
Serial.println("connection failed");


void loop() {
if (client.available()) {
char c =;

if (!client.connected()) {

it was hanging on Wifly.begin().

After a bit of hunting round I found this detailed description of what might be up – essentially a timeout, and then twice only, while I was fiddling with the headers, SpiUartTerminal.pde worked.

The rest of the time it just hangs on this:

Attempting to connect to SPI UART...

So really I’m looking for a bit of advice – I don’t really want to solder it on, but are there better ways of connecting the shield to the Arduino? Are headers typically less reliable than soldering? Is there a better way to connect the shield somehow maybe using a breadboard? (e.g. like this). Or am I just doing something daft …?

UPDATE: Thanks to John (see comment below) I sorted out the problem, which was a newby issue: stackable headers need to be soldered! Anyway I persuaded Damian to solder for me (I’ve never done it before) and we now have a working wireless, battery-powered remote control:

(All it does is send the category to a http web service and that randomly chooses an item from all iPlayer available items in that category, and sends it to a web page connected with XMPP).

Thanks everyone who helped. I’m very pleased with it :D

Nanode / twitter blink example

Here are some notes on my adventures trying to make an ethernet connected Nanode that blinks when certain words are mentioned on twitter. I was working with Mac OS X and there were a few gotchas, so I’ve mentioned them here so I don’t forget and in case anything is useful to anyone else. There’s an exciting video of the resulting beast here featuring the acrylic case from the excellent and fast SKPang. The code (an unholy mixture of C++ and Processing) is here. I was coming at this as someone who’d previously only got blinking and similar going on a Arduino Duemilanove.

Getting the Nanode working

  • Buy a Nanode (ethernet Arduinos are also available, I chose a Nanode because it was recommended to me, also their support is very good and it arrived very quickly. I think in retrospect it’s a bit hard to use for a real novice like me, though I enjoyed finding out…). I got a prebuilt Nanode RFX (which has a Hope RF shield and a microSD slot). You need to also buy a Programming Adaptor, which you need in order to talk to a Nanode as the USB programming interface isn’t built in.
  • Download the Arduino IDE
  • Install the FTDI driver (see this comment, which helped me out a lot) – installing it will restart your computer. This is a different driver to the one you use with a standard Arduino – see the Arduino guide if you’re not using a Nanode
  • Open the blink Arduino example (under file -> examples -> Basic, or here) and change the output to 6
  • Connect the Nanode to the Mac using the FTDI cable using a USB cable
  • In the IDE, set the port to the new driver and the board to ‘Arduino Duemilanove with ATMega 328′
  • Compile and run the Blink example on the Nanode
  • The default LED on the Nanode should blink
  • Celebrate

Connecting up Ethernet

  • Install Ethernet Library -> cd ~/Documents/Arduino; mkdir libraries
  • Download EtherCard library and unzip it in this directory
  • Restart the Arduino IDE and you should see sketch / import library – a new library (not Ethernet but EtherCard at the bottom)
  • Start a new sketch
  • Next I copied and pasted this WebClient example from EtherCard into a new file, and that formed the basis of my code.
  • Click on sketch / import library – and import EtherCard – and it puts some import statements at the top
  • Add this at the top: #include <stdint.h>
  • Connect it to an ethernet connection (e.g. I shared airport to ethernet connection on my mac)

The one problem I had was that it appeared to work intermittently, or once per restart of the board. I think this must have been some sort of race condition. Anyway, I solved it by adding a tiny wait after these two lines:

void loop () {


 delay(100); //<--  add this.


If you look then at the serial monitor (button with the little magnifing glass on the top right of the Arduino IDE), you should see some results. Click restart on the Nanode if not. It takes a while to get the IP address.

A couple of useful links:

A node.js bot in XMPP

Yesterday Danbri and I invested a few hours in a rapid node.js prototype for NoTube. We’ll blog about it properly elsewhere, but this is just a little note about a bit of curious behaviour we found, in case anyone runs into the same problem.

Just before christmas Dan made a node.js xmpp bot that could appear in N-Screen and take commands via drag and drop (if you don’t care about this, the point is that it uses node.js with node-xmpp). Dan got it showing up in the N-Screen interface and reflecting back whatever you dropped on it. I thought it would be trivial to hook in one of the item-to-item recommenders I have working via a json http api. Basically to do http GETs in node.js you need something like this:

var http = require('http');

var data_client = http.createClient(80, "");
var request = data_client.request('GET', '/iplayer_dev/api/suggest?pid='+pid', {'host': ''});

request.on('response', function (response) {
var myStr = "";
response.on('data', function (chunk) {
console.log('BODY: ' + chunk);
myStr += chunk;
response.on('end', function (response) {

Then you can parse myStr e.g.

var j = JSON.parse(myStr);

What we wanted to do was send that myStr as a string content of an xmpp message like this:

var cl = new xmpp.Client({
jid: jid + '/bot',
password: password

cl.on('stanza', function(stanza) {
var msg = { to: stanza.attrs.from , type: 'chat' };

... get myStr of recommendations based on that message

cl.send(new xmpp.Element('message', msg ).c('body').t(myStr) );

It really should have been simple, but in practice the myStr existed when printed out to console but was never sent. At first we thought it was something to do with Buffers – if you don’t do response.setEncoding(…) you get Buffers back and perhaps some stringification of those wasn’t working, but no. To add to the confusion we could create Json objects from the string but they still would not send, even if copied to new strings.

In retrospect it’s obvious it was the XMPP that was the issue, but it took line by line trial and error sending of some sample input before I found it: & characters in the input were causing silent failure when the message was sent – presumably due to an XML parsing problem that for some reason didn’t show up as an error (I know almost nothing about node.js so there could have been some user error there too). Escaping these & didn’t seem to work, so for now we’ve just removed them and it all works fine. We need to raise a bug report, but thought I’d blog for now in case it helps anyone else. The code is here.

Archiving a Mediawiki Installation

NoTube uses a Mediawiki installation kindly provided by for its internal documentation. As the project draws to a close (we finish officially on January 31st 2012, with our final review in late March) we wanted to make sure we had a copy of everything we had done over the last few years. Much of this is and will remain private to the partners but there are some interesting ideas and usecases we wrote down early on that we don’t want to lose track of. I hadn’t realised that by default Mediawiki has an API, but once I did, it was pretty simple to download all the pages. I’ve put the Ruby script on github in case it’s useful to anyone else. Basically the only fiddly bit is the cookies. You do, of course, need a username and password for the wiki you want to download, but thereafter, there’s an API call you can call recursively to get a list of all pages, and then download them individually.

Web [on|and|in|for|with|via|through] TV Workshop

In September I participated in the programme committee of the W3C’s Web On TV workshop, which was held in Japan. Because of some existing committments I was not able to go to the face-to-face meeting, so to try and make up for it, I read through all the papers instead of just my allocated ones. My notes are below. These are just my personal opinions, and I’m not an expert in the TV field (although Web and TV is my thing – I work on the NoTube project). All the papers are public. There is also a Draft Web and TV Interest Group Charter. The title of this post is stolen from danbri who was pointing out that Web AND TV need not be Web ON TV.

These reviews are very short – most of the papers are themselves very short, being expressions of interest. In some cases I just use a representative quote from the paper. The attempt here is to summarise not to evaluate them, though I indicate where I am interested in a particular topic. The workshop summary is here.


A large group were interested in BML and explaining why it’s important, perhaps indicating that they do not see a reason to change from using that.

A group are interested in HTML5 and how it might work with BML for interactive applications, and a subgroup interested in user interfaces for TV and common UIs for TV and other devices using HTML5.

There is an overlapping group who see the TV as being a hub for home entertainment, which seems to mean that everything is controlled via the TV, web pages are viewed on the TV etc.

There is also a group interested in APIs for TV and other devices (such as controls).

There is a strong sense that IPTV is very important and standards for it are important, especially DRM and efficiency.

I get the impression that there are a lot of participants who have specific scenarios in mind and also a number who are looking for interesting aplications of HTML5 to TV.

Papers 21 and 27, 30 are the most interesting from my point of view. 31 makes an important point. I’ve a lot of sympathy with 36. 39 and 41 are also interesting.


1. Shinichi Matsui (Panasonic)

Would like to attend in a personal capacity. His view is that “TVs are the most important components, not only for displaying contents, but of “Ubiquitous Home Appliances” which will evolve to “Web Appliances” surrounding consumers.”

2. Tatsuo Matsuoka (Innovative IP Architecture Center, NTT Communications Corporation)

They have made an IPTV service. They are interested in what functions are done by different devices and APIs, and IPTV standards and DRM.

3. Katsuhiko Kageyama (Hitachi)

Interested in consumer electronics: user interfaces for TV especially HTML5 capabilities, control and communications between devices.

4. Sunghan Kim (ETRI/W3C Korea Office)

Interested in the relationships between devices, and content provision, e.g. start watching on one device and continue on another, and the various W3C and other standards that could be employed to make it happen.

5. Wayne Carr (Intel)

Interested in HTML5 as a way to provide web experience across a range of devices, TV in particular.

6. Masakazu Muraoka (

Interested in APIs to TV and HTML on TV.

7. Aaron Zhang (Huawei)

They are an IPTV provider and suggest an architecture for improving the user experience of the web on TV (avoid bad UI experiences of early PCs)

8. Masakazu Kobayashi (KDDI)

Interested in HTML5 as a common interface to Web TV, avoiding situations such as the different standards for e-books.

9. Yusuke Kawabe (NTV (Nippon Television))

Would like to talk about BML and the usecases for it, and see what any new usecases are.

10. Hidekazu Bunne (TV Asahi)

As (9)

11. Tomokazu Yamada (IPTV Forum)

Would like to talk about IPTV, specifically DRM and EPG metadata, and have some usecases to share.

12. Tatsuto Murayama (NTT)

Describe their requirements for HTML5:

“1. Layout optimization with reflowable materials
2. Requirements for vertical writing/reading and ruby annotations
3. HTML5 widgets as containers for digital books”

Seem most interested in digital books, but also talk about easy to use layout optimisation on TV screens.

13. Koichi MARUYAMA (NTT Cyber Solutions Lab.)

Interest is in a markup language for IPTV with
” – Easy multimedia description like BML/LIME
– Interactivity as rich as that of native application
– Service integration and linkage for multiple devices”

Social networking, performance and DRM are their main interests.

14. Limin Yu (DragonTec)

They have developed a BML IPTV browser and next are doing a LIME browser. They would like to demonstrate their browser. They are interested in standards suitable for the chinese market. They think that W3C technoloigies have potential for interactive TV.

15. Shigeru Owada (Sony CSL)

Interesting ideas of devices as ‘fairies’ that can communicate with each other and that humans can communicate with. “We are interested more on fun usage of ubiquitous home network than protocol layer implementation”

16. Yoshikazu Seki (Fuji Television)

as (9)

17. Kazunori Tanikawa (NEC)

Interested in IPTV, scenarios, and the potential of HTML5.

18. Kenji Sugihara (TV Tokyo)

Similar to (9) especially for broadcaster controlled interactive appliactions using BML.

19 is missing

20. Hiroyuki Aizu (Toshiba)

Would like to show some usecases of HTML5 on TV as the hub within a hiome network, and some ideas about communication technology and TV.

21. Shuhei Habu (Allied Resources Communications)

Interesting usecases and a proposal for privacy for TV in HTML5 based on BML and APIs for TV.

22. Kenji Fukuda (Wowow)

Similar to (18)

23. Jan Lindquist (Ericsson)

A member of the Open IPTV Forum (OIPF) standardization group who woudl like to talk about his experiences in standardisation in the subgroup responsible for the web latform (javascript, embedded video).

24. Yoshiaki Ohsumi (Panasonic R&D)

Interested in possible future usecase and smarter integration of TV and web technologues; TV as a hub.

25. Ishidoshiro Takashi (Melco)

Make TVs and perpherals. Interested in the future relationship between BML and HTML5 and traditional over the air and HTML5 and from the user’s point of view how to improve the experience.

26. Keiya Motohashi (NHK)

Interested in public service usecsaes such as disaster information, BML and interactive applications, connecting TV with the web.

27. Hyojin Park (KAIST)

Researchers on TV. Interested in device APIs for the browser to control the TV, architecture and standards to allow appropriate UIs for different devices.


The paper is about BML, which is a markup language widely used in Japan and is ‘is basically an extension for existing Web standards, e.g., XHTML 1.1′.

They would be able to provide usecases and are interested in seeing how TVs will become more of a hub for entertainment in the home, and how these changes fit with html5.

29. Makoto Nishimura at Cisco Systems

“Our interest is the integration of LIME and HTML5 on to our video products such as IP-STB, RF-STB and other related solutions.”

30. Hiroshi Omata (

They have made remote controls from mobile phones and are therefore interested in devices APIs for TV. Also interested in standardising HTML5 for TV.

31. Naomi Nakamura (ACCESS)

Think that people don’t use TV but watch it – i.e. lean back exterience; therefore new usecases will need to be thought through that accept this.

32: Tatsuya Igarashi, TDG, Sony Corporation

Again interested in the TV as a hub for home entertainment and integrated web technology; interested in HTML5; provide usecases.

33: Shozo FUKUI, Tomo-Digi Corporation

They would like to explain why BML was useful, explain the diffrence between BML and HTML5 and have several usecases to discuss, including extensibility in the future.

34: Tatsuki Matsuda, NTT-Resonant Inc.

They would like to join the workshop, but don’t offer a paper – they are provders of web portal services and would like to be able to integrate with TV services.

35. Masahito Kawamori (ITU-T)

From ITU-T: would like to present their experiences standardising for IPTV: declarative languages, Lua, SVG, ECMAscript.

36. Charles McCathieNevile (Opera Software)

Proposes concrete steps (e.g. testcases) for ensuring “use of HTML on TV [is] more closely aligned with its usage in general”, and that this should happen in W3C or in close colaboration with W3C.

37. Daniel Park (Samsung)

“We are supporting on developing best practices and guidelines for Web on TV as well as easy of connection with other Web-capable devices from Web application.”

38. Diot Christophe (Technicolor)

They can help bring the views of services providers and content producers to the table. Interested in web on TV applications, why HTML5 not CE-HTML.

39. Asanobu Kitamoto (NII)

Describes the concept of ‘Bayesian TV’ – not just TV on the web or vice versa, but a personalised push system, rather than the pull of the web, with recommendations and user interactions.

40. Manabu Shimobe (UIEvolution)

“we are very interested in contributing to defining the additional standards needed for smarter integration of web technologies and broadcast services” particularly user interface aspects.

41. Kiyoshi Oura (Airframe)

Interesting points made – the only one to mention advertising – describing some of the different watching scenarios of the future including different devices. Interested in HTML5 and the potential for continuing enolving of content, especially flexible data storage mechanisms.