The World Cup Scoreboard That Became a Cellular Test Rig
How an office World Cup scoreboard became a practical test of cellular reliability, remote management, and the LiveArc data platform.
So, I built a cellular-powered World Cup scoreboard for my office.
Mostly because I wanted a scoreboard. But I also needed a good excuse to test the cellular platform we’re evaluating for future Franklin Labs products.
Conveniently, I can’t use the office Wi-Fi for personal projects. So the Raspberry Pi behind this thing runs over an IoT cellular connection.
Problem solved. New collection of problems created.
The hardware is pretty simple: a Raspberry Pi, an Adafruit controller, and a 64x32 LED matrix. The software is where I got carried away.
It pulls live World Cup data, prioritizes the games people in the office care about, and automatically runs when there are games to show. It caches the last good data when the connection drops, adjusts how aggressively it polls based on cellular usage, reports its health back to LiveArc, and can recover from certain problems remotely.
I also built a private control panel and an office voting system so everyone could pick match winners.
Naturally, no one used the voting system.
The data flow looks roughly like this:
Sports APIs → LiveArc → Cellular → Raspberry Pi → LED matrix
LiveArc handles the aggregation of sports data and turns it into a compact feed. The Pi only asks for what the display needs, which keeps the device simple and avoids using cellular data to download a novel every 30 seconds.
The scoreboard has only been running for the World Cup games, but it already gives me a practical way to test:
- Cellular reliability and data usage
- Adaptive polling under a cellular data budget
- Remote device management and software updates
- Offline caching, recovery, and backend communication
- Whether a Raspberry Pi can survive living on top of a cubicle
I also recently signed our cellular service agreement because of it.
The scoreboard is fun, but it’s also a real device operating over the same kind of connection we’ll use in future Franklin Labs products. That makes it a lot more useful than another test rig sitting on my desk pretending to be deployed.
That’s generally how I prefer to test things: build something useful, put it somewhere inconvenient, and let it expose my bad assumptions before a customer gets the chance.
Sometimes the bad assumption is cellular architecture.
Sometimes it’s believing your coworkers want another app.
Precision Tech. Prairie Born.