Posted by KA9NWM
I keep getting asked some version of the same question: why does Helioclock feel different from a typical hobbyist dashboard project? The honest answer isn’t about ham radio at all. It’s about where I spent the first four decades of my working life.
I started as a broadcast meteorologist at a TV station in Lafayette, Indiana, back in April 1978 during and after my education at Purdue University. Over the years that turned into a second parallel career as a broadcast systems engineer, specifically building the weather display systems that run behind the meteorologist you see on your screen. Many of the systems you see on-air today evolved from work I did in the 1980’s and 90’s.That’s the background I’m building Helioclock out of, and it shows up in decisions most software developers wouldn’t think twice about.
One thing I’m really proud of from that era is my design for an RGB to NTSC composite video encoder board, seen below from 1985. It was the first ever to fit inside a PC, and it even had Genlock capability. Looks at all those trimpots! It would take me almost an hour to get that analog beast dialed it. The breadboard section was to handle a genlock quirk with a particular model of Grass Valley Group video switcher. Back in those days you didn’t write software to fix issues, you designed a circuit.
Here’s the thing about live television that’s hard to explain to someone who hasn’t worked in it: on-air is the one environment where software genuinely cannot fail. Not “shouldn’t fail,” not “rarely fails.” Cannot fail.
Here I am doing weather at KHSL-TV in Chico, CA where I started in 1987. This photo was taken around 2005 I believe. The second photo is me with the “green screen.”
There’s an old line, borrowed loosely from NASA flight director Gene Kranz and the Apollo 13 story: failure is not an option. In a mission control room, that’s about getting three astronauts home alive. In a TV studio at 6:00 PM, it’s a smaller stage, but the same discipline applies: failure on-air is not an option, because there is no pause button, there is no “let me restart that,” and there is no second take. If the weather graphics system hangs during a live severe weather cut-in, that’s not a bug report, that’s a viewer who needed to know a tornado warning was issued and didn’t get it in time. I spent years building systems that had to work correctly the first time, every time, with zero tolerance for “it usually works.”
That’s the lens I look at Helioclock through, and it explains a lot of choices that might otherwise look like overkill for a hobby clock app.
It’s why “no central server, no single point of failure” isn’t just a marketing line, it’s the same architecture instinct that kept a station on the air when a network feed dropped: never build something whose failure takes everything else down with it. It’s why I care about SD card and USB wear mitigation to a degree that probably seems excessive for a clock display, moving logs and temp files into RAM, disabling swap, tuning journald. In broadcast, storage failures happen quietly, at 3 AM, on a system nobody’s watching, and you find out about them at the worst possible moment. Building for that failure mode before it happens is just how I was trained to think. It’s why I insist on real health monitoring (disk, memory, CPU temperature, uptime) baked into the product itself, rather than something you bolt on later. A weather system that can’t tell you it’s about to run out of disk space is a system that fails silently, and silent failures are the ones that hurt you on-air.
It also explains something about how I work day to day, even in these development sessions. I don’t let code changes go out on a hunch. Every build gets checked before it deploys. Every visual bug gets traced to its actual root cause, not just patched at the symptom, because in broadcast a graphics glitch during a live segment usually turns out to trace back to something structural, and papering over the symptom just means it comes back at a worse moment. That discipline isn’t paranoia. It’s just what four decades of “this has to work, live, right now” does to how you build things.
Helioclock isn’t a broadcast graphics system (but it acts like one.) Nobody’s safety depends on whether a DX cluster panel updates on time. But I’d rather build it like it does, than find out the hard way that I should have.
73,
Anthony, KA9NWM