The Panic That Started It All
You know how it is. You live close to a major station, but not close enough. Bromley South. Great for getting into London fast, terrible for the last-minute dash. My routine was always the same: check the schedule on my phone, grab my jacket, bolt out the door. The problem? That schedule lies sometimes. Or rather, it doesn’t tell you the one thing you really need until you’re actually standing under the flickering station departure board: the platform number.
I swear, I missed the 07:43 fast service three times in one month because I had to get through the barriers, look up, realize it was Platform 4, and then sprint to the end of the station, only to see the doors closing. Pure rage. I kept thinking, why can’t I just have that platform detail instantly? Right there, on the screen, while I’m pouring my coffee.
So, I decided to stop running and start building. This wasn’t about fancy coding; this was about necessity. I needed a simple, big-text display for the next few trains heading north, and it needed to show the platform number the second the train company confirmed it. Nothing else mattered.
Wrestling the Data Beast into Submission
My first step was finding the data source. I went digging around the official train operator sites. They don’t exactly just hand over a clean list of “next train, time, platform” in giant letters. What I eventually found was the main feed—the huge, messy, constant stream of information that feeds all those public station screens. It was a ton of raw, complicated text. XML or JSON or whatever they call it; it looked like garbage to me. All I cared about was pulling out three things:
- The station code for Bromley South (got that easily).
- The scheduled time and the final destination.
- The current, actual, assigned platform number.
The first few attempts were a disaster. I wrote a quick Python script—I always use Python for these simple data wrangling tasks because it just feels less fussy—and it pulled everything. I was getting cancelled trains to places I’d never heard of, freight movements, test runs. It was information overload. It was slow and constantly broke because the feed was updating every few seconds.
I realized I had to filter aggressively. I spent a whole evening just figuring out how to tell the script: “If the train is going to Victoria, Blackfriars, or City Thameslink, keep it. If the status is ‘Cancelled,’ ditch it. If the status is ‘Delayed,’ keep the time but highlight it.”
The Platform Problem – The Real MVP
Here’s where the real headache began, and frankly, the reason this whole project was necessary. The platform detail. When a train is 15 minutes out, the platform number in the feed often says “TBC” (To Be Confirmed) or sometimes just blank. The train companies wait until the last possible minute to confirm the platform to avoid confusion if tracks need switching.
But that TBC is the killer. If I display TBC, I haven’t solved my problem. I still have to wait and run.
My solution wasn’t technically complex, but it was key. I structured the display logic to prioritize the platform field above all else. If the data feed came back and the platform field was empty, the display showed the time and destination, but the platform box just pulsed a faint grey color—a visual reminder that I needed to check soon.
The breakthrough: I added a special condition. As soon as the platform field populated with a number (say, ‘3’ or ‘4’), my script immediately triggered a change in the display. The platform number flashed bright green twice, and the font size for that single number ballooned up to fill the whole screen section for about three seconds before settling into its normal, large font size. This meant that even if I glanced at the screen from across the kitchen, that green flash would grab my attention and confirm the platform instantly.
From Code to Coffee-Side Companion
After I managed to reliably grab, filter, and display the platform number, the rest was just hardware setup. I didn’t buy anything new. I repurposed an old, cheap tablet that had been sitting in a drawer for two years. I mounted it on a little stand right next to my coffee machine. It runs a simple, full-screen browser pointing to the local file generated by my Python script, refreshing the display every 30 seconds to stay current with the official feed.
The font is massive, white text on a deep black background—high contrast, easy to read at a distance, even without my glasses. It shows the next four trains, clearly separated. The crucial element, the platform number, is always bold and centred.
Honestly, the time I spent wrestling that raw data feed and perfecting the timing of that green flash has paid itself back a hundredfold. I haven’t had to sprint to Platform 4 since. Now, while I’m waiting for the kettle to boil, I look over, see “07:55 Victoria,” and if the platform flashes “3,” I know exactly when to leave the house. No guessing, no barrier anxiety. Just instant, verified platform details, right in my own kitchen. It’s truly fantastic when a simple bit of practical coding saves you daily stress.
It’s a perfect example of why I share this stuff. It wasn’t built for a company or for money; it was built because the public information system sucked for my personal needs, and I decided to fix it myself. If you’re living near a busy station, you should absolutely dig into the data feed and build your own private departure board. Trust me, it changes your life.