Note: This post isn’t about photography per se, but I came up with many other uses for my Pis, so I couldn’t help it 😉

I know plenty about hardware, but I’m really a software guy at heart. If there is a way to do something in software, it’s usually cheaper, easy to duplicate for others, more flexible once deployed, and more adaptable in the long run. Which brings me to Pandora. I like the idea of Pandora (nearly commercial free radio based on a desired theme), but there are several problems with it. Some things I can’t do anything about, and it won’t really change. Pandora has a limited selection when it comes to certain themes. Hint: Type in Billy Crystal to get Pandora going. But, when a channel works, you often don’t want to reserve real estate on your computer, or resources on your phone while it’s in operation. In fact, you often want one without the other. Enter the Raspberry Pi.

This weekend I took one of my unused Raspberry Pi’s (I have at least five floating around!), and upgraded it’s copy of pianobar software to listen to Pandora using the output jack and a portable battery powered speaker. I noticed that pianobar supports a shared file mechanism to adjust channels, volume, and other aspects of play. I set the Raspberry Pi up in the corner with a battery pack-to-USB adapter I created which offers approximately four hours of continuous operation for the Pi. I added a portable rechargeable speaker system that can be plugged into the Pi’s audio output jack.

For a while, SSH worked well to control pianobar remotely. The Pi is wireless and can be used anywhere in the house. Because the power pack is mobile, and the audio outputs are self powered, the system is quite portable. The problem is control. Let’s say I want to bring the Pi downstairs so I can listen to some soundtracks while I eat lunch. I can’t easily change the channels, lower the volume, or pause the music. Sure, I could get an SSH app for my iPhone, but that’s not as easy to use as I’d like. I could also build various buttons on a breadboard hooked to the Pi, but then the system will be harder to duplicate, diagnose issues, and can’t be operated remotely. Finally, my kids aren’t going to be using SSH, so I need to a better control mechanism.

An idea occurred to me. What if I could control Pandora on the Pi from any web client. How about my phone? There are many ways to accomplish this, but the easiest would be if I could start with a mini web-server on the Pi. The web server could receive browser requests, issue the Pandora controlling commands using the shared file interface, and return information when appropriate to the client browser. If I wanted the page to invoke commands without refreshing, I’d have to use AJAX to issue the call and return the results to the GUI directly through JavaScript.

I did a little research and found a miniature C++ web server implementation which only responded to “get” commands – which is sufficient for this project. I quickly compile the example and restructured it for intercepting CGI ‘get’ calls. I wrote a simple command handler script in Perl to change the current pianobar channel (next, previous) using the AJAX methodology. I then hooked the two up so the CGI ‘get’ call from a served HTML page invoked the Perl directly. I proceeded down this path adding more commands to the single script file. In the HTML page I appropriately varied the “?XXXX” commands which were extracted and sent directly to the Perl script. With much success, I got all the basic functionality working remotely from Safari on my iPhone. I cleaned up the HTML GUI, and added bi-directional capability so Pandora responses could be fed back to a “status” line via AJAX on the client browser.

Adding voice feedback for Pandora operations was my brother’s idea, but it was pretty simple to add considering the Perl script was already handling each command separately, and audio and power was already being managed.

Thinking back, now, the results have quite a few advantages over other hardware solutions:

1. Pandora can be operated remotely.
2. Pandora can be remotely controlled by phones, computers, and tablets.
3. The GUI is easily extensible – just add to the HTML and Perl command script.
4. The Web Server and infrastructure can be re-used for other similar situations where you want to issue remote Raspberry Pi commands from a remote Web client.
5. The whole system is software based so it can be duplicated by just copying the Pi’s SD card and changing the network parameters.
6. The cost is minimal because the only hardware you need is the basic Pi, power, and speakers.
7. If desired, the Web Server could be exposed externally to the local router making the Pi controllable by any browser in the world!
8. The bandwidth requirements are minimal because the only traffic is the ‘get’ command and optional browser response.
9. The system is easy to debug because the server can display received commands and log errors to stdout (if run in the foreground while testing) as well as to a log file.

Number 4 cannot be understated. For example, the next project I began with a different Pi was a remotely controlled car. This was done using two bi-directional DC motors, and the same Web Server framework. The main difference was the Perl script. This time, instead of controlling Pandora, the Perl script was modified to send bursts of GPIO logic to the Servo controller board. The served HTML page was altered so it offered each of the possible directions for the car to travel. The Pi was then simply attached to the top of the car, and control was once again given to any remote browser. But, the Car Pi post is for another rainy weekend… 😉