A quick analysis of wifi cards for using a Raspberry Pi as an access point

When Radiodan can’t access the web, it throws up an access point (AP) created by the Pi: you connect directly to that and it displays the available wifi points in a webpage as a captive portal, and asks you to add the password for the one you want. It’s not easy to get credentials for wifi to objects with no user interface, and this is the best one we’ve found so far (Chromecast does something similar).

However our home tests suggest that the many varieties of wifi USB cards and access points cause problems of two major kinds. One a general problem of Radiodan accessing the internet – the wifi access point in a house might just be too far away. The other is that some wifi cards don’t seem to work as access points properly, and we wanted to get to the bottom of where the problems were there, as identified with the kind help of Giles Booth (@blogmywiki). This is so that we can recommend wifi cards to go with Radiodan or at least so we can say which are known to work.

I’ve started on the second problem here. I had 6 USB wifi cards in the house of various kinds: left to right: Wipi, Comfast, Micronet, Tenda, Loglink, Edimax
A selection of wifi cards: left to right: Wipi, Comfast, Micronet, Tenda, Loglink, Edimax

Here’s what I found for each.

Test setup:

  • 5 metres from an apple wifi point
  • Mac OS 10.9.5 Macbook Air laptop
  • 30 cm between laptop and Pi

Test conditions:

  • Radiodan clean image, boot up, try and connect to the radiodan-configuration AP from laptop


Name Result libusb output
WiPi Network appears in 3m 10s. Bus 001 Device 004: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

Comfast cf-wu720n Network appears in 3m 10s. Bus 001 Device 007: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

Micronet SP907NS Nothing after 4 minutes Bus 001 Device 006: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

Tenda with ariel w311U+ Network appears in < 3m Bus 001 Device 009: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 Wireless Adapter

Loglink wl0084B Network appears but I can’t connect to it Bus 001 Device 008: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

Edimax Nothing after 4 minutes Bus 001 Device 005: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS]

So basically I found two different manufacturers, Ralink and Realtek and the Realtek ones don’t work as APs with our setup.

It should be possible to get the Realtek ones working – there’s a detailed description here – and I managed to get a network showing up using those instructions but within our framework, but I couldn’t connect to it – so we’ll have to test this some more.

How to find your wifi card’s chipset

The best way it to plug it into a Raspberry pi that you are already connected to and type:

$ pi@radiodan ~ $ lsusb

This will give you a list of everything connected to USB, in my case (I had two wifi cards connected):

Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. 
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. 
Bus 001 Device 004: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter
Bus 001 Device 006: ID 0bda:8176 Realtek Semiconductor Corp. RTL8188CUS 802.11n WLAN Adapter

On Mac OS X you can look in apple menu -> about this mac -> more info -> system report and then click on USB – but you’ll need to google the vendor name and id to get the chip.

Raspberry Pi podcast-player-in-a-box – step by step


Podcast-player-in-a-box is a way to associate a physical object (a plastic card) with a possibly-changing list of audio files. When you put the card in the box it plays the audio.

It’s inspired by this lovely project to make an audiobook reader and also by Jasmine Cox’s enchanted objects.

I’m particularly interested in using it with Huffduffer, an excellent site that enables you to build your own podcast of audio files.

Podcast-player-in-a-box matches contactless cards of a particular type (MIFARE) with podcast feeds. MIFARE cards are very common – Oyster cards for example, and many ID cards, so there are plenty of them around (I had 6 in my house, or you can buy them easily), and there’s a cheap and easily available shield for them for the Raspberry Pi.

The box enables you to “programme” a card for a particular podcast. It doesn’t actually write to the card, just reads the id and maintains matches between card ids and urls. A card has to be present to play, and when the box is shut it stops playing. If it finds a new item in the podcast, it plays that, otherwise it remembers roughly where you last were in the podcast.


I made it because I want to listen to audio podcasts on a device, rather than a mobile or a laptop, because that’s how I listen to the radio. I also want to be able to switch between different podcasts very quickly, easily and intuitively.

It’s also a test for me of Radiodan, the radio prototyping platform we’ve been working on. Radiodan allows you to add new radio apps and flip between them. I wanted to see how quickly I could prototype something using the platform (answer – I got quite far in a day, but it’s taken me a couple of weeks to iron out the bugs).

You can see the podcast-in-a-box in action in this video.

Here are step-by-step instructions. It’ll take about 2 hours once you have the SD card written – so maybe 3-4 hours in total (but you can do something else while the SD card is writing. Much of the 2 hours is also waiting for stuff to install).

Things you’ll need


  • Raspberry Pi (B or B+, because you need 2 USB ports, I used a B+ and these instructions assume that)
  • Mini speaker with USB power / charging and 3.5mm jack (example)
  • Explore NFC Raspberry Pi shield
  • 8G or 4G (micro) SD card suitable for the Pi (example)
  • WiPi or similar wifi card (RT5370 chipset)
  • Power supply for the Pi (example)
  • Microswitch (example) + 2 screws to attach it
  • 6 M/M jumper wires (example), two attached to crocodile clips
  • 2 M/F jumper wires (example)
  • 1 RGB LED common cathode (example)
  • Small breadboard ideally with a sticky back (example)
  • 3 x 1K resistors
  • Oyster card or similar MIFARE card
  • Small box with a lid (example)
  • Thin balsa wood (~ 0.3mm width) or thick card
  • A bit of thicker balsa wood (I used 1cm square) or something similar, to trigger the lid button
  • Glue (for the balsa wood lid trigger)
  • Optionally: keyboard, mouse and screen, HDMI cable (for the Pi)



  • Electric drill
  • Screwdriver
  • Soldering iron and solder
  • Laptop
  • Hacksaw

Putting it all together requires basic linux commands and editing, but no programming.


1. Put the operating system on the SD card

I recommend using an 8GB SD card tested with the PI – Radiodan does a lot of writes to the disk and not all cards are up to it. The Radiodan image is Ubuntu Wheezy with some extra Open Source code for playing audio streams, and managing wifi. If you like, you can use a 4GB card instead of 8GB – there’s a separate image for that in this directory.

Get the Radiodan 8GB SD card image:

curl -O http://dev.notu.be/2014/12/radiodan/2014-12-23-radiodan.img.gz

Plug the SD card into the laptop using a card reader. List disks:

$ diskutil list

Find the disk number (e.g. “2”). Unmount that disk.

$ diskutil unmountDisk /dev/diskX

Unzip and write the image in 1 step:

$ gzip -dc /path/to/2014-12-23-radiodan.img.gz | sudo dd of=/dev/diskX bs=1m

This part can take a long time (74 minutes last time I tried). You can speed it up by –

  • using a separate card reader rather than the built-in Mac one (if that’s what you have)
  • you can try $ gzip -dc /path/to/2014-12-23-radiodan.img.gz | sudo dd of=/dev/rdiskXXX bs=1m (“rdisk” rather than “disk”) – but I find this can corrupt the disk.

2. Assemble the basic elements

Put the SD card in the Pi, and the wifi card in one of the USB ports. Plug in the speaker into another USB port and into the 3.5mm audio socket. Plug the Pi into the power supply and plug it into the mains. It should look like this:


3. Get the wifi working and test

Wait a minute or two for it to boot up, and you should see a wifi network appear (“radiodan-configuration”).

Connect to this new wifi network with your laptop. A web page should pop up, if it doesn’t, go to any web page. You should see a page load with a list of all the wifi networks available. Pick your usual one, and enter the details, and reboot the Pi when instructed.


Make sure you rejoin your usual wifi network.

4. Test the vanilla Radiodan

Once the Pi has rebooted, you have the default Radiodan. It currently acts like an internet radio. You can test this by going to http://radiodan.local in a web page on your laptop.

You should see something like this:


Click on the power button and you should hear some radio playing. It can take a little while for it to be visible (you might get 404 Not Found for a bit).

We’re going to change its behaviour by installing another app.

5. Log into the Radiodan

If you like you can do this using a keyboard and mouse and screen, but I usually just shell in from my laptop, since the Radiodan is on the wifi. This can be a bit slow depending on congestion in your wifi network.

$ ssh pi@radiodan.local

The password is the default pi password: “raspberry” (without quotes)

6. Overclock and enable SPI interface

$ sudo raspi-config

Overclock to Medium

Enable the SPI interface (sudo raspi-config -> advanced -> enable SPI)

Reboot: $ sudo reboot

7. Disable Radiodan updates

Radiodan uses Monit to manage its processes. You can see what it’s doing by typing this:

$ sudo monit status

We want to disable Radiodan updates (updater_status) in case it overwrites the changes we’ve made; we also want to remove radiodan-cease (a utility to turn off the radio with the power button being held down, because we use the power button differently); and we’re going to replace radiodan-magic which is the default app with our own, so we’re going to stop Monit monitoring all those:

$ sudo monit stop updater_status
$ sudo monit stop radiodan-cease
$ sudo monit stop radiodan-magic

then you’ll see things like this:

$ sudo monit status
File 'updater_status'
status Not monitored
monitoring status Not monitored
data collected Fri, 02 Jan 2015 15:02:16

8. Download the podcast software

Radiodan keeps its apps in /opt/radiodan/apps, so we’ll put it there.

$ cd /opt/radiodan/apps
$ sudo git clone https://github.com/libbymiller/radiodan-client-podcast.git
$ cd radiodan-client-podcast/
$ sudo chown -R pi:pi .

There are two pieces – a script in python that only talks to the NFC reader, and some node code (mostly in main.js) that controls the audio and runs a small web server.

9. Install dependencies

Install the dependences for node

$ npm install

and for the python nxppy code (for interacting with the NFC reader)

$ cd
$ sudo apt-get update
$ sudo apt-get -y install build-essential python2.7-dev python-setuptools cmake
$ curl -O https://bootstrap.pypa.io/get-pip.py
$ sudo python get-pip.py
$ sudo pip install requests

Install nxppy:

$ git clone https://github.com/svvitale/nxppy.git
$ cd nxppy
$ sudo python setup.py build install

(nxppy didn’t seem happy being installed with pip, I didn’t investigate why).

10. Install the podcast app

Monit works using init.d scripts, so we need to add those, so that our app runs when the Pi is booted up.

$ sudo cp /opt/radiodan/apps/radiodan-client-podcast/init.d/radiodan-huffduffer /etc/init.d/
$ sudo cp /opt/radiodan/apps/radiodan-client-podcast/init.d/radiodan-nfc /etc/init.d/

and add these to Monit

$ sudo cp /opt/radiodan/apps/radiodan-client-podcast/init.d/radiodan-type-huffduffer /etc/monit/monitrc.d/

Change the config file for the physical UI:

$ sudo pico /etc/init.d/radiodan-buttons


Make a small edit to the buttons interface:

$ sudo pico /opt/radiodan/apps/buttons/current/lib/bootstrap.js

// Reverse the polarity of the neutron flow
// rgbOpts.reverse = true;

^^^ comment out this line, like this

Switch to the new app type

$ sudo radiodan-device-type radiodan-type-huffduffer

Reboot to make sure it all comes up.

$ sudo reboot

11. Check everything’s running

ssh in again

$ ssh pi@radiodan.local

$ ps ax | grep node

 2126 ?        Sl     0:11 /usr/lib/erlang/erts-6.1/bin/beam -W w -K true -A30 -P 1048576 -- -root /usr/lib/erlang -progname erl -- -home /var/lib/rabbitmq -- -pa /usr/lib/rabbitmq/lib/rabbitmq_server-3.3.5/sbin/../ebin -noshell -noinput -s rabbit boot -sname rabbit@radiodan -boot start_sasl -kernel inet_default_connect_options [{nodelay,true}] -sasl errlog_type error -sasl sasl_error_logger false -rabbit error_logger {file,"/var/log/rabbitmq/rabbit@radiodan.log"} -rabbit sasl_error_logger {file,"/var/log/rabbitmq/rabbit@radiodan-sasl.log"} -rabbit enabled_plugins_file "/etc/rabbitmq/enabled_plugins" -rabbit plugins_dir "/usr/lib/rabbitmq/lib/rabbitmq_server-3.3.5/sbin/../plugins" -rabbit plugins_expand_dir "/var/lib/rabbitmq/mnesia/rabbit@radiodan-plugins-expand" -os_mon start_cpu_sup false -os_mon start_disksup false -os_mon start_memsup false -mnesia dir "/var/lib/rabbitmq/mnesia/rabbit@radiodan" -kernel inet_dist_listen_min 25672 -kernel inet_dist_listen_max 25672
 2554 ?        Sl     0:11 node /opt/radiodan/apps/buttons/current/bin/server /opt/radiodan/apps/radiodan-client-podcast/config/physical-ui-config.json
 2564 ?        Sl     0:11 /usr/local/bin/node /opt/radiodan/apps/radiodan-client-podcast/main.js
 2575 ?        Sl     0:07 node /opt/radiodan/apps/server/current/bin/server /opt/radiodan/apps/magic/current/config/radiodan-config.json
 2942 pts/0    S+     0:00 grep --color=auto node

$ ps ax | grep python

 2541 ?        D      0:28 /usr/bin/python /opt/radiodan/apps/radiodan-client-podcast/accessCardReader.py
 2951 pts/0    S+     0:00 grep --color=auto python

Check for errors

$ tail /var/log/radiodan-huffduffer.log
$ tail /var/log/radiodan-nfc.log

13. Test the podcast app

$ curl -X POST http://localhost:5000/rssFromNFC -d "feedUrl=http://downloads.bbc.co.uk/podcasts/fivelive/kermode/rss.xml"

You should hear the podcast. Stop it like this:

curl -X POST http://localhost:5000/stopFromNFC

Now shut down the PI, as we’re going to attach the NFC reader.

sudo halt

14. Solder some wires on to the NFC shield

One of the downsides of using a shield is that it uses most of the pins, even on the B+. We need to have some sort of a signal about what’s going on (an LED), and also a button for the closing-box-switching-off feature. The shield doesn’t actually use all the pins but it sits on all of them, so we need to solder the wires we need for the RGB led and the button onto some of the unused pins on the shield.

Because it’s a B+ there are a couple of spare ground pins available, so I just soldered the 4 pins I needed. Here’s a list of the pins the NFC shield uses, but it’s a bit vague, and I found the spare ones through trial and error.

The soldering is a bit tricky – what seems to work best is to make the pins short, tin them:


and also tin the places where you’ll be adding the wires:


(we’ll be using WiringPi wires 3,4,5,6 in this diagram – I’ve put a “*” next to them):

$ gpio readall

 +-----+-----+---------+------+---+--B Plus--+---+------+---------+-----+-----+
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 |     |     |    3.3v |      |   |  1 || 2  |   |      | 5v      |     |     |
 |   2 |   8 |   SDA.1 |   IN | 0 |  3 || 4  |   |      | 5V      |     |     |
 |   3 |   9 |   SCL.1 |   IN | 1 |  5 || 6  |   |      | 0v      |     |     |
 |   4 |   7 | GPIO. 7 |   IN | 1 |  7 || 8  | 1 | ALT0 | TxD     | 15  | 14  |
 |     |     |      0v |      |   |  9 || 10 | 1 | ALT0 | RxD     | 16  | 15  |
 |  17 |   0 | GPIO. 0 |   IN | 0 | 11 || 12 | 0 | IN   | GPIO. 1 | 1   | 18  |
 |  27 |   2 | GPIO. 2 |  OUT | 0 | 13 || 14 |   |      | 0v      |     |     |
 |  22 |   3 | GPIO. 3*|   IN | 1 | 15 || 16 | 0 | OUT  | GPIO. 4*| 4   | 23  |
 |     |     |    3.3v |      |   | 17 || 18 | 0 | OUT  | GPIO. 5*| 5   | 24  |
 |  10 |  12 |    MOSI | ALT0 | 0 | 19 || 20 |   |      | 0v      |     |     |
 |   9 |  13 |    MISO | ALT0 | 0 | 21 || 22 | 1 | OUT  | GPIO. 6*| 6   | 25  |
 |  11 |  14 |    SCLK | ALT0 | 0 | 23 || 24 | 1 | ALT0 | CE0     | 10  | 8   |
 |     |     |      0v |      |   | 25 || 26 | 1 | OUT  | CE1     | 11  | 7   |
 |   0 |  30 |   SDA.0 |   IN | 1 | 27 || 28 | 1 | IN   | SCL.0   | 31  | 1   |
 |   5 |  21 | GPIO.21 |   IN | 1 | 29 || 30 |   |      | 0v      |     |     |
 |   6 |  22 | GPIO.22 |   IN | 1 | 31 || 32 | 0 | IN   | GPIO.26 | 26  | 12  |
 |  13 |  23 | GPIO.23 |   IN | 0 | 33 || 34 |   |      | 0v*     |     |     |
 |  19 |  24 | GPIO.24 |   IN | 0 | 35 || 36 | 0 | IN   | GPIO.27 | 27  | 16  |
 |  26 |  25 | GPIO.25 |   IN | 0 | 37 || 38 | 0 | IN   | GPIO.28 | 28  | 20  |
 |     |     |      0v*|      |   | 39 || 40 | 0 | IN   | GPIO.29 | 29  | 21  |
 | BCM | wPi |   Name  | Mode | V | Physical | V | Mode | Name    | wPi | BCM |
 +-----+-----+---------+------+---+--B Plus--+---+------+---------+-----+-----+

We’re soldering on the top of the NFC shield.


15. Assemble the LED components

I happened to have some common cathode RGB leds – common anode ones are also available, but need different configuations. The cathode RGB LED’s longest leg goes to ground and then it’s

blue green [cathode] red

We connect them to WiringPi pins 6, 5 and 4 respectively, using the mini breadboard and the resistors


and then add the ground:


16. Add the button

This uses WiringPi pin 3 and another ground pin, via the breadboard again:


The “COM” terminal of the switch goes to ground and the pin 3 wire goes to “NO” (normally open)


17. Try it all out – Programme a card



  • Save


After a few seconds it should start playing the audio from your feed and the light should go green.

18. Test behaviour

  • Click the switch shut – while you hold it, it should stop the audio and the light should go blue
  • Release the switch and it should restart the audio and the light should go green
  • Remove the Oyster card and it should stop the audio again, and the light should go green
  • Add the Oyster card again and it should restart from approximately the same point

The basics are now done – we just need to put it in the box. Turn it off by unplugging it or doing sudo halt if you are sshd in to the Pi.

19. Drill holes in the box

The basic part is the hole for the power cable. Make a note of the maximum width and height of the small end of the power cable – that’s the hole size you need.


You may also want to add holes for ventilation – it can get warm (but not very hot).


20. Add the switch

Screw the switch on to the side of the box. Glue a bit of balsa wood or similar in the opposite corner of the lid, and test that when the box is shut you can hear the switch click.


While you are sawing, cut a couple of pieces of balsa wood, one to fit exactly across the lid and another across the width of the box to form a shelf.


21. Put everything in the box

Put everything in the box threading the power cable through the hole you drilled earlier. The arrangement will vary a bit depending on your box size and shape, but the important things are that the aerial of the NFC reader is accessible (the card doesn’t have to be flat on it though) and the LED is visible. Reconnect the croc clips to the switch.


I’ve added a little shelf in to make it easier to place the card. The range of the NFC is about 3-5 cm, but the closer the shelf is to it the better.


22. Test again




You can programme more cards and stick pictures on them to show what they will play. A Pogo printer is a great for this (but a normal printer and a pritt stick work perfectly well too).



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 blockbox.cards).

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.zip libnfc-libnfc-1.7.0
scp libnfc-libnfc-1.7.0.zip pi@radiodan-libby.local:

on the pi

mkdir libnfc
cd libnfc
mv ~/libnfc-libnfc-1.7.0.zip .
unzip libnfc-libnfc-1.7.0.zip
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/Makefile.am:6: error: Libtool library used but 'LIBTOOL' is undefined
libnfc/Makefile.am:6: The usual way to define 'LIBTOOL' is to add 'LT_INIT'
libnfc/Makefile.am:6: to 'configure.ac' 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 https://code.google.com/p/libnfc/
cd libnfc
git checkout libnfc-1.7.1
git clean -d -f -x
git remote|grep -q anonscm||git remote add anonscm git://anonscm.debian.org/collab-maint/libnfc.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 https://code.google.com/p/libnfc/
cd libnfc
git checkout libnfc-1.7.1
git clean -d -f -x
git remote|grep -q anonscm||git remote add anonscm git://anonscm.debian.org/collab-maint/libnfc.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

https://learn.adafruit.com/adafruit-nfc-rfid-on-raspberry-pi/freeing-uart-on-the-pi (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: https://github.com/svvitale/nxppy

print "Imported NXPPY"
reader = nxppy.Mifare()
print "Loaded mifare device"
currentId = None
while True:
uid = reader.select()
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/radiodan-buttons.pid
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).