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

Update: a step by step how-to is now available.

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

Update: a step by step how-to is now available.

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

Update: a step by step how-to is now available.

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.

Huffduffer Radiodan

Update: a step by step how-to is now available.

I’ve been wanting a physical radio that plays podcasts for a long time, and it’s something we’ve discussed quite a lot in the Radiodan team. There’s no real reason why not – Radiodan plays MP3s because it uses MPD. and I occasionally talk about a ‘Cambrian explosion’ of radios – we think that Radiodan will be able to let us quickly try out new ideas like this one.

So I want to do something very quickly – 1 day out of my 10% time, and see how far I get.

I also want to use Richard Pope’s checklist for new projects – so these are my notes (Richard’s point 6). This post will therefore change and be added to as I go along.


Radiodan is a radio experiences prototyping platform that we are using at work to show what radio could be like. It’s a Raspberry Pi in a nice box with custom software written in node.js to play audio internet streams and run a webserver to help you control it. There are also physical buttons and dials and some work around easily(ish) getting it on the wifi. The idea is to show what’s possible and test what’s sensible. It uses internet streams – not DAB or FM – because we can quickly show interesting things using streams only. We can make something that acts like a radio without building all the pieces.

Browsing around yesterday I re-found Huffduffer, a really nice service and site by @adactio that allows you to find audio files on the web and add them to a collection – and RSS feed – and also to follow other people, subscribe to RSS feeds from specific events. That seems like a perfect fit for a podcast Radiodan.


Here are Richard Pope’s checklist items, which you should read in full:

1) Know your history.
2) Read the legislation.
3) Draw the thing
4) Understand the state of technology
5) Seek out metaphors.
6) Keep notes, share notes.
7) Keep a list of user needs.
8) Sketch in code.
9) Get a prototype in front of real users.
10) Throw your prototype away.

To add to that, my colleague Tristan’s written about types of prototyping – I need to work out what fidelity I need to make the prototype. Obviously I’d like something that actually works, but probably don’t have time for that.

Initial idea

  • A physical radio that plays podcasts like a radio station
  • maybe with some sort of RFID(?) interface that allows you to flip between different collections

Todo list

00. Start a product checklist
0. start with a standard radiodan, set it up and get it working
1. Fork the simple version of the radiodan client (there are two types of radio currently)
2. See if it’ll play an mp3 as a stream
3. Hardcode an RSS feed and display the result in the controller webpage
4. Try RFID to flip between different RSS feeds?
5. Invent a nice case
6. Document everything
7. Fin

Know your history

I’m doing a quick search for:

  • projects that are very similar (e.g. raspberry pi podcast players)
    • Podcast downloader/player – can I use Podget? nice list of features needed at a minimum, and interesting “WiFi dongle with an antenna to keep one device in my car”
  • podcast players in general (for interface issues)
  • List of Radiodan postcards for similar things
    • I think the closest is ChrisG’s radio, though there are several where podcasts are one element of a more complex radio.

For podcast players in general, I think it actually makes more sense to try some out, but not sure I have enough time, so going with my current experience:

I do use the one on my iphone, and it’s very annoying

  • it seems not to delete things and so the disk fills up
  • it constantly nags to be online
  • its sleep timer doesn’t work properly so sometimes I end up listening to in our time all night while asleep, which is weird


  • it does mark new things as new, and listened to as listened to
  • it remembers where I am in the podcast (that seems pretty important)

2) Read the legislation

I hope / think I can skip this one. Vaguely related, here’s a note on Huffduffer’s terms of use.

3) Draw the thing

We have a Radiodan ‘process’ for some of this. Here’s my postcard:


I think the checklist item is more general than that though:

“Aim for something that represents the totality of the service – a mental model for yourself, and something to help you explain it to others.”


A few things came out of this

  • I don’t know whether I can stream the mp3s or need to schedule their downloads
  • I don’t know if I need a Radiodan web interface or not. That’s sort of interesting.
  • Forgot to draw the RFID bit

4) Understand the state of technology

“Spend time understanding the state of technology and design right now. Assume it has changed since you started your last project and that your knowledge is out of date.”
“Actively seek out ideas that you can steal to solve the problem at hand.”

The research part missing here was to do with how radios handle these kinds of problems. Here’s a quick bit of research:

5) Seek out metaphors.

Something like “your home-made radio station”.

6) Keep notes, share notes.

These are them. Though maybe I should have used github so I got version control.

7) Keep a list of user needs.

A few are emerging, I’m sure there are more:

  • Remembers where you are in a podcast
  • Some way of managing of podcasts (maybe just the Huffduffer site? does that make any sense?
  • Somehow you need to decide what goes on the radio, so assuming Huffduffer, that means either pairing to an account or some other way of telling it the RSS feed you’re interested in
  • Maybe: new podcast available?
  • Mark new items as new (how?)
  • Volume, on / off

8) Sketch in code.

I’ve been working for about two and a half hours, so on my self-imposed timetable I need to get moving to make something. I’m going to try and adapt one piece of the current Radiodan codebase – a very simple interface – to try and use it for podcasts. Radiodan can have different brains swapped in – a more complex one is the magic button radio – which is a more fully-featured radio experience, but also more complicated to hack on.

Maybe I need lunch first actually.

0. start with a standard radiodan, set it up and get it working

I’m cheating a bit here. I already have one I prepared earlier. The basic steps are outlined here:

  • download a card image (we need to make a new one)
  • put it on a pi
  • assemble the bits
  • turn it on
  • do the wifi dance to get it online
  • turn it on using the buttons or the web interface

Here’s mine with the back off so I can ssh to it over ethernet shared from my mac – typically wifi is slower for that kind of operation.


Intermission – Catwigs

Catwigs are a project I’ve been working on with Richard Sewell. They’re a way of talking and thinking about your project to make sure you haven’t missed anything important. I forgot to do them for this project. One moment please….


Basically you shuffle the 22 cards, pick 7 and then decide their orientation based on your project, and then talk about how to improve the ones facing downwards.

For this project, I think it’s reasonably clear what it is, I hope to make it usable, though probably only averagely so, given my limited UX skills; it solves a problem for me (but not a terribly important problem, and it might be quite niche); I think it will generate ideas because physical prototypes often do; it should benefit people (it certainly won’t take anything away and might even increase the amount of knowledge in the world), and it’s in our best interests in order to test Radiodan. It won’t make us any money, but that’s ok.

Sketch in code (cont)

TODO: 1. Fork the simple version of the radiodan client (there are two types of radio currently)

# check the example type radiodan works
sudo radiodan-device-type radiodan-type-example
sudo reboot
# go to http://radiodan-libby.local
# play a stream (works)

# make a new device type
# clone my fork
cd /opt/radiodan/apps
sudo git clone
sudo mv client-web-example client-huffduffer
cd client-huffduffer
sudo chown -R pi:pi .
# change repo name in the web interface ( and in the client:
sudo git remote set-url origin
# make a little edit so that we know the right one is running
# e.g. in /opt/radiodan/apps/client-huffduffer/static/index.html
git add .
git commit -m "Small edits"
git push
npm install # this takes a few minutes. I had to remove references to avahi and mdns to make it work, but we don't need that for now.

# add to init.d
cd /etc/init.d/
sudo cp radiodan-example radiodan-huffduffer
# make appropriate edits, including this:
# DAEMON_OPTS="/opt/radiodan/apps/client-huffduffer/main.js"
# then
sudo pico radiodan-huffduffer
sudo chmod 755 /etc/init.d/radiodan-huffduffer
sudo update-rc.d radiodan-huffduffer defaults
sudo update-rc.d radiodan-huffduffer enable

# add to monit so we can switch between them
cd /etc/monit/monitrc.d/
sudo cp radiodan-type-example radiodan-type-huffduffer
# make edits to replace radiodan-example in that file

# now:
sudo radiodan-device-type
Current device type: radiodan-type-example
Device type required. Valid types radiodan-type-example, radiodan-type-huffduffer, radiodan-type-magic
sudo radiodan-device-type radiodan-type-huffduffer
sudo reboot

After a bit of fiddling that worked, so I now have a basic radiodan instance with an interface I can change, and it’s all in github.

Todo: 2. See if it’ll play an mp3 as a stream

If it does, that’s great, because I won’t have to download them, manage files etc, but just the metadata about them.

I can test that within the web interface (for me, http://radiodan-libby.local), and yes they do seem to play fine.

Next I want to see if I can play them programmatically.

The main guts of the functionality are in ./node_modules/radiodan-client/, the Radiodan client library installed as module. This converts commands to events in rabbitmq. The commands available are in ./static/js/playback-controls.js.

This makes things very straightforward indeed I think for a hardcoded RSS file:

a. when the app is started, get the hardcoded RSS file
b. add all the media files to the playlist
c. start playing the first one
d. is that it?

Obviously that won’t provide a away to remember where you were on restart, which will be very irritating, and nor will the buttons work (e.g. for next, previous), but it’s a start.

TODO: 3. Hardcode an RSS feed and display the result in the controller webpage

# First, stop monit monitoring radiodan-huffduffer:
sudo monit unmonitor radiodan-huffduffer

# then make some edits and test
/usr/local/bin/node /opt/radiodan/apps/client-huffduffer/main.js

The slightly confusing thing here is that node is really just running a tiny website – everything’s happening in client-side javascript, but we want to do this server-side, because chances are Huffduffer doesn’t do CORS for RSS and indeed I think it doesn’t):

curl -k -H "Origin:" -H "Access-Control-Request-Method: POST" -H "Access-Control-Request-Headers: X-Requested-With" -X OPTIONS --head

Copying the similar file in the original code, I think the best thing is to create a little file that adds the rss feed data to the playlist like that.

….time passes…

I wasn’t able to make the player play from node.js – I couldn’t find an example that helped. I’ll try again at some point. You can see my attempts in git.

My second attempt used javascript, with a very simple proxy for my url, like this:

// proxy our one url
var request = require('request');
app.get('/rss', function(req,res) {
//modify the url in any way you want
var newurl = '';

Then it was just a matter of a small change to xjr.js:

function getRSS(url, success) {
var xhr = new XMLHttpRequest();'GET', url, true);
xhr.onload = function() {
var rss = xhr.responseText;
var arr = rss.split("\n");
var urls = [];
for(var i =0; i< arr.length; i++){
var text = arr[i];
var m = text.match(/<enclosure url=\"(.*?)\"/);

and then a call in app.js:

if(urls && urls.length>0){
for (var i=0; i< urls.length; i++){
console.log("nothing to add to playlist");

and bingo.

It currently only works when the html page on the device is loaded. Not sure how to manage it with a button. There’s also no title or length, but maybe those can be passed somehow to it. But it plays!

I didn’t get to try the RFID reader, but you could also set the URL in the page for example.

That’s enough for today though – about 7 hours from start to finish – not bad.