HN Debrief

I wanted a clock that never needed setting. Things escalated

  • Hardware
  • Developer Tools
  • AI
  • Open Source
  • Infrastructure

The article is a build log for a custom clock meant to avoid the usual annoyances of bedside clocks like losing time after power flickers, awkward daylight saving changes, and ugly consumer designs. The author ended up with a Raspberry Pi-based clock that pulls time from NTP, lives in a custom enclosure, and integrates with HomeKit. He also described leaning on a general-purpose LLM for parts of the Python and CAD work because those were not areas he felt strong in.

If you just need a reliable clock, buy or build around a simple radio, GPS, RTC, or ESP32-based design instead of a full Linux box. If you care about using LLMs for side projects, this is a good example of where they lower the barrier for a custom one-off without changing the fact that the underlying problem is already solved more simply.

Discussion mood

Lightly amused and mostly positive about the tinkering, with a strong undercurrent of "you could have solved this more simply." People were especially animated about two things: radio-controlled and GPS clocks already covering much of the need, and skepticism that a Raspberry Pi plus LLM help was the right level of complexity for a clock.

Key insights

  1. 01

    WiFi clocks quietly beat radio clocks indoors

    Off-the-shelf WiFi analog clocks came up as the most pragmatic answer once radio reception starts failing indoors. Several people said WWVB-based clocks were unreliable in places like Florida and North Carolina, while a cheap WiFi model that syncs once a day at 4 a.m. handled daylight saving time without any visible disruption. That sharpens the tradeoff. "Offline" sounds cleaner, but a low-duty-cycle WiFi sync can be less annoying in real homes than a weaker longwave radio signal.

    If your users will place clocks deep inside buildings, test radio sync before betting on it. A daily NTP sync over WiFi may deliver better real-world reliability than a theoretically simpler radio design.

      Attribution:
    • isomorphic #1
    • js2 #1
    • moduspol #1 #2
  2. 02

    GPS gets time fast but hardware limits matter

    The GPS side discussion added an important nuance. A receiver can recover accurate time before it has a full position fix, because timing is fundamental to the system, and the PPS output can give microsecond to nanosecond-grade edges. But cold start behavior still depends on what data the receiver has cached and what the hardware exposes. Off-the-shelf modules may not give you a fast, clean path to time the way a custom receiver would.

    Do not treat "GPS time" as a single capability. Check cold-start behavior, indoor sensitivity, and whether the module exposes PPS if timing quality actually matters.

      Attribution:
    • seba_dos1 #1
    • rcxdude #1
    • colechristensen #1
  3. 03

    There is no perfect indoor clock time source

    The most useful systems view was that every common approach fails somewhere. RTC chips drift and need a battery. Longwave radio needs quiet conditions and can be placement-sensitive. GPS struggles indoors. WiFi and internet time need credentials and more power. Even clever ideas like sniffing WiFi timing beacons are situational. That reframes the problem from "pick the best clock technology" to "pick the failure mode you can live with."

    Design around your acceptable failure mode before you choose parts. For a bedroom clock that often means favoring graceful degradation over theoretical purity.

      Attribution:
    • MathMonkeyMan #1
    • RetroTechie #1
  4. 04

    The useful novelty was tool access, not timekeeping

    What actually made the project interesting was not NTP or HomeKit. It was that someone who does not consider himself a programmer or CAD person still got a polished hardware object over the line. The author said he owned the architecture, packaging, installer, and deployment, while the model filled in Python and Fusion gaps. That is a more credible LLM use case than "AI invented a new clock." It compressed the skills gap on finishing work.

    For one-off internal tools or hardware prototypes, LLMs may be best used to unblock weak disciplines around a design you already understand. Keep ownership of the architecture and verification.

      Attribution:
    • lee_ars #1 #2
    • Animats #1
    • linehedonist #1

Against the grain

  1. 01

    Old atomic clocks already solve this well enough

    Battery-backed radio clocks were presented as the boring solution that already works. One commenter has used the same Phillips atomic alarm clock for 23 years with only daylight saving toggles. Others praised Seiko radio-controlled wall clocks and basic RV clocks that recover after battery loss on their own. That undercuts the idea that the underlying need was unsolved. In many places, it was solved decades ago.

    Before building around Linux, check whether mature commodity hardware already covers your requirements in practice. The missing piece may be aesthetics, not engineering.

      Attribution:
    • Frost1x #1
    • petepete #1
    • m463 #1
  2. 02

    A Pi is the wrong computer for a clock

    Several people objected less to the project than to the platform choice. Running a full Linux distro and Python to fetch and display time was called wasteful, especially when an ESP32, an STM32, or even a simpler dedicated microcontroller could do NTP sync, drive a display, and keep time on far less power and complexity. The jab about choosing distro upgrades over two yearly DST changes captured the mood exactly.

    If you want a productizable design, prototype on the platform that matches the final job. A Pi is fine for exploration, but it hides the constraints that actually matter in a clock.

      Attribution:
    • sasaf5 #1
    • hn_submit #1
    • mrheosuper #1
    • russdill #1
  3. 03

    Phone-paired clocks create avoidable lock-in

    Bluetooth time-sync clocks got little sympathy because they shift a simple function onto a proprietary app and pairing flow. The criticism was not about accuracy. It was about dependency. A clock should sync from open infrastructure like radio time, NTP, or a mobile standard, not from some vendor app that turns timekeeping into another channel for data collection and abandonment risk.

    Avoid designs that require a companion app for core device behavior unless the app adds real value. For basic infrastructure-like devices, standards-based syncing is a stronger product choice.

      Attribution:
    • dabinat #1
    • ButlerianJihad #1
    • lee_ars #1

In plain english

CAD ↩
Computer-aided design, software used to create 2D or 3D models for parts and enclosures.
DCF77 ↩
A German longwave radio time signal used by many European radio-controlled clocks.
ESP32 ↩
A low-cost microcontroller with built-in WiFi and Bluetooth, commonly used in hobby electronics and Internet of Things devices.
GPS ↩
Global Positioning System, a satellite navigation system whose signals also provide very accurate time.
HomeKit ↩
Apple's platform for controlling and automating smart home devices from Apple devices.
LLM ↩
Large Language Model, a machine learning system trained to generate and analyze text.
MSF ↩
The UK's longwave radio time signal broadcast from Cumbria for radio-controlled clocks and other systems.
NTP ↩
Network Time Protocol, the standard internet protocol used to synchronize clocks between computers and devices.
PPS ↩
Pulse per second, a precise timing signal often provided by GPS receivers for accurate clock synchronization.
RTC ↩
Real-time clock, a small hardware clock chip or function that keeps time even when the main system is off.
STM32 ↩
A family of 32-bit microcontrollers widely used in embedded electronics.
WWVB ↩
A U.S. low-frequency radio station that broadcasts accurate time signals for radio-controlled clocks.

Reference links

Radio time services and coverage

Clock projects and tools

  • Time Station Emulator
    Web app that uses speaker emissions to emulate radio time signals for clocks
  • Clock Wave
    Phone app mentioned for spoofing radio time signals when local reception is poor
  • ESPTimeCast
    Example ESP32-based clock project offered as a simpler alternative
  • rpiclock
    Related Raspberry Pi clock project with NTP sync status indicator ideas
  • ClockThing
    Another DIY clock project that reads an iCal feed for alarms
  • Precision Clock Mk IV
    Related precision clock build shared for inspiration

Commercial clocks and hardware examples

Time nerd references