A One-Board Bus Display That Survives Kapadokya Dust

The minibus office in Göreme runs a 32-inch screen on the wall showing the next three departures. It was a Raspberry Pi 3B+ with a cheap HDMI panel, LibreOffice Impress in slideshow mode, and a USB stick somebody swapped each Monday. Version details matter here because the failure was not the software: after about five weeks, the screen went pale and the Pi’s CPU temperature sat at 78°C in July, and the panel’s bezel had a visible film of tuff dust inside the glass.

What I changed was not the slideshow. I moved the whole thing to a plain framebuffer text renderer and stopped using the desktop session entirely. The Pi boots to a console, runs a small Python loop, and writes directly to /dev/fb0 via a 1024x600 surface. Departure times come from a CSV that the office edits in a browser on a phone.

# /boot/firmware/cmdline.txt additions
console=tty1 consoleblank=0 logo.nologo quiet

# /etc/systemd/system/busboard.service
[Service]
ExecStart=/usr/bin/python3 /opt/busboard/render.py
Restart=always
RestartSec=5

The render loop is boring on purpose:

import csv, time
from PIL import Image, ImageDraw

W, H = 1024, 600

def frame(rows):
    img = Image.new('RGB', (W, H), (0, 0, 0))
    d = ImageDraw.Draw(img)
    for i, (dest, t) in enumerate(rows):
        d.text((40, 80 + i * 120), dest, fill=(255, 255, 255))
        d.text((640, 80 + i * 120), t, fill=(255, 210, 80))
    return img

while True:
    with open('/opt/busboard/times.csv') as f:
        rows = list(csv.reader(f))[:3]
    frame(rows).save('/dev/fb0')
    time.sleep(30)

The mechanism, and the cost: no compositor means no GPU memory pressure and no X crash, but also no fonts beyond what I install, no cursor, and no easy screenshot. Rendering every 30 seconds instead of on change is wasteful but keeps the loop stateless; if the CSV is half-written, the next pass fixes it. I put a small 5V fan on the case and a piece of window screen behind the intake. The dust film stopped growing.

Where this breaks: the panel itself is the weak point. After two summers the backlight dimmed unevenly, and the fix was a replacement panel, not code. Also, /dev/fb0 writes assume the framebuffer driver matches the panel’s native resolution; on a different Pi model or a HDMI-to-LVDS adapter, the byte layout changes and the image tears or shifts. I hit that when a spare Pi 4 went in and the colors came out blue-swapped. And if the office ever wants video or a map, this approach is the wrong base.

If you have run a public-facing display through a hot, dusty season, what did you do about the panel rather than the software?