LED Panel Apps · October 21, 2026
How a Live Sports LED Scoreboard Works: Lessons From Running One Across Four Leagues
A live sports scoreboard on an LED matrix looks simple: fetch a score, draw it. Running one every day across MLB, NFL, NHL and NBA showed that most of the work sits elsewhere: who a team is, when to draw, what is allowed on screen, and what to do when the data says nothing.
These notes come from a Raspberry Pi 4 driving two 128x64 HUB75 panels (a 256x64 canvas) through a Wi-Fi MatrixPortal S3. The same lessons apply to a single 64x32 panel.
1. A scoreboard is three separate jobs
- Data: fetch schedules, live game state, standings and team metadata on its own timer.
- State: decide what should be on screen right now, and why.
- Drawing: turn that decision into pixels at a fixed frame rate.
Keep them apart. If drawing waits on the network, a slow response freezes the display. If the data layer decides what to show, every new league adds special cases everywhere.
2. A team is not its abbreviation
"PHI" is four different teams: the Phillies, Eagles, Flyers and 76ers, each with its own id, colors and logo. A cache keyed by abbreviation shows the wrong badge and colors the first time two of them appear in one session. Key every team by league + provider team id, and treat the abbreviation as display text only.
3. Never touch the network during a frame
Team colors, logos and metadata are fetched ahead of time, written to disk and loaded from there. A frame only reads memory. At 8 frames per second you have 125 ms per frame, and one slow image request is a visible stutter.
4. Use wall-clock frame timing, not sleep(1/fps)
Measure how long the frame took and sleep only the time that's left. If a frame runs late, skip it rather than queueing it. Sleeping a fixed 1/fps after the work drifts slower over time; queueing late frames builds a backlog that plays out as a fast-forward burst.
5. Text and logos need opposite treatment
On a 64-pixel-tall display, anti-aliased text reads as blur. Use bitmap fonts drawn one pixel per pixel (the public-domain X11 "misc-fixed" fonts work well) and threshold glyphs hard. Logos are the opposite: thresholding a 30-pixel crest destroys it, so scale it with a smooth filter and keep its alpha.
6. Decide what's allowed to take over the screen
A live game interrupting whatever is on the wall is a strong action. A priority ladder keeps it predictable:
- Alerts (for example a doorbell or a print finishing)
- A scoring event for a favorite team (a celebration)
- A game you picked by hand
- An automatic live game for a favorite team
- A page you picked
- Pregame countdown
- Idle rotation (weather, standings, upcoming games)
Only a short, explicit list of favorite teams should take over automatically. Every other game is one you choose. When the higher item ends, the display returns to what it was showing.
7. Don't invent data the feed doesn't have
Every sport exposes different live detail. Baseball can give bases and outs; football gives possession, down, distance and field position; hockey gives shots on goal. If a field isn't in the feed (pitch count, in this case), leave it off the screen. A made-up number on a scoreboard is worse than a blank.
8. Check the result, not the process
A service reporting "running" doesn't mean a frame reached the panels. Useful checks read evidence from the display controller itself: frames received, uptime after a power cut (a real power cycle resets it; a fake one doesn't), and whether the panel accepted the last frame.
9. The data and logo question
Most hobby scoreboards use unofficial, undocumented sports endpoints and team logos. That's a personal-use decision. Team logos are trademarks, and an unofficial endpoint comes with no commercial terms, so a product sold to other people needs a licensed data source and should ship with team colors and abbreviations rather than bundled logos. That's the main reason our Raspberry Pi sports scoreboard is still in development.