HamClock is a small information panel designed for the radio station: it displays the position of radio amateurs on a world map, propagation conditions, solar data, satellites, and a series of other information useful for radio operations. Born as an extremely lightweight application, running both on Raspberry Pi and ESP32, it was for many years an almost ubiquitous presence on ham radio stations.

After the death of its author, Elwood Downey (WB0OEW), and the consequent end of the infrastructure that powered it, it seemed destined to quickly become a piece of history. And yet, months later, HamClock is still working: no longer thanks to a single infrastructure, but thanks to the work of the community that has taken up its legacy.

Info

The death of Elwood Downey (WB0OEW), creator of HamClock, suddenly left not only a program, but above all the infrastructure that powered it, without its driving force. To the user, HamClock appeared to be a self-contained panel, but in reality a significant part of its operation depended on services managed by Clear Sky Institute: solar data, propagation, maps, feeds, and other information were aggregated by the infrastructure that Downey had built and maintained over the years.

With the end of the original service, announced for June 2026, the problem became a reality. The client code had not disappeared: HamClock was, and remains, open-source software distributed under the MIT license. But having the code does not necessarily mean having the services that code expects to find on the other side of the network. And it is precisely this distinction that makes the story of HamClock so interesting.

For older installations, the problem is particularly evident: the original client had been designed around the Clear Sky Institute infrastructure and did not provide a simple, generalized mechanism for replacing the backend. When the original services began to degrade, therefore, the problem was not so much the program installed on the Raspberry Pi or ESP, but what was on the other side of the connection.

The amateur radio community thus found itself facing a rather unusual choice: abandon HamClock and replace it with something completely different, continue maintaining the original client, or rebuild the infrastructure required to make it work.

The paths that emerged are essentially three, and they are interesting precisely because they represent three different philosophies.

OpenHamClock

If HamClock was an application written in C, designed to be extremely lightweight and capable of running practically anywhere, starting with small ESP modules, OpenHamClock instead comes with a decidedly more modern architecture: an open-source web application (MIT license) with a React frontend and Node.js backend, developed by the community around Chris Hetherington, K0CJH. The backend acts as a proxy and aggregator for the various external sources, while React handles the interface.

We are no longer dealing with a small program that talks directly to infrastructure built around it, but with a real web application capable of integrating different sources, with functionality greatly expanded compared with the original: DX Cluster, PSKReporter, POTA and other activation activities, weather data, satellite information, various propagation layers, and a plugin system for adding new layers to the map. For those attached to the original look, a Classic layout has also been retained, with panels and colored characters on a dark background: at least visually, the transition is not traumatic.

Naturally, this architecture comes at a price: OpenHamClock is no longer a small standalone binary that can be installed anywhere, and local installation is more demanding in terms of dependencies (the project nevertheless provides procedures that help deployment on a modern PC or Raspberry Pi). And there is another important difference: OpenHamClock does not eliminate its dependence on the Internet and external services, but changes it. The backend continues to aggregate data from numerous sources (NOAA, POTA, SOTA, PSKReporter, CelesTrak, Open-Meteo, DX Cluster, and others), thus moving from a vertical dependency on a single infrastructure to a horizontal dependency on a constellation of independent services.

For those with a Raspberry Pi or PC and no particular need for compatibility with older hardware, OpenHamClock is probably the most modern and feature-rich solution.

OpenHamClock is available online, with the repository on github.

But it is not the only path.

HamClock lives on

The second possibility is perhaps the most interesting for those who do not simply want to replace HamClock, but want to continue using Elwood’s work: the original Clear Sky Institute source code has not been lost, since the client was released under the MIT license and the community was therefore able to take it, preserve it, and continue developing it.

Today the reference point is the repository on github, which explicitly presents itself as the primary source for maintaining the client. The project started from the source code of version 4.22, the last one produced by Clear Sky Institute, and keeps the original client as a frontend compatible with evolving HamClock specifications. This is an important detail, because it distinguishes the project from a simple historical archive of old versions: the code has not merely been preserved (it is available online on github), but has become the basis for a community continuation of the client.

The main problem remained, however: the client alone was not enough. A backend was needed, and this is where Open Hamclock Backend, abbreviated OHB, comes in. It is worth noting that it was Downey himself, in release 4.22, who added the -b option to point the client to an alternative backend: a technical detail that proved decisive, because it is precisely this mechanism that later made it possible to connect to a replacement backend such as OHB.

Open Hamclock Backend

OHB is probably the most interesting answer for those who want to continue using the old HamClock without depending on the original Clear Sky Institute infrastructure. It explicitly presents itself as an open-source replacement backend: it maintains the interface of the original client by generating propagation data, maps, and feeds from publicly documented sources, and can run on relatively modest hardware, including a simple Raspberry Pi 3B+.

The interesting point is that OHB does not force all users onto a single new central server: the backend can be installed locally and become an integral part of the station. It is precisely this possibility of distributing the backend across multiple independent installations that directly addresses the problem that emerged with the end of the Clear Sky Institute infrastructure: the project explicitly states that it aims to mitigate the risk of a new centralized infrastructure through independent and federated instances. There is also a public instance, accessible through ohb.hamclock.app, for those who do not want to manage the backend themselves; but those who prefer maximum control can install it on their own machine and make their installation essentially independent of a single centralized service.

This is not a minor philosophical difference. With the original HamClock, we had an open-source client but a strongly centralized infrastructure; with HamClock and a self-hosted OHB backend, we can instead have both the client and the backend under the control of the community or, if we choose, directly under our own control. Naturally, this solution does not make the system completely independent of the Internet either – OHB continues to use external data sources – but there is no longer necessarily a single point through which all users have to pass. And this is probably the most interesting outcome of the whole story.

Three different ways of carrying on HamClock’s legacy

At this point, the three paths are quite clear. OpenHamClock takes the original idea and completely reinterprets it, building a new, modern application that is richer and easier to extend. The Open Hamclock HamClock project, on the other hand, maintains the original client, preserving its philosophy, interface, and compatibility, while progressively separating it from the old Clear Sky Institute ecosystem. OHB addresses the most delicate point, the one left uncovered after the end of the original services: rebuilding a compatible backend and, above all, making it distributable.

This is therefore not simply the story of a program that risked dying with its author, but also a small lesson in open source. At first glance, HamClock seemed like a perfect example of free and independent software: the code was available, the program could be installed locally, and it could run on extremely inexpensive hardware. But open code does not necessarily mean decentralized infrastructure. When Elwood Downey passed away, the code did not disappear: what disappeared was the service that code relied on. And this is precisely where the community was able to make a difference: some chose to rewrite the application, some to continue the original client, and others to rebuild the backend: three different approaches to the same problem, made possible by the fact that the code was open.

In the end, therefore, the question is not simply which HamClock to choose. It is also how much dependence on external infrastructure we are willing to accept.

And perhaps this is the most beautiful part of the story: HamClock has not simply survived the death of its author: it has begun to become something different, built no longer around a single person and a single infrastructure, but around a community.

And, ultimately, that is what open code is all about.

Info