Posted by KA9NWM
I stepped away from active development for a couple weeks in the middle of June. Life happens, I got very sick with a new flu variant and wow did it knock me down. It’s a solo project, so when I came back at the end of the month there was a real backlog of things I’d been meaning to finish before I could call anything an alpha release.
The first thing I picked back up was Remote View settings sync, something I’d scoped out earlier from feedback given by WB6RXG but never actually built. The idea is simple: if you open Helioclock from a laptop or phone browser on the same network instead of the kiosk display itself, you shouldn’t have to redo all your settings by hand. I added a SYNC FROM KIOSK button that only shows up on remote browsers, and had the server hand over the kiosk’s own settings file to seed the new session. My first pass at detecting whether a device had already been synced used file modification times, which sounds reasonable until you realize a remote client’s settings file will always be newer than the kiosk’s, since the kiosk isn’t the one writing it. That heuristic was broken by design, not by a bug, so I replaced it with an explicit kiosk ID file instead. I’d also floated the idea of a QR code for pairing, which was more complexity than the problem actually needed. The simple version works fine.
Right behind that, I built a Health Report panel: disk usage, memory, CPU temperature, uptime, load averages, and Node’s own heap and memory stats, all color-coded so a glance tells you if something needs attention. It sounds like a small admin feature, but for something meant to run unattended in a shack or a NOC for months at a time, being able to check on the box’s own health without SSHing in matters more than it looks like on paper.
By June 29th, all of that came together into v2.2.0, the version I’m calling the real alpha: something ready to hand to a trusted reviewer with their own N100 hardware, not just something running on my own bench. That’s a meaningful line to cross. Up to that point everything had only ever run on machines I controlled directly.
The last thing that started that week is one I’m genuinely excited about: a bootable USB stick SKU. The idea is that someone with an old x86 PC gathering dust could plug in a 32GB USB drive and have it boot straight into a full, working Helioclock appliance with nothing installed on their actual hard drive. I made the call to build it as a real full Ubuntu install onto the drive rather than a live, non-persistent boot, since a live overlay would have fought against everything the install script already assumes about a normal, persistent filesystem. I also renamed the install scripts to make the USB product’s identity clear (install-x86.sh became helioclock-install-usb.sh), and added the same wear mitigation work the SD card SKU already needed: tmpfs for logs and temp files, journald kept out of persistent storage, swap disabled entirely. A flash drive under 24/7 load needs the same protection an SD card does.
I closed out the month with a full production SOP document for the USB stick, covering everything from preparing a production PC to the final pre-ship checklist. It’s the kind of unglamorous paperwork that doesn’t show up in a demo, but it’s what turns “I built one that works” into “I can build these reliably, more than once.”
73,
Anthony, KA9NWM