TrainLight is a display by Sean Savage that communicates public transport information at a glance. The design assumes that the user already knows where they are going, and the public transport options to get there, and communicates just what they need to know (which bus is coming sooner) at a glance. I really like this project because of it’s simplicity and attractive way it displays the information.
Not only is TrainLight a cool project, Sean wrote up a great tutorial on how to build your own.
Electronics
TrainLight gets updates from the internet using WiFi via a Particle Core, but you’d want to use a cheaper and more powerful Photon if you’re reproducing the project today. Besides the Photon, you only need a strip of addressable LEDs, and a few parts to connect them together. Because the display is always on, it needs an external power supply.
Enclosure
The base for the enclosure is a block of Foam Core with a hole in it for the electronics, and the LED strip wrapped around the outside. The foam and electronics don’t need to be made to look pretty, as they are all covered by a canvas panel, and the LEDs project from behind the canvas onto the wall.
I like this enclosure as it’s made with easy to source materials, and there are no fancy tools required. It’s a clean look after it’s put together.
Software
TrainLight gets transit information from the NextBus API which supports a number of transit systems across the US and Canada. There’s a Ruby script that runs every 30 seconds to get data for eight transit stops and sends a summary message to TrainLight through the Particle Cloud. Additionally the parser depends on a Node.js proxy server called restbus to translate the API data from its original XML to a restful JSON format that’s easier to parse. This complicates replicating the project - at least for me - as I don’t currently have a server set up to run Node.js and Ruby apps, and with my electronics hardware and firmware background haven’t deployed something like this before.
The firmware is quite simple, and mostly just listens for the server to send the eight values representing minutes until each bus arrives, and then converts those values into colors to display on the LED strip.
I took a look at the possibility of replacing the server and Ruby script with Webhooks. Webhooks were made for JSON data, and the original NextBus feed is in XML. There at least needs to be another service to translate the data to JSON, so at a minimum, the restbus proxy server needs to be running on a server somewhere.
TrainLight checks eight transit feeds twice a minute. Each feed would need its own Webhook as they each have a unique URL. To have the same functionality using Webhooks, we would need to create eight unique Webhooks and trigger sixteen hooks per minute. Particle limits the total number of Webhooks a user can create to twenty - so this one project would take up a good chunk of your total hooks. Particle limits triggering to ten hooks per minute per device, not enough to reproduce the functionality. Given these limits, using Webhooks doesn’t seem like a good choice to replace the server completely.
Suggestions for the Next Version
While I think the project is quite good as it is, I can think of a couple improvements for a second version.
First, I would try to hide the power supply wire as it really takes away from the otherwise clean look of the project. This isn’t always a practical option as it pretty much requires putting a hole in the wall to route the power cord.
Next, I would use FastLED instead of the Neopixel library. FastLED would drive the LEDs at low brightness better than the Neopixel library, and gives options for changing up color palettes and helping with smooth fades between colors to make the project even more polished.