Heute Vormittag hat mich Israel gehört. 4Z4TJ, rund 2900 Kilometer weit weg — und zwar nicht vom Shack aus, sondern mobil: Ich stehe gerade in Oberurmein auf 1600 Metern über Meer, das Funkgerät läuft im Wohnmobil. 14 MHz, 200 Milliwatt. Das ist weniger, als meine Nachttischlampe zieht, und es ist keine Anekdote vom Hörensagen: Die Meldung steht in der Datenbank, samt der Angabe, mit welchem Signal-Rausch-Abstand die Gegenstation mein Signal aus dem Rauschen gegraben hat.
Genau diese Zahl ist der Grund, warum HAM-Tools seit Version 1.44 ein WSPR-Modul hat. Nicht wegen der Rekorde. Sondern weil man damit endlich etwas kann, wofür ich bisher immer nur Bauchgefühl hatte: eine Antenne messen statt schätzen.
Kurz für alle, die WSPR noch nie benutzt haben
WSPR — gesprochen «whisper» — ist keine Betriebsart zum Funken. Man führt keine Verbindungen. Eine Station sendet alle paar Minuten knapp zwei Minuten lang drei Angaben: Rufzeichen, Locator, Leistung. Mit so wenig Watt, dass das Signal im Rauschen verschwindet. Empfänger in aller Welt graben es wieder heraus und melden es an eine gemeinsame Datenbank — mit Frequenz, Uhrzeit und eben jenem Signal-Rausch-Abstand.
Seit 1.44 macht HAM-Tools das komplett selbst: senden, empfangen, auswerten. Ohne WSJT-X daneben, ohne zweite Audio-Umleitung, ohne zweite CAT-Verbindung. Frequenz und Datenmodus stellt die App über CAT ein, eine Bandwechsel-Automatik dreht auf Wunsch reihum durch die gewählten Bänder — für Empfang und Aussendung. Ein Durchgang über vier Bänder dauert acht Minuten.
Der Bogen, der sich damit schliesst
Seit 1.41 steckt ein NEC2-Rechenkern in der App — er hat mir gerade erst meine eigene Delta-Loop-Faustformel um die Ohren gehauen. Aber der Rechenkern sagt nur, was eine Antenne im Modell tun sollte. Was sie an ihrem Standort tatsächlich tut — mit diesem Boden, diesen Nachbarhäusern, dieser Aufbauhöhe — steht auf einem anderen Blatt.
WSPR liefert dieses andere Blatt. Damit ist die Reihe komplett, die sich über die letzten Versionen aufgebaut hat: rechnen (1.41), prüfen (1.43), messen (1.44). Alles mit demselben Funkgerät, alles in einer App.
Warum «zwölf Stationen gegen acht» nichts beweist
Und jetzt zum Teil, der mir beim Bauen am wichtigsten war. Wer zwei Antennen vergleichen will, zählt zuerst: Antenne A wurde von zwölf Stationen gehört, Antenne B von acht — also ist A besser. Klingt logisch. Misst aber die Ionosphäre, nicht die Antenne. Die Ausbreitungsbedingungen ändern sich über wenige Stunden stärker als jede bauliche Änderung. Wer vormittags misst und nachmittags vergleicht, bekommt eine Zahl, die mit dem Mast nichts zu tun hat.
Der Vergleich im Modul funktioniert deshalb anders: Er zählt nur die Stationen, die beide Messzeiträume gehört haben. Für jede dieser gemeinsamen Stationen wird die Differenz im Signal-Rausch-Abstand gebildet, das Ergebnis ist deren Median. Daneben steht gleichwertig die Anzahl der gemeinsamen Stationen — ab fünf gilt das Resultat als belastbar, darunter entscheidet ein einzelner Empfänger mit wackligem Signal über die ganze Zahl.
Stationen, die nur in einem der beiden Zeiträume auftauchen, werden getrennt ausgewiesen statt verschwiegen. Interessant, aber kein Beleg: Wer im zweiten Durchgang fehlt, kann auch einfach seinen Empfänger abgeschaltet haben.
Was am echten Funkgerät herauskam
Beim Modul sind 227 automatische Tests im Release-Lauf grün. Und trotzdem: Die vier interessantesten Fehler fand keiner davon. Die kamen alle erst am echten Rig heraus.
Da waren die Falschdekodierungen — bei sehr schwachen Signalen geht gelegentlich eine Prüfsumme zufällig auf, und heraus fällt ein Rufzeichen, das es nicht geben kann (kein zugeteiltes Präfix beginnt mit 0 oder 1). Die werden jetzt markiert statt ausgeblendet, denn beim Antennenvergleich will man sehen, wie oft das passiert. Auf dem Screenshot oben ist so ein Fall mit Warnsymbol zu sehen.
Da waren die namenlosen Stationen: Manche senden statt des Rufzeichens dessen Prüfsumme, um Platz für einen genaueren Standort zu schaffen. Die Zuordnungstabelle, die das auflöst, wurde nach jedem Durchlauf gelöscht — diese Stationen wären für immer namenlos geblieben. Eine davon kam mit 0 dB über 300 km herein.
Da war USB-D: Bei Icom ist der Datenmodus kein eigener Modus, sondern USB plus ein Flag über einen zweiten CAT-Befehl. Der fehlte. Das Gerät blieb im Sprachbetrieb und hätte das Audio vom Mikrofon genommen statt vom USB-Codec — was nebenbei auch Winlink betraf.
Und da war der ernsteste: die Sendetastung beim Beenden. Wer die App während einer laufenden Aussendung schloss, liess den Sender als Dauerträger stehen — die PTT wurde nicht gelöst. Bei einer Bake, die tagelang unbeaufsichtigt läuft, ist das der schlimmste denkbare Fall. Betraf auch SSTV und Winlink, ist in 1.44 für alle drei behoben.
Die Lehre daraus schreibe ich mir selbst hinter die Ohren: Tests beweisen, dass der Code tut, was ich mir vorgestellt habe. Das Funkgerät prüft, ob ich mir das Richtige vorgestellt habe.
Bakenbetrieb heisst Verantwortung
Eine WSPR-Bake läuft tagelang ohne Aufsicht — entsprechend defensiv ist das Modul eingestellt. Die Vorgabe ist reiner Empfang; wer senden will, muss das doppelt einschalten. Ein Watchdog überwacht die Sendetastung, und beim Beenden wird die PTT synchron gelöst, bevor die App zugeht.
Dazu die Rücksicht auf alle anderen: Das WSPR-Band ist nur 200 Hz schmal. Empfohlen sind 20 Prozent Sendeanteil — wer ständig sendet, hört selbst nichts und belegt das Fenster für alle. Welche Zeitfenster eine Station erwischt, wird aus Fensternummer und Rufzeichen berechnet, sonst würden alle mit derselben Einstellung gleichzeitig senden und sich gegenseitig zudecken.
Ehre, wem Ehre gebührt
Der Sendeweg ist komplett selbst geschrieben — Kodierung, Faltungscode, 162 Symbole, 4-FSK mit durchgehender Phase, in Swift. Beim Dekodieren war ich ehrlich zu mir selbst: Bei −28 dB Signal-Rausch-Abstand zu dekodieren ist hohe Schule, und ein selbstgeschriebener Decoder, der nur die starken Signale findet, sieht aus, als würde er funktionieren — WSPR lebt aber von den schwachen. Darum liegt der bewährte wsprd-Decoder aus dem WSJT-X-Projekt bei und läuft als eigener Prozess, gleiches Muster wie beim NEC2-Kern. Er steht unter GPLv3, und der Dank dafür geht an Joe Taylor K1JT und Steven Franke K9AN. Geprüft wird die Kette über eine geschlossene Gegenprobe: eigener Encoder, kontrolliertes Rauschen, Referenz-Decoder — dekodiert bis −28 dB, und bei −35 dB kommt bewusst nichts mehr, damit ein Test, der versehentlich immer dekodiert, auffliegt.
Die Zahlen
| Sendedauer je Durchgang | 110,6 s, Start 1 s nach jeder geraden UTC-Minute |
| Bandbreite | 6 Hz |
| Nutzlast | 50 Bit — Rufzeichen, Locator, Leistung |
| Empfindlichkeit | rund −28 dB Signal-Rausch-Abstand in 2500 Hz |
| Zeitgenauigkeit | ±1 s nötig, sonst fallen die schwachen Signale aus |
| Erreicht im Test | 2900 km mit 200 mW ≙ rund 14’500 km/W |
Wichtig für die Praxis: Ohne genaue Systemuhr geht nichts — die Zwei-Minuten-Fenster sind hart synchronisiert, mehr als eine Sekunde daneben und die schwachen Signale fallen aus dem Dekodierfenster.
Was noch fehlt — und was daraus wird
Die Vergleichsfunktion ist gebaut, getestet und erklärt. Was ihr noch fehlt, ist ihr erster echter Auftritt: zwei Messzeiträume, zwei Antennen, eine dB-Zahl. Genau das kommt als Nächstes — eine konkrete Umbaumassnahme, vorher und nachher je ein paar Stunden Bake, und dann steht hier, was der Umbau wirklich gebracht hat. Nach der Delta-Loop-Geschichte traue ich meinem Bauchgefühl jedenfalls nicht mehr weiter, als ich einen Ringkern werfen kann.
Das Modul steckt in HAM-Tools 1.44, die Hilfeseite gibt es auf Deutsch und Englisch, das Changelog wie immer dazu.
Erzähl mir, wen deine 200 Milliwatt erreichen.
73 de Chris, HB9HJI