Â鶹ԼÅÄ

There’s been a lot of interesting work already done in this field. Previously, the Â鶹ԼÅÄ have collaborated with BERG to produce , a customisable radio with modular components that add social elements to your radio experience. Â鶹ԼÅÄ North Lab have produced a that plays a specially-produced play that adjusts the performance according to what the radio senses in it’s environment.

We wanted to be able to conduct similar experiments in radio but in a way that allowed us to work quickly and without spending time building bespoke electronic equipment.

What we've built so far

Here are a few examples of what we’ve built so far.

Archers Avoider

This was our first effort at building our own radio emulator. We’ve been kicking this idea around the office for a while now. This shouldn’t be thought of as aimed specifically at The Archers but it’s a great example of the sort of programme that divides opinion. Plenty of us worship at the altar of the Radio Four schedule and yet when certain fixtures play out, you can’t help but think “Why can’t I have something else instead?”. You could easily invert the concept, with a radio that only plays only on-demand episodes of Archers Omnibus and Ambridge Extra, with interruptions in your schedule for live Archers episodes.

In our case, we wanted to leave Ambridge behind and the Archers Avoider was our attempt to solve this problem.

The above photo from the we held back in April explains the concept nicely. When a programme you don’t like appears on the radio, you can hit the button and the radio chooses a substitute programme that you might prefer instead. Once your programme is finished, you are returned to your regularly scheduled programming.

Over the next few months, we spent our 10% time working on new iterations of the avoider. At each stage, we experimented with the interface and its functionality, using buttons, home-made cases and low-cost usb devices. Because we were using off-the-shelf components, it made each iteration simple and cost-effective, allowing us to experiment more, trying them out for real and guessing less.

Here’s a quick clip of the current Archers Avoider Mark Four in action:

Radio Democracy

The Archers Avoider is for when you are prepared listen to anything else. For our next project, we wanted to see how we could decide what content should be played instead. Radio democracy, built by Libby, is an idea by which adds voting into the mix and selects the best programme based on the number of up and down votes it has received.

The radio preselects a selection of popular Â鶹ԼÅÄ podcasts. When you avoid a programme, it selects the programme with the most votes that you haven’t already listened to. You can then vote for or against this new programme or just select a random one. If you don’t like it, the radio will immediately try you with another programme from the current selection, until your original programme has ended. The information is aggregated by a central server and attempts to play better content for you next time.

Radio Request Show

Most of our focus has been on building “real”, physical radios for people to try out. The Request show was a quick hack to show that the software is flexible enough to create a radio-like experience online, and we can interact with APIs just as easily as physical interfaces. We hooked up our software to the API to enable listeners to call and text in with their music requests. These requests were mixed into the current playlist of tracks, which was streamed live over our internal network. Within a day of development time, we had a fully functional, interactive radio station.

How We Built It

We’ve covered what we’ve managed to produce so far using our toolset. We’ll now go into a some depth about the tools we’ve created: a Ruby library and a toolset for working with the software on embedded devices.

Ruby Gem

The key piece of software is the Radiodan Ruby gem. When I realised I needed to put the first Archers Avoider into Github during our hackday, I struggled to come up with a suitable name for it. Pressed for time, I entered “Radiodan” and I’ve regretted it ever since.

On one level, Radiodan is simply a wrapper for a well established music player for Linux: . It connects to the player via telnet, checks for status changes (e.g. a new playlist, changes to volume, music stopped) and also issues commands to manage the content being played. To play content using Radiodan, you build a playlist of what you want to play and how you would like it to be played. Radiodan then checks this against what MPD is currently doing. It then makes changes to ensure that the player is in sync with your request.

The current version of the gem employs a approach to adding additional functionality. To build your own Radiodan app, you include the gem and build up Middleware pieces of functionality. Some basic functionality is provided in the gem but it’s easy to write your own.

Basic functionality includes:

• Interaction with the player via the filesystem
• Webserver
• Playlist toggler
• “Panic Mode”, for archers-avoider like temporary switching of playlists

Using and , the gem can manage MPD, serve webpages and respond to external events within a single Ruby process. We’re still in a very early stage of development but we’re very pleased with the results we’re getting so far.

Raspberry Pi

You could put the Radiodan gem onto any number of devices that support Ruby, including hosting it on the web, but we’ve found real value in running it on an embedded device. The Raspberry Pi is a fantastic example of what an embedded device can be. This low-powered board has everything we need to produce a convincing radio emulation, including on-board ethernet and audio card. With the two USB ports, we can connect any number of USB devices to enhance its capability. It has a fantastic community of developers, producing great open-source software that we’ve used as the basis of our work. Importantly for us, it’s also cheap. This allows us (or anyone else) to build realistic radios out of our own pocket.

Cold Start

When working on the Pi, we realised that the most aggravating part of working on these systems is the cold start; getting the device ready to run for the first time. Connecting to the internet, setting a hostname, getting the Radiodan code and prerequisites installed. These are all fiddly actions that you generally only have to deal with once per new device, but as we were rapidly prototyping our radios, we were frequently facing these issues, sometimes several times per day.

In order to alleviate our own pain, we’ve been looking into building own own set of tools to simplify the cold start process. We’ve been documenting these in our .

The first issue we’ve tackled is that of the network setup. Our radios don’t currently have screens, nor do they have a keyboard. So how do we setup our wireless internet settings when the Pi first boots up? We’ve attempted to solve this by making the Pi create its own adhoc network if it cannot connect to any other hotspot. When we connect to this adhoc network, we are taken to a webpage on the Pi that allows us to search for available networks and enter a password to access. The Pi then reboots and (with luck) gets itself on to the Wifi network of your choice.

We’re also working on solutions to automate software installation using and an interactive “first-run” command-line tool to allow you to run an example Radiodan application.

Working in the open

We take great pride in being able to work completely in the open. By making our work , we hope to further the current state of the art for future radio devices. All of our code is available to download and for you to try out yourself, albeit in the knowledge that we are still figuring all of this out for ourselves. Radiodan is still very much a work-in-progress and we hope to share more of our work with you in the future.