Catwigs: A conversation with your project


Catwigs is a project which started at Bristol Hackspace. I’d been complaining that some of the ‘user scenarios’ that people like me work on can end up being wildly unrealistic (“As a user, I’d like to spend more money on goods and services” or “As a user, I’d like to use technology ‘X’ [insert current technological enthusasm of participants here]”).

One very direct, sensible question to ask about an idea is “does it actually solve a problem?”. If it doesn’t, why are you doing it? Valid reasons include “to have fun” or “because I like it”, but what if they’re not there? Like wigs for cats, many ideas do not solve a problem. Cats don’t need wigs.

It seems very easy to go through the motions of working out why people might want the thing you are making, without actually thinking very deeply about it. Richard Sewell and I were talking about this, and at Hackspace and over email in the next few days, we started to think of other things that people may fail to take into account. For example, how are people going to find the thing?


Is it going to be easy to use?


will people come back to it?


is it the right thing to do now?


and hang on, what on earth is it?


(you’d be surprised how difficult that question is for a lot of projects).

We spent quite a bit of time thinking about how to express these ideas. Here’s an excerpt from an email from Richard in August:

“Or a small set of real-world comparisons – so Entertaining gets ‘Tax return’, ‘Sitcom’,
‘Fireworks’. Solves A Problem gets ‘Cat wig’, ‘Garage door opener’, ‘Antibiotics’.
Something like that.”

(‘Catwigs’ is an obviously great name, and perfect for this project, though we didn’t realise at the time that catwigs are an internet thing)

Catwigs then, has become a checklist of things you might have forgotten to think about for your project. The instructions are to create an analogy between your project and the given card. So for example, for this one:


You are asked to argue how how your project is similar to one of the three items on the card. Let’s say I’ve got a great idea for a new start-up, penFinderLE, which bluetooth-LE-enables your biros so you can always find them. Does it solve a problem? well, occasionally, for a few forgetful people with a lot of pens, a lot of money and an interest in technology, but it’s not going to solve a serious problem that affects millions of people. This line of reasoning makes it more like a garage door remote than antibiotics (perhaps even edging towards the uselessness of catwigs?) so we place the card roughly horizontally, maybe with the arrow facing slightly downwards.


Analogies take effort to make and so encourage you think about something you’re probably very familiar with in a different way. Arguing about the analogy with other people working on the project is even better, because it draws out any ambiguities and differences of opinion.

Analogies are quite time-consuming to think up though, especially if you’re you’re dusting off long-dormant drawing skills to illustrate them like I was, and so need to think of things you can actually attempt a drawing of. They are also difficult to scale (what’s half way between antibiotics and a catwig?) and hard to internationalise as they rely on commonalities in peoples’ ways of thinking.

Both of us are keen on the random, card-based technique of Brian Eno’s Oblique Strategies, so we made some cards. This is me testing an early version on themselves on the way back from EMFCamp:


The final piece – thought up by Chris Lynas at Hackspace I think – was to give them an obvious directionality, so that you could at least approximately judge the results of a catwigs session at a glance.


We tested them in a very rough form with people at EMFCamp and Hackspace, until we had a reasonable set of 22. We had these printed at Moo, taking inspiration from Giles Turnball’s excellent and useful “Strategies for people like me” (Now available to buy as

So, here they are. We’ve tested them on a bunch of people, both at Bristol Hackspace, at BBC R&D and in various pubs and over coffee. We think they’re useful towards the start of a project, particularly in a group, and even more particularly if there are potential problems with the project which aren’t being articulated. These are the instructions:

“Shuffle and cut the cards. Deal 7 or all of them.

For each card, choose the orientation that matches your project.

See which are obvious and which contentious.

Discard any that are irrelevant.

Reorder by priority.

Do you still like your project?”

The idea is to use them to have a discussion. A fun discussion, ideally. And to kill your project if you don’t like it any more, or to tackle any potential problems if you do still like it.

Richard and I would like to thank Bristol Hackspace and IRFS at BBC R&D, and many other
friends for helping us test and improve Catwigs.

Huffduffer / Radiodan Digression – NFC control

I’d like to be able to change the URL of the RSS feed using NFC (~RFID). This is a tiny bit of over-engineering, but could also be very cool. I have a couple of NFC boards I’ve been planning on playing with for a while.

One’s an NFC Adafruit shield for the Arduino. I thought it was a breakout board as in the instructions, and it’s a bit annoying that it isn’t, as I think I’ll have to have an arduino in the mix with the breakout board, and it won’t really fit in the box with all that stuff (plus I’ll need a chunky power supply). And it’s not the one in the instructions so it won’t be super-easy.

So I’m thinking I’ll try the other, which is a Raspberry Pi NFC shield. Unfortunately the code is binary…which I’m not keen on running without knowing what it is. Fortunately, it’s libnfc-compatible, which is why I bought it.

So I think:

  • attach the NFC shield
  • compile libnfc
  • try libnfc example
  • add to the radiodan code

Attach the NFC shield

A nice easy one first. Because mine’s a B+ I think I’ll have room to add some buttons and things to the GPIO later – it covers all the B’s GPIO ports, so I’ve removed by button cables for now.

NFC shield

I switched the Pi off first and then rebooted it. It seems happy enough and I can ssh in.

Compile libnfc

There are some instructions for compiling libNFC on the Adafruit site.

In a browser, go to

download zip
scp zip to the pi

cd Downloads
zip -r libnfc-libnfc-1.7.0
scp pi@radiodan-libby.local:

on the pi

mkdir libnfc
cd libnfc
mv ~/ .
cd libnfc-libnfc-1.7.0/
sudo mkdir /etc/nfc
sudo mkdir /etc/nfc/devices.d
sudo cp contrib/libnfc/pn532_uart_on_rpi.conf.sample /etc/nfc/devices.d/pn532_uart_on_rpi.conf
sudo nano /etc/nfc/devices.d/pn532_uart_on_rpi.conf
add to the bottom: allow_intrusive_scan = true
./configure --with-drivers=pn532_uart --sysconfdir=/etc --prefix=/usr
-bash: ./configure: No such file or directory

install autoconf

sudo apt-get update
sudo apt-get install autoconf

create configure file

autoreconf -vis

libnfc/ error: Libtool library used but 'LIBTOOL' is undefined
libnfc/ The usual way to define 'LIBTOOL' is to add 'LT_INIT'
libnfc/ to '' and run 'aclocal' and 'autoconf' again.

but configure does exist. hm


./configure --with-drivers=pn532_uart --sysconfdir=/etc --prefix=/usr


these instructions look better.

sudo apt-get install libusb-dev libpcsclite-dev libextutils-pkgconfig-perl
git clone
cd libnfc
git checkout libnfc-1.7.1
git clean -d -f -x
git remote|grep -q anonscm||git remote add anonscm git://
git fetch anonscm
git reset
dpkg-buildpackage -uc -us -b

dpkg-checkbuilddeps: Unmet build dependencies: debhelper (>= 9) dh-autoreconf libtool
dpkg-buildpackage: warning: build dependencies/conflicts unsatisfied; aborting
dpkg-buildpackage: warning: (Use -d flag to override.)

sudo apt-get install debhelper dh-autoreconf libtool

dpkg-buildpackage -uc -us -b

Thread model: posix
gcc version 4.6.3 (Debian 4.6.3-14+rpi1)
configure:3495: $? = 0
configure:3484: gcc -V >&5
gcc: error: unrecognized option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3495: $? = 4
configure:3484: gcc -qversion >&5
gcc: error: unrecognized option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:3495: $? = 4
configure:3515: checking whether the C compiler works
configure:3537: gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro conftest.c >&5
cc1: error: unrecognized command line option '-fstack-protector-strong'
configure:3541: $? = 1
configure:3579: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "libnfc"


Let’s try this again – don’t really need a deb package

./configure --with-drivers=pn532_uart --sysconfdir=/etc --prefix=/usr

appears to work

sudo apt-get install libusb-0.1-4 libpcsclite1 libccid pcscd

seems happy

sudo make clean
sudo make install all

Plug in NFC device, place a tag on it and test your installation


error libnfc.driver.pn532_uart Invalid serial port: /dev/ttyAMA0

hm. From earlier

Selected drivers:
acr122_pcsc...... no
acr122_usb....... no
acr122s.......... no
arygon........... no
pn53x_usb........ no
pn532_uart....... yes
pn532_spi....... no
pn532_i2c........ no

I tried this to free up the uart.

- and then on reboot I think the disk has become corrupt. Dammit.

Andrew’s got a better plan anyway, talking to it through the serial port.


Starting again with a clean install of raspian

sudo apt-get install libusb-dev libpcsclite-dev libextutils-pkgconfig-perl
git clone
cd libnfc
git checkout libnfc-1.7.1
git clean -d -f -x
git remote|grep -q anonscm||git remote add anonscm git://
git fetch anonscm
git reset

now, without the RFID shield plugged in, free up the UART.

sudo apt-get install debhelper dh-autoreconf libtool
sudo mkdir /etc/nfc
sudo mkdir /etc/nfc/devices.d
sudo cp contrib/libnfc/pn532_uart_on_rpi.conf.sample /etc/nfc/devices.d/pn532_uart_on_rpi.conf
sudo nano /etc/nfc/devices.d/pn532_uart_on_rpi.conf
allow_intrusive_scan = true

autoreconf -vis
./configure –with-drivers=pn532_uart –sysconfdir=/etc –prefix=/usr

sudo make clean
sudo make install all

disable serial comms in raspi-config

shut down
add the shield
start up

pi@raspberrypi ~ $ nfc-list
nfc-list uses libnfc libnfc-1.7.1
error libnfc.driver.pn532_uart pn53x_check_communication error
nfc-list: ERROR: Unable to open NFC device: pn532_uart:/dev/ttyAMA0

shut down, remove shield, restart (the latter was done already)

[repeated goes]


sudo nano /boot/cmdline.txt

dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait


dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait

sudo halt

reattach shield


stil same error, although it is detecting the card. I think maybe I’m using the wrong driver.


“The EXPLORE-NFC is not supported by the libnfc. The information in the product description is wrong. This board is supported by the NXP NFC Reader Library. The sources are available for download at [1].”


I later got it working with this:

print "Imported NXPPY"
reader = nxppy.Mifare()
print "Loaded mifare device"
currentId = None
while True:
uid =
if(currentId == None or currentId!=uid):
currentId = uid
print "New card ID:" + currentId

Hufferduffer Radiodan part 4 – server side Radiodan API and buttons

Server side calls

Andrew has been helping me with server-side radiodan calls. I was close with this commit but this:

radiodan = require('radiodan-client'),
radiodanClient = require('radiodan-client'),
player = radiodan.player.get("default"),
player.add({ clear: true, playlist: url});

should have been:

player = radiodan.player.get("main"),

‘main’ is specified in the config file – you can set your own name for the player, but using this means that you don’t have to touch the (shared) config file (which is here)

Andrew also used cheerio for jQuery-like XML parsing rather than my hack-parsing.

The full API is here, but those docs need updating.


On button

Andrew suggests I just put my button handling code in main.js for now. The code itself is just copied from here, and at the moment we only want it to print something to console with a press of the button. Here’s the commit.

We also need to add the buttons code to monit:

sudo pico /etc/monit/conf.d/radiodan-type-huffduffer

add this at the end:

check process radiodan-buttons with pidfile /var/run/radiodan/
group radiodan
start program = "/usr/sbin/service radiodan-buttons start"
stop program = "/usr/sbin/service radiodan-buttons stop"

sudo monit reload

tail -f /var/log/radiodan-huffduffer.log

and we see "powerButton PRESSED"

[later] Thanks to Andrew it works very nicely, playing when the box is opened, and pausing when it’s closed. The code is here and we’ll use it as fodder for a proper tutorial. I am *well* chuffed. Thanks Andrew.

Here’s the result in action (video).

Huffduffer Radiodan part 3 – using the switch with Radiodan code

Yesterday I got a microswitch working – today I want to make it turn on the radio. Given that I can only start my podcasts in client-side mode at the moment, I’ll have to bodge it a bit so I can actually see it working (Andrew is going to help me understand the server side API better tomorrow).

So my plan is to

1. Switch back to the radiodan “magic button” radio
2. Make my switch replace the default on button
3. Make my switch turn the radio on when it’s open

and if I have time

4. attach a simple rotary encoder for volume
5. attach an RGB LED for the status lights

For the magic button radio, we have had some simple PCBs made to make the soldering easier for two RGB LED-rotary encoder-buttons, but it doesn’t fit in my new box, and anyway, I want to see how difficult it is without the PCB.

It’s 3pm now and I have about an hour free.

Switch back to the radiodan “magic button” radio

This is easy. I’ve sshed in and do this:

pi@radiodan-libby ~ $ sudo radiodan-device-type

Current device type: radiodan-type-huffduffer
Device type required. Valid types radiodan-type-example, radiodan-type-huffduffer, radiodan-type-magic

so I do

pi@radiodan-libby ~ $ sudo radiodan-device-type radiodan-type-magic

and reboot

Once we’re back up, if I go to http://radiodan-libby.local I should see the full-fledged radio interface, but I don’t, I just see my Huffduffer one.


I guess I messed up Monit or rc.d. Looking at ps ax | grep node, both versions are running.

looking at ls /etc/rc*.d

radiodan-huffduffer is in there but not magic, so I remove it from rc.d

update-rc.d -f radiodan-huffduffer remove


and that fixed it.


I’m testing it by doing

sudo radiodan-device-type radiodan-type-huffduffer


sudo radiodan-device-type radiodan-type-magic


to check I’ve got it switching properly, and it is.

ps ax | grep node

gives us among other things

node /opt/radiodan/apps/buttons/current/bin/server /opt/radiodan/apps/magic/current/config/physical-ui-config.json

/opt/radiodan/apps/magic/current/config/physical-ui-config.json is the config file for the physical buttons, dials etc.

catting that file gives us (among other things)

"id": "power",
"pins": [
"pin": 3,
"pull": "down",
"pressedIsHigh": true

so I want to

  • move my button to pin 3 from 17
  • change pressedIsHigh to false (because I want it to trigger when not pressed)
  • is that it?

For now I’m just trying to see if the pin 3 works. If I touch the croc clips together and look in

tail -f radiodan-buttons.log

I can see this:


so it seems to be working, but I can see in the web interface that it’s not turning on.

[debugging session with Andrew]

I had the pin wrong – we use the wiringpi ones, so 3 is the 8th on the left working downwards:

I was using one of the rotary encoder pins.

Also I need a pullup resistor because it’s attached to ground, not 5v (the rotary encoder-buttons work a bit oddly, a better example is “next” in the config file.)


"id": "power",
"pins": [
"pin": 3,
"pull": "up",
"pressedIsHigh": false

(then sudo monit restart radiodan-buttons )

This is the correct config, as the rotary encoder that usually does the ‘on’ button is usually connected to power. So now it goes and on and off when I touch the croc clips together. Fixing them to the switch as before, it goes on when I press it down. I need it to go on when my button is not pressed. I’m not sure how to do that, and I’m 30 mins over time so I’ll leave it till tomorrow.

Andrew also says: “you may want to copy that config file somewhere since any new software updates will overwrite it — a current limitation of our update software”

To see the things controlled by monit:

sudo monit summary

This stops it monitoring a script that turns the radio off when the power button is held down for 3 seconds:

sudo monit stop radiodan-cease

and this:

sudo monit stop updater_status

stops the updater (both between reboots)

Huffduffer Radiodan part 2 – a switch

I wanted to make a nice box for the radio, and yesterday bought this jewelry-box-size one from “Craft and More” in Bristol for £5:


I was thinking at first I would drill a large hole in the top to replicate the current radio design, but then realised I was missing a trick: clearly, when you open the box, the radio should turn on. Damian suggested I use a microswitch – this one was £2 at Maplin:


I’m going to have to rearchitect the whole software side, unless I really make it hacky – I need to put the load commands on the server side not the client side, and that will have to wait, but I figured at least I could test the switch before I hook it up to the Radiodan infrastructure.

I’ve temporarily bluetacked a bit of balsa wood into the box, and now I’m going to attach the switch to the GPIO, using these instructions to pin 17 on this diagram (I don’t need a pull up resistor as I can use one of the pins with a software pull-up later, I think, anyway, seems to work).

import RPi.GPIO as GPIO
import time


#initialise a previous input variable to 0 (assume button not pressed last)
prev_input = 0
while True:
#take a reading
input = GPIO.input(17)
#if the last reading was low and this one high, print
if ((not prev_input) and input):
print("Button pressed")
#update previous input
prev_input = input
#slight pause to debounce

sudo python

The microswitch has 3 legs, one for ground, one for triggering when open, and one closed. I want the middle one, so that it triggers when open (“NO”).

So now I can use a tiny screw I found in a drawer to fix the switch inside:


and I had the wrong corner for the box, initially, and had to squish down my power and ethernet cables to test it, but it works.

Next steps: get it working with the Radiodan GPIO software.