Rationale for a Ham Radio Meta-Spotter

Written on Thursday 25 September 2025

I’ve been thinking on-and-off for a few months now about extracting the back-end of Field Spotter into its own, separate thing—a sort of meta-cluster of portable ham radio spots. This post is a bit of an attempt to get my thoughts in order—most importantly, should I bother?

Rationale

  1. Field Spotter is entirely web-based, meaning that every FS user’s device is querying all the APIs for POTA, SOTA etc. individually. I don’t know how many users FS has at any moment in time, but if there’s quite a lot, that’s adding up to quite a few API calls that probably return the same result. By turning the API call aspect of FS into its own thing, that would become my issue to deal with and may reduce the impact on the upstream APIs.
  2. Being entirely web-based, FS has to deal with CORS. The Parks’n’Peaks API doesn’t support it, so we would already need a work-around in some server-side code. HEMA doesn’t even use HTTPS, so same problem there. Extracting the API calls into server-side code would avoid this problem. It would also mean I could set a custom User-Agent string, which is one of the T&Cs of a couple of APIs which I am currently just ignoring.
  3. I could simplify FS’ code a lot by having data already in a consistent format at the time it arrives at the client. Currently, all the APIs work in slightly different ways, like frequencies in kHz vs MHz, whether n-fer references are natively supported, whether a separate lookup is required to get a lat/lon point for a reference, etc. This logic could be dealt with separately to the client-side code.
  4. It might be useful to someone else, who could build their own neat front-end.
  5. I could include more sources of data that aren’t immediately useful to FS, such as generic DX cluster spots, APRS.fi or APRS-IS, packet node communications, RBN, etc.
  6. I could make it neat and extensible for other people to write plugins.
  7. As well as a JSON API that FS would consume, I could make it a nice tabular web interface with lots of filters which might be useful.

Anti-Rationale

  1. It’s another point of failure in the Field Spotter system, and another thing to separately maintain, allocate server resources for, etc.
  2. It’s quite a lot of work, when I probably have better things I should be doing with my time.
  3. There are plenty of DX cluster websites out there already which have the same kind of user interface and most of the same data as I would have, so for people just interested in the “DX cluster experience”, mine would offer very little extra.
  4. Polling all the separate APIs probably isn’t the long-term solution, and time might be better spent convincing the xOTA programmes and existing clusters to do something a bit more modern, like sending data to a central MQTT server that anyone could subscribe to.
  5. Obligatory xkcd

xkcd #927: Standards

  1. S50CLX Cluster—takes xOTA API spots and provides them as a telnet DX cluster
  2. DXHeat—General DX cluster web UI, has a websocket API which its own page calls internally, no accurate lat/lon or park refs, not sure of how external access might work or whether they would be open to me using it
  3. DXWatch—General DX cluster web UI, has a JSON API which its own page calls internally, might have most of the data I’d need, no CORS headers, unsure whether they would be open to me using it
  4. DXSummit—General DX cluster web UI, has a JSON API which its own page calls internally, no accurate lat/lon or park refs, does allow cross-origin requests, unsure whether they would be open to me using it
  5. DXClusterAPI e.g. spots JSON—telnet cluster to JSON API, reference implementation using dxcluster.oevsv.at—node.js/Docker based, no accurate lat/lon or park refs, but open source so could be built upon
  6. DXClusterMap—Kotlin based, provides map and table, closed source, supports POTA but no accurate lat/lon or other xOTAs, websocket communication with backend, not sure of how external access might work or whether they would be open to me using it
  7. DX cluster parser in Python
  8. DX cluster listener in Rust
  9. Prototype telnet cluster to MQTT code (via Discord)

Thoughts are welcomed from anyone with an interest in ham radio, clusters, xOTA spotting, or software in general! I’ve already asked for input via Discord and Fedi but if you’re arriving here from elsewhere and feel like leaving a comment below, please do. I’ll be updating the page as I think of more things for or against doing this.

Comments