MPK Departure Board at the Bus Stop

Electronic departure boards are usually a significant expense and a closed system from a single supplier. I checked how much could be done using the public data of the carrier, an ordinary monitor, and a small computer.

The first board is prepared for the Os. Słoneczne stop in Stary Sącz, served by MPK Nowy Sącz. The board's page can be accessed at bus.starysacz.um.gov.pl, and the kiosk displaying it is awaiting installation in its enclosure.

Visible from several meters away

A bus stop display is not a website. People don't click on it, scroll through it or read it from close range. So, I only took the identity - fonts, color palette and shapes - from the municipality's template. The rest was designed for an outdoor screen:

• dark background that doesn't glare at night and doesn't reflect the sun as strongly as white,
• the bus line number as the only colourful element,
• hours in fixed-width digits so they don't jump when minutes change,
• each state described by words, such as “ahead of schedule 2 minutes,” rather than just color,
• the layout adjusts automatically: two columns side by side or a list for larger hubs.

Data that nobody described

MPK Nowy Sącz has two public data sources, but none of them are documented. The file with predictions covers the entire network, over 550 stops, but provides relative time and hour without date. The schedule is complete, but it knows nothing about delays.

The municipal server connects both sources. The timetable is the base, and the forecast is the correction: for each trip, the display shows the scheduled time and how much the bus is delayed or early.

On the way, errors in the carrier's data came to light, for example, reversed columns on one of the lines. The corrections are in a separate configuration file, so there is no need to look for them in the code.

The Kiosk with No Secrets

There's a small computer with Debian and Chromium in kiosk mode standing next to the bus stop. It only knows its own display address. It doesn't have API keys for the transport operator or SMS gateway because eventually, someone will open the device on the street.

• connects to the server via VPN, logging in only with a certificate,
• it restarts every night at 4:00 and is monitored by a watchdog during the day
• the superuser account can only perform a few strictly defined commands,
• when forecasts stop coming in, after 10 minutes the board returns to just showing the schedule instead of displaying old delays.

SMS Supervision

The monitoring service runs on a separate server, alongside the city's own SMS gateway. It checks the kiosk, the display server and MPK data every minute. The administrator receives an SMS when:

• the kiosk does not ask for data for 10 minutes,
• the kiosk restarted unexpectedly, for example after a power outage,
• the temperature inside the enclosure exceeds 75 degrees Celsius or the disk fills up,
• MPK data or the timetable stopped updating.

It also works the other way around. The operator can check the status of the kiosk or request a reboot via SMS, without having to go to the stop.

One system for multiple stops

There is no actual stop in the code. The display is described by an entry in the configuration: bars, layout, and direction descriptions. The server still retrieves the entire MPK network, so another display is a new entry and the same system image on another computer.

I provide the departure data through the public API of the municipality, in the same format as other services. The municipal portal, mobile app, or information kiosk at the office can use it. The same kiosk mechanism is already working on the boards in the hall of the office.

Stack

• Node.js service for departure times at Node 24 and TypeScript, data snapshot on disk instead of a database,
• Astro page for the bus stop board, Tailwind v4, self-hosted fonts,
• Debian, cage and Chromium in kiosk mode, systemd, WireGuard,
• supervision in Python without dependencies, custom SMS gateway,
• Docker, CI on OneDev.