The history of amateur radio clusters
The image above shows a typical Cluster node in Kuala Lumpur, using DXSpider.
In the era before Cluster, DXers (those who enthusiastically pursue and strive to contact distant stations) could only rely on verbal exchanges, sending QSL cards via mail, or listening to the "DX window" at 14.195/14.200 MHz, which was extremely inconvenient and often missed propagation windows.
Here, let's start with a definition of DX Cluster:
A DX cluster is a network system that allows amateur radio operators to share real-time information about active DX stations. When an operator identifies a DX station on a particular frequency, they can "discover" the station by reporting detailed information to the cluster. This information typically includes the station's call sign, frequency, mode of operation (such as CW, SSB, or digital), and signal strength.
Please note that it is a network system, not a specific protocol or software. In fact, there are multiple software applications that can function as DX Cluster nodes (see below).
The origins of DX clusters can be traced back to the 1980s, when amateur radio operators began using early computer networks to share information about active DX stations. Initially, these efforts relied on group radios.（AX.25）— A digital communication method that allows operators to exchange data via radio frequencies. Early DX clusters operated as independent service nodes, while other general stations communicated with the DX cluster via radio and downloaded the latest DX information. At this time, there were no explicit protocol specifications between the clusters, and communication content was relatively loose, more like a BBS system. These early clusters laid the foundation for today's advanced networks.
The shift came with "PacketCluster," which Dick Newell is credited with developing around 1988-1989 (the AK1A was first publicly demonstrated at the 1989 Dayton Hamvention). PacketCluster played a key role in the development of modern DX clustering systems.
The PacketCluster trademark was acquired by Aether Systems in 2000, and since then, it has ceased official maintenance within the industry. Only a few government or rescue networks continue to operate privately.
PacketCluster works as follows: It also relies on a radio link layer protocol called AX.25, but it defines certain plaintext keywords such as DX, ANNOUNCE, SHOW/FILTER, and SET/NOVICE. In this design, there is no distinction between servers and clients; each node is equal to every other node, and many nodes form a "cluster" or "group."
However, in the mid-to-late 1990s, a three-tier architecture emerged: "master node - funnel node - user." The user end had devolved into a pure client (sending commands but not receiving radio signals). With Internet access, the nodes we see today are actually divided into two layers: a hybrid backbone node that combines radio and internet (still running Cluster protocol) and a pure Telnet client (such as logging software on a user's device), which is no longer an "equivalent node."
Each radio node operating a PacketCluster (which should be said, the radio is connected to the computer running the software) listens for one or more other radios that have installed the software. These connected nodes are called clusters. The clusters connect to each other, expanding the air network. They use the protocol to send packets and communicate with each other.
Individual users connect to the node via radio frequencies, unlike the link with node stations. Users can announce DX points and related announcements, send personal call messages, send and receive email messages, search and retrieve archived data, and access data from information databases.
After the PacketCluster was introduced, any enthusiast who connected to a node could send short messages like "3XY1D0 21.025 MHz CW" to the entire network in just one minute. Others could easily know (for example) when a rare Liberian radio station went online without having to wait. The set of plain text commands – DX, ANNOUNCE, SHOW/FILTER, SET/NOVICE – became the de facto "protocol" for all PacketCluster software later on.
Although the PacketCluster user base is declining due to the shift in ownership, currently, the trademarks and software rights are held by Aether Systems. It serves law enforcement and fire rescue departments in the United States, with over 40,000 users (data provided by Aether in 2003; current status unknown).
The DX cluster offers several benefits to amateur radio operators: HAMs can focus on specific locations rather than randomly scanning the bands, which saves time. Furthermore, by providing real-time activity information, the DX cluster allows HAMs to stay informed about band conditions and propagation trends, uncovering new DX opportunities. This makes it easier to find rare stations or achieve goals such as "all-state commuting" (in the US).（WAS）Or DX Century Club（DXCC）The threshold for achieving award milestones.
With the emergence of the internet in the 1990s, DX clusters developed into globally accessible systems that were part-internet and part-amateur radio. As the internet connection became more stable and reliable, DX cluster networks gradually transitioned to using the internet infrastructure: amateur radio stations used the internet toTelnet protocolThey are interconnected to collect DX spots, messages, and announcements, and to exchange emails. This is similar to early telnet BBS systems or fido-net.
This shift significantly increased both the number of users and the amount of information shared. Over time, these platforms introduced advanced features such as filtering, alerts, and maps, which greatly enhanced the DX experience.
Many new HAMs struggle to decide which node (server) to connect to, but in reality, there's little difference. Currently, most public nodes/clusters are interconnected, and when someone "discovers" a DX site connected to a cluster, that cluster will share the data with all other clusters, so the data appears almost instantly on them. The only difference between DX clusters is their interface and functionality – so you can choose whichever one you prefer.
(Image above: SpotCollector developed by DXlabsuite)
Although PacketCluster is still in use today, after thirty years, many nodes are replacing it, such as AR-Cluster.CC ClusterCLX, Clusse, DX Spider, DxNet
| Achieve | Platform | The main extensions to the original protocol. | Typical node |
|---|
| DX Spider | Cross-platform / Perl | SET/DX_GRID, script plugin | ve7cc, hb9wdf |
| AR-Cluster | Win/.NET | Memory database, JSON/SPIDER | dxc.nc7j.com |
| CC Cluster | Win | Private network for competition, zero configuration. | (Self-built) |
The DX Cluster ecosystem has largely stabilized, and can be broadly divided into three software implementations (based on my observations):
1. DX Spider: This is an open-source, cross-platform solution with the largest number of nodes, and its maintainers continue to use Perl for incremental updates.
There is also the new AR-Cluster, "冉冉升起的新星", which can only run on Windows/.NET platforms. Its official node is dxc.nc7j.com, and it is used as a data source by RBN (Reverse Beacon Network).
RBN can be seen as a "self-service spot provider" for the cluster, but communication between RBN nodes uses its own XML/JSON protocol, rather than the traditional cluster protocol.
Within the competition, you can see the CC Cluster (Contest Cluster) in action. This implementation focuses on the competition team and allows the team to use their own servers within a local network to achieve sub-millisecond local spot distribution, which is suitable for multiple users operating the same competition call sign.
There are other software options available, such as Clx and Dxcng. They appear to be primarily used by European HAMs for local maintenance and operation, with a smaller user base.
As previously mentioned, DX Cluster is a loosely defined network system. One of its ongoing challenges has been the lack of clear protocol specifications and unified APIs, relying instead on long-standing conventions (such as).DX 9A1P 7.005 5999 3Z50P"This simple, 80-byte fixed-length string is used for exchanging information. The new cluster, in order to maintain compatibility, can only introduce new features as private extensions, such as the AR-Cluster's "JSON/SPIDER" instruction and the DX Spider's "SET/DX_GRID" instruction, which slows down its evolution. However, we can still see the efforts of new technologies in the backend architecture, such as the AR Cluster using multi-threading and an in-memory database, along with filters, a user command set, a high-performance telnet server, and decoupling of the interface and background processing."
Regarding 80 bytes: Actually, the maximum size of an early AX.25 UI frame was 256 bytes, and PacketCluster truncated a single line to fit with Packet-Radio compatibility. 70-80 characters, this is a deliberate truncation, following an established convention for effective length.
Regarding why strings are written in that particular format: The original PacketCluster implementation used spaces to separate fields, resulting in a total of 6 segments.DX + Call sign + Frequency + Mode/SNR + Notes + Spotting tableLater, Spider allowed arbitrary fields to use "_" instead of spaces, which enabled support for grids and IOTA, among others.
Several competition/log software packages include a Cluster function (based on the telnet protocol), such as DX Summit and N1MM. Users do not need to install them separately. There is also one piece of software that I'm not sure if anyone remembers, DX Atlas's CW Skimmer (which is sometimes jokingly called the "skimmer") also has a server-side component, which is essentially a (private protocol) Cluster. Some services directly provide web-based access (rather than through the older telnet protocol), such as DXHeat.
(I originally intended to write about how a typical HAM radio operator can start using the DX Cluster functionality, but since there are likely people who already have the ability to learn on their own, I won't start from scratch...)
闽ICP备2021006864号-7
闽公网安备35020602002794号