If you travel on the British rail system, you’ll be familiar with the ubiquitous orange dot-matrix departure display boards. At a glance they tell you the expected arrival times of the next few trains, where they are headed, and at the bottom the current time. [Chris Crocker-White] was inspired by a Tweet to recreate one of these displays in miniature and hang it under his monitor.
The hardware is a Raspberry Pi Zero with an OLED screen, in a custom 3D-printed case. A soldered USB cable takes power from the monitor’s USB ports. Software wise it’s a demonstration vehicle for the Balena cloud service that pulls its data from their transport API, but the choice of dot matrix typeface is perfect and absolutely looks the part.
There is some question as to whether a project such as this one should need a cloud service as its backend, and of course it serves as a demonstration piece rather than a definitive way to enact a departure board. It does however bring a ready-packaged API for transport data, which given that many data sources can be opaque, is a useful feature.
Train time displays seem to be a popular choice on the Eastern side of the Atlantic, here’s another British one, and one from Ireland.
Thanks [Pyrofer] for the tip.
I like the question whether such services should be cloud based. I’d argue that yes, that’s probably one of the key applications of web services: giving you information about the state of affairs in someone else’s complex system (here: trains).
However, there’s a nice solution for many of the radio-powered train departure boards:
http://2015.sdra.io/pages/programme.html#radio-data-channel-reverse-engineered
Get out your SDR, capture the data broadcasted on the data channels coming with most modern FM radio stations, do a bit of smarts, and get your departures without having to go outside.
Regardless of whether you call the backend a “cloud service” or just a backend… doesn’t it have to access one in order to provide updated data? How would it function without one? Hard coded departure times?
Does this one copy the annoying bug on the real departure boards that happens when the current train leaves? On the real boards, when the train leaves the station it disappears from the board and the next train moves up the list on the board, but then there is a an extra animation where an X scrolls across the screen deleting that train off the board and then the train reappears again on the board.
Always infuriates me that nobody has fixed that in the years that these boards have been in use. This is a pretty cool project though.
If you;re after London departure data, you can skip the cloud service and talk to their API directly: https://api.tfl.gov.uk/
Similarly, many North American systems make their data available on nextbus: https://www.nextbus.com/
Reminds me of the ones used by the MTA here in the US, (NY) for the LIRR and MetroNorth, And as it happens that the display uses similar methods.
I hope he’s got ‘delayed’ and ‘cancelled’ hard coded somewhere in the firmware.
10:52 Bournemouth, expected 11:58 !
It’s not Swiss or Japanese rail, for sure