One of the underlying themes of a few projects here at the Center for Civic Media is the idea that we can increase awareness and engagement in local communities by bringing already-centralized public information to people when and where they need it. As part of this goal we’ve created a relatively cheap digital electronic signage platform, primarily to showcase realtime transit and community calendar information. I want to share some of the technical details behind our current solution – scrolling LED signs controlled by a re-purposed router running simple software on top of TomatoUSB.
Our goal was to test our some ideas quickly, so the code is definitely under construction. If you’re interested, read and/or fork our code on GitHub:
- Realtime Community Sign – the Python scripts that run on the router
- Community Sign Server – the CakePHP web-app that manages the signs
Our primary platform for this signage has been scrolling LED signs controlled by a computer. These are robust, visible from afar, widely available, and a known commodity to the general public. Since our community partners’ information is online, we need these signs to be connected to the internet. The already-networked signs we found were expensive proprietary solutions with locked-in software that appeared hard to extend for our prototyping. This led us to install our first test sites with the LED sign being connected to a $300 netbook running a simple Python script (a solution a lot of people use).
Once the prototype signs proved useful we focused some more attention on engineering the cost down – culminating with the decision to connect the LED sign to a hacked up wireless router. These routers are commodity off-the-shelf products, and a robust community has built up around two open-source firmware options you can install on many of them (Tomato and DD-WRT). We opted to use TomatoUSB with the NetGear WNR3500. At $60 this router is a lot cheaper than a netbook! We used optware to get our Python scripts running on it, and now have a much cheaper digital sign control solution. Stitching this all together as a bit of a pain, so we’ve documented our setup steps copiously.
The last piece of the puzzle is the standard client-server design. Each sign is a dumb terminal, simply asking the central server what content to show. The server has a simple web administration interface that lets us assign transit or calendar information to various displays. Further reducing the complexity, and to match our community partners’ solution, we decided to import calendar feeds from other sites (Google Calendar is the main one so far). There are some data interchange standards for this type of transit and calendar data, and we’ve taken advantage of that where it was low-enough friction to do so. Centralized community calendaring is a hard problem, so we’re lucky to have partners that already have that in place.
We’re currently testing the impact of these signs in a variety of locations, so we’re not looking to expand just yet. However the code includes a bill-of-materials if you want to build your own network of signs. Let us know what solutions you’ve come up with for similar problems, or if you have ideas about how to improve our current platform!
