Thinking about the purpose of prototypes:

Make new and upcoming technologies and standards tangible enough to help people think through the consequences of them.

Technology is moving fast, but it is also unevenly distributed, and the consequences – good and bad – of emerging technologies may only become apparent as they move into the mainstream. By making these consequences tangible early we can choose between possible futures.

Links

MIT Design Fiction Research Group

What do Prototypes Prototype? by Stephanie Houde and Charles Hill

Intel’s Tomorrow project

This is my view only, and there’s a certain amount of thinking out loud / lack of checking / potentially high bullshit level.

Yesterday I was asked to comment on a Radiodan doc and this popped out:

Radiodan is a radical new way of putting audiences at the heart of media device development using imaginative forecasting / design fiction, participatory design, concurrent standards development with user testing, and user testing of new radio features on real devices.

1. Design fiction: building real-ish physical devices make possible media devices futures more realistic for people and thereby enables the exploration of more of the radio (and potentially TV) user-need-space (and its mapping to “product space”).
2. Radiodan enables Digital Creativity: the explosion of ideas generated by the Radiodan Creative Process©®™ shows that familiar media devices are a very productive area for generating new ideas by experts and audiences.
3. Concurrent code-and-standards development: most radio (and TV) standards are made without testing on users or running code – implementation comes afterwards. This means thousands of engineer hours invested before knowing if anyone wants the features. Testing devices and features on users stops this incredible waste.
4. Real user input into real radios: new real features, pre-tested on users on realistic devices, to get genuine feedback, for inclusion into new or existing digital or physical products.

All these require fast, iterative, flexible, cheap but robust development, so that behaviour is known and testing can measure the difference. Techniques from web development applied to devices offer a way to do this. Research suggests that people make better decisions when shown product features embodied in devices in this way [citation needed], regardless of whether the end product is physical or digital.

This morning I’m wondering how much of that is true, so I thought I’d develop some of the ideas a bit further.

Design Fiction / Scifi and Radiodan

I’m becoming increasingly interested in design fiction and also scifi (thanks mainly to Richard Sewell) as a way of expanding our imagination about what future possibilities there could be (here’s a discussion about the relationship between design fiction and scifi).

I think that a great many products, services and the like get stuck at local maxima and it’s hard then to think about possible alternative futures. Richard Pope has an interesting take on this area.

What’s become clear to me is that (a) silly or surprising or unusual things make people think about alternatives more creatively (b) their thinginess is an inherent part of that …er…surprisal. I don’t know why it’s the case, but making unusual physical things that embody new possibilities and features is a great way of getting people – us – to think more imaginatively about future possibilities and so expand the space around which products can be built.

Radiodan is great for that, because it enables us to make peculiar new new radio-like things very quickly (like this one) and hereby trigger one of these digressions into a different part of product-space or user-need-space. It frees up your brain to think about what you want to make, rather than how.

Digital Creativity

This second point is also about expanding the possible space but in a different way. The “Radiodan Creative Process©®™ has no ©®™ at all (those are a joke!) and is not really a process because it’s so simple: start talking about radios and everyone says “oh I want one that does …”. Give someone a postcard with a rough drawing of a radio on it and some stickers representing buttons and dials and similar things, and ask them what they want their radio to do and almost everyone will start drawing or writing something on it about what they want from a radio.

Once you’ve got over the idea that radios could be different, then ideas pop out of people so easily – and it’s so nice to experience that. This is the beginning of participatory design I think, and it’s amazing when it works.

The “process” works for other things too (we created our own avatars using a similar idea and a simple sketch of a robot: that’s me in the middle).

I’ve headed this section “Digital Creativity” because that’s the term the BBC is using for its work around getting people to code. The BBC rightly sees it as broader than coding, but for me what’s missing is this (horrible phrase) elicitation of requirements. Finding out what a user needs and describing those needs. Coding (or anything else that’s “digitally creative” for most people has to be for a reason. For those who don’t need a reason, they’re probably already coding….

The other aspect is that Radiodan is simple enough such that anyone with Javascript can have a go at hacking their own version. It almost looks like an afterthought here, but it’s not: it’s an absolutely integral part of Radiodan that it lowers the barrier to making a real or nearly real device, and for “Digital Creativity” Radiodan could be a simple kit (maybe a PCB, maybe a cardboard flatpack box) that (nearly) anyone could make their own radio with. Lowering barrier to entry runs as a principle throughout the project, and is applicable to lots of potential users, who could be inside or outside the BBC.

Concurrent code-and-standards development

I’ve been peripherally involved in the W3C for many years and so it feels completely natural to me that standards work will have running code associated with standards while the standards are being made (also, often tests, and detailed usecases; and many standards are based on existing products). Similarly, the IETF has as a “founding belief” “rough consensus and running code“.

As I understand it, that’s often not the way that radio and TV standards work (but this is the part I’m least confident about, so please do comment). Instead, there are some broad usecases that the group has in mind when it starts, then some engineers create very precise specifications about the features to be implemented, and then implementation starts. Of course the engineers know about the capacities of their technologies so they can be fairly confident about what’s technically possible. But the missing part for me is whether anyone actually wants the thing that’s being specified.

These kinds of standards seem to be built on the principle of “build it and they will come”: make a technology that’s interesting and flexible enough and people will build interesting applications on top of it and the end users will be happy. But it’s a risky strategy – overlap between technologies that are sufficiently flexible to enable a profusion of interesting applications but are also sufficiently precisely specified to make interoperability practical – happens very rarely. But this is the only strategy available, because it’s so difficult and slow to develop for Radios (and TVs).

IRT are doing some very interesting work in making a hybrid radio from a Pi, which could enable concurrent standards and code – which I think would be be a massive step forward; but I’m talking about something different: to test using prototypes before standardisation starts to see how and whether people will actually use the features enabled by the standard.

In one sense this is simply paying more than lip-service to usecases, but Radiodan and things like it for TV can speed up this pre-standards process. I’d argue that you can get a long way with paper prototyping to get feedback on new products and features, but there’s nothing like putting a working device in front of a human and seeing what they do with it, and that’s what we can now do with Radiodan. Suddenly we can find out if people want the thing. Risk is reduced without reducing creativity.

Real user testing of novel real radios

Then this is the final thing we could do – but haven’t yet – with Radiodan. Make a “living lab” of people who could test radios such that those features could go into a radio product. Whether it is appropriate for an organisation like the BBC is quite a different matter, but we can at least see how it might be possible to do it, using deployment and development tools from the web applied to devices.

The most interesting part

I love the participatory design part (I suppose this is why people become teachers) but the most interesting piece of the puzzle is that what seems to happen is that people can better visualise features when they form part of a physical object than part of a digital one. Maybe it’s something to do with affordances and the intuitions we get when we interact with something physically – and I’ve found no academic evidence so far – but it’s a real effect. What’s more, it applies even when you get people to think about physical objects, which is both amazing and also much quicker.

I put at the start “Radiodan is a radical new way of putting audiences at the heart of media device development…” which just shows you what clichéd bullshit can flow out of my typing just to get things moving, but I do, truly, think it is a radical way of thinking of, testing and making new devices. I hope I’ve managed to explain why I think that, finally.

I made one of these a few months ago – they’re super simple – but Chris Lynas asked me about it, so I thought I should write it up quickly.

It’s an internet radio that turns itself on for the Archers then turns itself off again afterwards. It’s not very smart: it just uses a crontab and the default Radiodan application’s REST API. It would be more interesting to do it based on real-time metadata. I’ll have a look at that at some point, but this does the job, as the Archers doesn’t move round much at all.

You’ll need: A Raspberry Pi, a speaker with a 3.5mm jack, a USB wifi card (ideally RT5370 chipset), an 8GB micro SD card, a power supply for the PI. And a nice box to put it in.

1. Provision the SD card

If none of this is familiar you might want to follow the official Raspberry Pi instructions. I did this on Mac OS X – it ought to work on linux.

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

2. Get the wifi working

Plug everything into the Pi, add the SD card and turn it on.

Then, either:

Wait for it to boot up, look for and connect to the wifi it generates (radiodan-configuration) and follow the instructions on the captive portal it generates, returning to your usual wifi afterwards.

The success of this depends on your chipset – I’ve done a quick analysis here and some just won’t work.

OR, login and add your wifi details to /etc/wpa_supplicant/wpa_supplicant.conf –

network={
ssid="YOUR_NETWORK_NAME"
psk="YOUR_NETWORK_PASSWORD"
}

usually does the trick. Either way, reboot afterwards.

3. Add a crontab

Ssh in :

$ ssh pi@radiodan.local

password “raspberry”

$ crontab -e

This is for the Archers, using the Radiodan REST API:

# turn it on at 14:02 weekdays
2 13 * * 1-5  /usr/bin/curl -X POST http://localhost/radio/service/radio4  

# turn it off at 14:15 weekdays
15 13 * * 1-5,7  /usr/bin/curl -X DELETE http://localhost/radio/power

# turn it on at 19:02 weekdays and sundays
2 18 * * 1-5,7  /usr/bin/curl -X POST http://localhost/radio/service/radio4 

# turn it off at 19:15 weekdays and sundays
15 18 * * 1-5,7  /usr/bin/curl -X DELETE http://localhost/radio/power

# turn it on at 10:00 on sundays for the omnibus edition
0 9 * * 7 /usr/bin/curl -X POST http://localhost/radio/service/radio4

# and turn it off at 11:15
15 10 * * 7 /usr/bin/curl -X DELETE http://localhost/radio/power

Save the crontab file.

4. Put it in a box

And enjoy your Radiodan 🙂

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

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

Results

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.

Introduction

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

Ingredients

• 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)

Tools

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

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

Method

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

change
DAEMON_OPTS="/opt/radiodan/apps/magic/current/config/physical-ui-config.json"
to
DAEMON_OPTS="/opt/radiodan/apps/radiodan-client-podcast/config/physical-ui-config.json"

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

• Turn on the Pi and wait until you the LED goes blue
• Go to http://radiodan.local/ and click on “programme a card“

• Put your Oyster card on the reader (the aerial is the blank bit) and click “next”.
• Add a feed URL, e.g http://downloads.bbc.co.uk/podcasts/fivelive/kermode/rss.xml (that one’s from the BBC’s podcast site) or one from the excellent Huffduffer (e.g. search for Scifi)

• 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

DONE

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