Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03635.jsonl.gz/523

von © Matthias, HB9TPN
Update 20.10.2020
Um einen DX-Cluster zu erklären, muss man etwas in der Geschichte ausholen. In der Zeit vor dem Internet (ja, das gibt es tatsächlich) konnte man sich ins Amateurfunk Packet Radio Netzwerk via einem nahen gelegenen Packet Radio Knoten über VHF/UHF (zum Teil auch via HF) einklinken. Die Packet Radio Server dahinter, welche verschiedene Daten, wie persönliche Meldungen, Newsletter, DX Informationen etc. speicherten, waren über ein weltweites Packer Radio Netzwerk miteinander verbunden und auch synchronisiert. In Europa konnte man sich z.B. in Hamburg über das PR- Netzwerk bis nach Basel «durchlinken» lassen, was jedoch immer länger dauerte, da anfänglich das PR-Netzwerk via VHF/UHF nur mit 1200 Baud funktionierte (später dann auch mit 9600 Baud). Als Hardware verwendete man einen PC, oder ein kleines Serial-Terminal, einen TNC (Terminal Node Controller), was faktisch ein MODEM darstellte und die digitalen Signale vom PC in Audiotöne wandelte und diese ins Funkgerät via Mikrofon- und Audiobuchse einkoppelte. Das ganze beruhte auf dem einfachen AX.25 Protokoll, welches heute noch für APRS verwendet wird.
Die neusten DX-Meldungen auf den DX-Clustern wurden in fast-Echtzeit über dieses Packet Radio Netzwerk verteilt. Um an diese Informationen zu kommen, musste man sich zuerst in dieses Netzwerk einklinken. Selbstverständlich konnte man auch seine DX-Meldungen auf dem Netzwerk absetzen. Aber eben, man musste auf einen Packet Radio Knoten Zugriff haben und zeitgleich musste man ein 2m oder 70cm Funkgerät mit TNC mitlaufen lassen.
Heute funktioniert das DX-Cluster Netzwerk auf ähnliche Art und Weise. Zwar werden die Daten meistens nicht mehr via «Äther» verteilt, sondern über das WWW. Es gibt verschiedene DX-Server, welche die Informationen aus der ganzen Welt sammeln und ins DX-Cluster Netz weiterverbreiten. Zum einen können die DX-Informationen bequem über eine Homepage dargestellt werden, oder dieselben Informationen können über ein TELNET Portal abgerufen werden.
TELNET, was ist jetzt das schon wieder?
TELNET ist im Internet ein weit verbreitetes Netzwerkprotokoll, was auf dem Client / Server Prinzip beruht. Das TELNET Protokoll ist einfach aufgebaut und ermöglich die Kommunikation zwischen zwei PCs, auch wenn diese verschiedene Betriebssysteme (z.B. MacOS und WINDOWS) haben. Die neuen MacOS und WINDOWS Versionen haben den TELNET Dienst standardmässig blockiert und müssen bei Verwendung zuerst frei geschaltet werden. Auch heute noch gibt es viele DX-Server, auf welche mit der TELNET Command Shell zugegriffen werden kann. Die Steuerung bzw. das Abfragen von Informationen erfolgen mit der Eingabe von Steuerkommandos, was an die alte Zeit von DOS erinnert.
Bild 1: DX-Cluster GB7MBC mit TELNET
Obwohl die TELNET Technologie eher altmodisch anmutet, werden heute immer noch die DX-Cluster Informationen in Logging Softwares (z.B. N1MM) via TELNET abgerufen. Die TELNET Rohdaten werden in der Logging Software eingebunden und z.B. auf einer Logging Software Bandmap dargestellt, mit welcher durch einen einfachen Mausklick der Transceiver auf die Frequenzen der DX-Station gestellt werden kann.
Bild 2: TELNET Fenster der Logging Software N1MM, eingeloggt ist der DX-Cluster GB7MBC
Nutzen und Verwendung von DX-Cluster
Die Verwendung von DX-Cluster ist Fluch und Segen zugleich. Die Suche nach einer DX-Station kann durch einen Eintrag im DX Cluster vereinfacht werden. Wenn jedoch bereits zwei oder mehr Einträge derselben DX-Station schon im DX-Cluster Netz kursieren, dann steht man meistens hinten an. Zudem ist das sogenannte Self-Spotting verpönt. D.h. eine Station stellt ihr eigenes Rufzeichen auf dem DX-Cluster, um auf sich aufmerksam zu machen. Das Self-Spotting ist während den Contests ebenfalls meist verboten. Leider halten sich nicht immer alle Stationen an diese Regel. Das führt regelmässig zu Abmahnungen, wenn nicht sogar zu Disqualifikationen von Contest-Stationen. Diese «Methode» ist auch in der Schweiz, v.a. anlässlich von Helvetia Contests, verbreitet.
Die Ausnahme bildet das Self-Spotting auf dem SOTA Cluster. SOTA Stationen starten meistens ihre Aktivität durch das Self-Spotting.
Bei der Teilnahme an Contests sind die Contestregeln ebenfalls genau durchzulesen. Sollte eine Kategorie «non-assisted» ausweisen, dann ist der Gebrauch von DX-Clustern, aktiv und passiv, nicht erlaubt. Auch hier gibt es jedes Jahr «schwarze Schafe», welche sich nicht an die Regeln halten mögen. Vor allem die Auswerter von grossen Contests (z.B. WPX, CQ WW, etc.) legen grossen Wert auf den korrekten Gebrauch von DX-Cluster während des Contests und verwenden ausgeklügelte Systeme, um Regelverletzungen nachweisen zu können.
Die Verwendung von DX-Cluster ist heute Standard und wird auch rege genutzt. Jedoch sollte beim Gebrauch und Absetzen von DX-Cluster Meldungen auch über die Notwendigkeit der Meldung nachgedacht werden. Zudem macht es meistens auch keinen Sinn, sich auf einem DX-Cluster in Chile einzuloggen, da man viele der dort gemeldeten Stationen in EU nicht hören wird.
Filtern von Cluster Meldungen
Filter 1 reject not by_zone 14,15,16
Es werden nur Spots von Spottern aus den aufgelisteten CQ-Zonen angezeigt. In diesem Fall aus Europa.
Spots von Japan, USA etc. sind zwar auch interessant. Aber für uns in HB und als QRP Station nicht unbedingt erreichbar.
Filter 2 reject not on hf/cw
Nur Spots von CW Stationen auf den Kurzwellenbändern werden angezeigt. Nicht-CW-OPs ersetzen cw mit ssb.
Filter 3 reject on hf/rtty
Keine RTTY Stationen auf den Kurzwellenbändern.
Filter 4 reject on hf/ssb
Keine SSB Stationen auf den Kurzwellenbändern.
Filter 5 reject info ft8
Keine FT8 Stationen.
Die Erfahrung zeigt, dass das gewünschte Resultat am ehesten erreicht wird, wenn man mit dem Befehl „reject“ filtert und dabei beim Groben beginnt. Zu beachten ist aber, dass nicht alle Clustersysteme mit diesen Befehlen kompatibel sind. Diese Angaben beziehen sich auf DXSpider.
Liste von DX-Cluster auf dem WWW: