ClusterDX has spots but it is not a DX Cluster

ClusterDX has been part of the routine of many 11-meter operators for years. Open the platform, check the spots, search for a call sign, verify who is active and follow what is happening on the band.

At first glance it appears to be an evolved DX Cluster.

But technically there is an important difference.

ClusterDX has spots, but does not function like a traditional DX Cluster because it is not part of an interconnected server network that exchanges those spots among themselves.

It is not a pedantic debate about whether everything should continue entering via Telnet and be seen with green letters on a black background. Clusters are also evolving and adopting new technologies.

The question is different.

A cluster is not defined by how it draws the spots on screen.

It is defined, above all, by how it circulates information.

And there ClusterDX plays with different rules.

What is really a DX Cluster

The original concept of DX Cluster is quite simple.

An operator connected to a node publishes that they have heard or worked a certain station. That message normally contains the call sign, frequency, time and some comment.

That is the spot.

But the real trick does not consist in showing it on a screen.

The node where it is published is connected with other nodes. These exchange information and form a network. A user connected to another server may end up receiving that same spot without the need to be in the node where it originated.

DXSpider, one of the most used cluster programs and heir to the PacketCluster concept, explains it directly: nodes tend to link with each other to increase the number of users and available spots. Its documentation contemplates connections between nodes, routes and mechanisms for information to circulate even by alternative paths within the network.

Simplifying it a lot, the scheme would be this:

Operador → Nodo A ↔ Nodo B ↔ Nodo C ← Operador

Node A does not need to store the whole world community.

Node B neither.

The important thing is that they talk to each other.

That is what turns several independent servers into a cluster.

Telnet does not turn a server into a cluster

Here it is convenient to dismantle another usual confusion.

For decades many operators have accessed the clusters via Packet Radio or Telnet. DXSpider continues documenting access via Telnet and there exist countless radio programs capable of connecting directly to a server using that system.

But Telnet does not define the cluster.

It is only an entry door.

Tomorrow that door can be MQTT, WebSocket, a REST API or any protocol that makes sense.

In fact, the URE WebCluster has been incorporating ad handling via MQTT. Its public change log from June 2026 explicitly mentions MQTT ad management within the platform.

The technology changes.

The principle remains the same.

A system receives information, processes it and allows other systems to use it.

That is why facing ‘traditional cluster’ against ‘modern web’ would be a wrong debate.

Modernizing a cluster does not consist in replacing a terminal with a pretty map.

It consists in improving the way information can circulate.

ClusterDX uses another architecture

ClusterDX is currently defined as an online platform created for amateur radio enthusiasts of DX on 11 meters CB. It has built around the spots a community with user accounts and different tools related to the activity.

That has value.

The problem appears when we apply strictly the concept of DX Cluster.

ClusterDX is not presented as a node connected to other DX Cluster servers nor does it have connection mechanisms between pairs equivalent to those used by networks like DXSpider.

What we find is another model.

Usuarios → ClusterDX ← Usuarios

Operators generate spots within ClusterDX and other ClusterDX users query them within that same platform.

That is spotting.

But it is not the federated architecture that historically defines a DX Cluster network.

Said without technical jargon: ClusterDX conserves the visible part of the cluster, but not the server network that gives sense to the term.

And it could seem a purely academic difference until you try to build something around those data.

The problem starts when you want to make your own logbook

Let’s imagine something quite modest.

We do not want to copy ClusterDX.

We do not want to set up a competing service.

Nor even we want to store millions of spots.

We only want to program our own logbook.

The program remains open while we do radio. When an interesting spot appears we want it to receive it automatically.

With a cluster that provides an accessible interface, the idea is trivial.

The logbook listens to the spot flow.

A station appears.

The program identifies the call sign.

Query the available information.

Check if it already exists in our log.

It warns us if we are interested.

Nothing especially revolutionary. Clusters have been connecting for years precisely with logging programs, and the very documentation of DXSpider contemplates the connection of this type of software.

Now let’s add a bit of tinkering.

Because to look at a screen we already have eyes.

From the spot to the antenna rotor

Let’s suppose we receive the spot of a station located at thousands of kilometers.

Our program knows our locator.

It also obtains the locator of the reported station.

With those two data it can calculate distance and bearing. The very DXSpider includes since years ago commands to calculate distance and direction between Maidenhead locators.

From there we can continue automating.

The software could query our log and check if we have already worked that station. It could send via CAT the frequency to the transceiver. It could also send the calculated azimuth to the rotor controller and automatically orient the antenna.

The flow would be something similar to this:

Spot → indicativo → locator → rumbo → rotor → radio → operador

We are not talking about generative AI, spy satellites nor Skynet entering via the ACC connector.

We are talking about basic automation.

And it turns out quite ironic that an activity full of people capable of building antennas, controllers with Arduino, CAT interfaces, logging programs and remote stations can find that the most complicated part is obtaining in authorized way the spot they are seeing on a webpage.

You can see the data but your program cannot use it equally

Here appears the true limit of ClusterDX.

Their current public rules establish that spot grabbing nor the transfer of spots, emails or other user data or of ClusterDX is not allowed. They also restrict the use of scripts and certain uses of information outside the own platform.

That changes much the discussion.

We are not simply talking about that ClusterDX does not publish a comfortable API.

We are talking about that their own rules establish explicit limits on the extraction and reuse of information.

For the normal user possibly there is not any problem.

Enter.

Look at the spots.

Publish your own.

Use the available tools.

Close the tab.

Everything perfect.

The problem appears when the user wants that another machine does something with that information.

There the screen becomes a frontier.

You can read the spot.

But integrating that same flow in an authorized way into an external tool is already another story.

In 11 meters different models already exist

Nor even we have to leave the 11 meters to find another philosophy.

LF11, for example, maintains a service oriented to 27 MHz that combines log and cluster. Its own web offers access to the cluster via Telnet and mechanisms to integrate both the log and the cluster into external pages.

It does not mean that LF11 is better than ClusterDX.

Nor that its community has the same size.

Nor that all their technical decisions are the correct ones.

It means something quite more simple.

It is possible to build services for 11 meters allowing that other tools consume part of the information.

And that opens possibilities.

A developer can experiment.

An amateur radio operator can write their own client.

A logging program can receive spots.

An application can filter them in another way.

Another system can use them as a starting point for an automation.

There is good part of the original spirit of the cluster.

Not only see information.

Move it.

The clusters are being modernized precisely to do more things

It turns out especially striking because the rest of the ecosystem has not remained frozen in 1998.

Telnet continues functioning because it is simple, is widely supported and there exists a huge amount of compatible software.

But around are appearing web systems, MQTT, automatic sources like Reverse Beacon Network, PSKReporter, advanced filters and services capable of combining huge amounts of spots.

In July 2026, for example, a development presented in the URE forums explained how it gathers human spots from the global DX Cluster network together with RBN, PSKReporter and other sources, maintaining Telnet ports precisely so that logbooks and contest programs can consume the result.

That is to say, Telnet can be old.

But the idea that is behind it is not.

Receiving a flow of information to be able to process it automatically remains tremendously useful.

MQTT simply takes that philosophy to more current architectures of publication and subscription.

The future of the cluster probably does not consist in choosing one or other.

It consists in being able to connect it with things.

My experience with the old ClusterDX forum

This question is not new for me.

Years ago I remember having read conversations in the old ClusterDX forum where some users proposed the possibility of having some type of API or mechanism that allowed using information from the platform from external tools.

I also remember a conversation where, in front of this type of request, an administrator explained that there was not an available API and mentioned that some people were resorting to alternative extraction methods, among them the scraping.

The old forum no longer allows locating publicly that thread.

I tell it because it was precisely one of the experiences that made me think about this difference between using a platform and being able to integrate it.

Fortunately, we also do not need that thread to know the current situation.

The rules that ClusterDX publishes today leave clear their stance regarding the extraction of spots and external use of information.

The anecdote explains where the question comes from.

The current rules allow discussing it with documents on the table.

Being private is not the problem

ClusterDX is a private initiative and has all the right to establish conditions for using its infrastructure.

Maintaining servers costs money.

Developing a platform takes work.

Moderating it also.

And no one can reasonably demand that a database built during years be delivered complete to anyone who arrives with a script under the arm.

That is not the debate.

An API also does not mean free bar.

It can demand authentication.

It can limit requests.

It can offer only the latest spots.

It can restrict certain fields.

It can establish quotas.

It can prevent commercial uses.

It can even be a service reserved to certain types of account.

The same happens with MQTT or with any other interface.

Interoperability does not mean giving up control.

It means providing a documented way to talk with the system.

Nor even it is necessary to open all the database

This point is important because many discussions about data end quickly in two quite tired sides.

Everything open.

Or everything closed.

There is a lot of ground in between.

To build the logbook of the previous example I do not need to download sixteen years of ClusterDX.

I only need to receive certain events.

A spot has appeared.

This is the call sign.

This is the frequency.

This is the time.

End.

A read-only interface with reasonable limits would already allow developing a huge amount of tools without delivering the complete database of the platform.

Even it could be established a difference between historical information and flow in real time.

Technically there are many possibilities.

What is missing is not technology.

There is missing deciding which degree of interoperability one wants to allow.

The network effect can also become a cage

ClusterDX explicitly asks its members to be active and publish their DX contacts. Their own rules show up to what point the participation of users constitutes a fundamental piece of the service.

That is logical.

A spotting system without people spotting has approximately the same utility as a WhatsApp group where only the administrator is there.

The more users participate, the more useful results the platform.

And the more useful it results, more operators enter.

The known network effect.

But when all that activity remains within a single platform and there exist important restrictions for using it from external tools, the same network effect that brings value also starts to produce dependency.

You want the spots because there is the community there.

The community stays there because there are the spots there.

That circle is extremely difficult to break for any new service.

And even more difficult if external tools also cannot integrate with the dominant source of information.

ClusterDX did much well to reach up here

None of this eliminates the merit of ClusterDX.

On the contrary.

If we are discussing about interoperability it is precisely because the platform managed to gather during years an amateur radio community of 11 meters around its services.

Currently it continues presenting as a space dedicated to amateur radio enthusiasts of DX on 11 meters and claims to have been running for 16 years.

Keeping alive during so long time a specialized project already has quite merit.

The criticism does not consist in denying that work.

It consists in asking what happens when a platform that has reached that level of adoption decides to function as a closed ecosystem instead of as an interoperable piece of a greater network.

Because both things produce very different experiences.

A cluster is worth for the connections it allows

Perhaps the name ClusterDX has ended playing a bad pass.

For many users, cluster simply means a list of spots.

But historically the concept was quite more interesting.

It meant nodes.

Links.

Routes.

Users entering via different servers.

Information jumping from one to another.

A distributed infrastructure that did not necessarily depend on a single entry door.

ClusterDX took one of the most visible functions of that system —the spotting— and built around it an own platform for the 11 meters.

It functioned.

Probably because that is why it stays there.

But by doing so left out a fundamental characteristic of the traditional cluster: the interconnection with other servers to share information.

And that decision has consequences that go much beyond how a call sign appears on screen.

It means we cannot treat their spots as an interoperable flow in the same way that we do with other systems.

It means developing independent tools results more complicated.

It means something as simple as connecting our own logbook can become a problem.

And it means that perfectly normal automations —query a locator, calculate a bearing or point an antenna— hit first with a question much less exciting:

how to get the data.

Radio should continue allowing us to tinker

There is a reason why all this seems important to me.

Radio has always been full of people who do not agree with using things as they come from factory.

We build antennas.

We solder interfaces.

We program controllers.

We automate rotors.

We connect radios to computers.

We invent solutions for problems that possibly only we have.

And yes, sometimes we dedicate three afternoons to automate a task that took us six seconds to do by hand.

That also forms part of the fun.

The digitization of radio should not end precisely with that possibility.

A platform can protect its infrastructure and continue allowing users to build things around it.

It can establish limits.

It can control abuses.

It can decide what information it exposes.

But there must exist a door.

Because a cluster, in the end, does not result interesting only by the spots it receives.

It results interesting for all that those spots can put in motion.

And in 2026 that difference matters more than ever.