FT8-Horch: zwei Handys, ein Tisch und null Watt

Aus einem kleinen Demo-Skript wurde eine App, die komplette FT8-QSOs über Lautsprecher und Mikrofon funkt, also FT8 ohne Funkgerät, ohne Antenne und mit einem Nachbarn, der sich fragt, was da so zwitschert. Für den Funkbetrieb ist sie ziemlich nutzlos. Für mein Verständnis von FT8 war sie Gold wert.

Auf meinem Schreibtisch liegt ein Handy, daneben steht ein PC mit Lautsprecher und Mikrofon, und die beiden zwitschern sich an wie zwei Wellensittiche, die über den Sinn des Lebens streiten. Das Handy ruft CQ. Der PC horcht, antwortet, bekommt einen Rapport, bestätigt, und nach anderthalb Minuten steht im QSO-Fenster das schönste Wort des Amateurfunks: 73.

Kein Funkgerät, keine Antenne, kein einziges Watt Sendeleistung. Nur Luft, ein Mikrofon und eine ordentliche Portion Mathematik.

Wer zufällig vorbeikommt, fragt, ob ich mir einen neuen Vogel zugelegt habe. Ich sage dann: Das ist ein QSO. Ich vermute, das hilft nicht weiter.

Warum ich eine App baue, die auf dem Band niemand vermissen wird, und was ich dabei gelernt habe, steht in den folgenden Kapiteln. Wir fangen mit der Vorgeschichte an, die eher eine Eskalationsgeschichte ist, und schauen uns dann die Bedienung an. Danach geht es um die Tücken der Luftstrecke, um eine kleine Dezibel-Rechnung zum Spreizen und Dehnen und um ein Spielzeug zum Fehlerschutz. Am Ende steht eine ehrliche Liste dessen, was nicht klappt, und wie du die App selbst ausprobierst.

1. Wie aus einer Demo eine App wurde

Ich beschäftige mich schon länger mit FT8. Irgendwann reicht es einem nicht mehr, dass etwas funktioniert, man will wissen, wie. Also habe ich mich durch die Spezifikationen gearbeitet, was ungefähr so aufregend ist, wie es klingt, und mir das Ergebnis in einem Blogartikel von der Seele geschrieben: FT8 – Mathematik statt Watt. Falls du ihn nicht kennst: Er ist lang und ziemlich tief. Man liest ihn mit Kaffee, und danach weiß man, warum ein Türsteher namens CRC-14 und ein Panzer namens LDPC aus zwölf Sekunden Rauschen eine einzige grüne Zeile machen.

Für alle, die den Artikel überspringen (ich nehme es dir nicht übel), die Kurzfassung. FT8 arbeitet im 15-Sekunden-Takt nach Weltzeit. Eine Nachricht wie CQ DL6LG JO60 wird in 77 Bits gepackt, bekommt eine Prüfsumme und einen kräftigen Fehlerschutz und geht als Folge von 79 Tönen auf die Reise, die zusammen nur 50 Hz breit sind. Der Empfänger rechnet sich die Bits aus dem Rauschen zurück, im Idealfall noch bei rund −21 dB. Mathematik ersetzt Sendeleistung, so lautete die Überschrift.

Nur: Etwas auf dem Papier zu verstehen und es wirklich zu begreifen, sind zwei verschiedene Dinge. Deshalb hatte ich eine bescheidene Idee. Ein kleines Programm sollte zeigen, wie aus CQ DL6LG JO60 ein Bitmuster wird. Es sollte die 14 Bit Prüfsumme (CRC) ausrechnen, die 83 Paritätsbits für den Fehlerschutz erzeugen und die drei Costas-Arrays einfügen, an denen der Empfänger das Signal überhaupt erst findet. Danach wollte ich simulieren, wie viele Bits kippen dürfen, bevor die Nachricht nicht mehr zu retten ist. Eine reine Demo, nur für meinen Kopf. Diese Funktion steckt übrigens heute noch in der App, dazu mehr in Kapitel 5.

Und dann ist die Sache eskaliert, wie so oft bei mir.

Ich hatte die Bitfolge. Warum also nicht gleich die Töne daraus machen und über den Lautsprecher abspielen? Gesagt, getan. Leider liegen die acht Töne von FT8 nur 6,25 Hz auseinander, und für ein Hörschwein wie mich klingt das wie ein einziger, leicht nervöser Pfeifton. Also habe ich eine Spreizung eingebaut: Der Tonabstand lässt sich auf 12,5, 25, 50 und 100 Hz erhöhen. Ab da konnte ich die Töne tatsächlich auseinanderhalten.

Das nächste Problem war die Geschwindigkeit. Jeder Ton dauert bei FT8 genau 160 Millisekunden, und das ist für mein altes Gehirn deutlich zu schnell. Also kam noch eine Dehnung dazu: Statt 15 Sekunden pro Durchgang gehen jetzt auch 30, 60 oder 120 Sekunden. Bei 120 Sekunden dauert jeder Ton rund 1,3 Sekunden, und man könnte fast mitschreiben und das FT8-Signal im Kopf decodieren. Ich habe es nicht versucht. Aber man könnte.

Du ahnst, wie es weitergeht. Wenn die Signale schon hörbar sind, muss man sie doch auch mit dem Mikrofon wieder auffangen können. Also kam der Empfang dazu, und mit ihm zwei Probleme, die mich deutlich länger beschäftigt haben als alles davor: die Uhr und die Rechenzeit. Beides steht in Kapitel 3.

Als auch das lief, lag der letzte Schritt auf der Hand. Wenn zwei Geräte sich hören und verstehen, muss doch auch ein richtiges FT8-QSO gehen, mit CQ, Rapport, Bestätigung und 73. Also kam die QSO-Logik dazu, der Vollständigkeit halber ein Logbuch, hier und da Feinschliff an Optik und Bedienung, und fertig war eine App, die eigentlich nur ein kleines Lernprogramm werden sollte.

Sie heißt FT8-Horch und hat als Logo ein Ohr, in das jemand reingebissen hat. Das ist kein Grafikfehler, das ist der Ohrenbeisser.

Beim Decoder hatte ich Hilfe von einer KI (Claude Code). Ich bin Universaldilettant und kein JavaScript-Profi, und einen Decoder, der in knapp zwei Sekunden ein Signal aus dem Rauschen fischt, hätte ich allein nicht hinbekommen. So einer will außerdem getestet werden, bis man nachts von Bitfolgen träumt. Was in die App reinkommt und was wieder rausfliegt, entscheide ich trotzdem selbst. Ein paar Ideen sind schon wieder rausgeflogen, die meisten vor dem Bauen, eine sogar danach. Dazu später mehr.

2. Vorhang auf: was die App kann

FT8-Horch ist eine Web-App. Sie läuft im Browser, lässt sich auf den Startbildschirm legen und braucht danach nicht einmal mehr Netz. Schauen wir uns an, wie sie aussieht, wenn gerade ein QSO läuft.

Oben links sitzt der Mikrofon-Schalter. Wenn du ihn umlegst und die Frage nach dem Mikrofon mit „Ja“ beantwortest, hast du schon fast alles getan. Darunter läuft der Wasserfall, auf dem jedes FT8-Signal als wacklige Spur durchs Bild zieht. Die rote Linie ist die Frequenz, auf der du sendest. Ein Doppeltipp verschiebt sie in eine Lücke zwischen zwei anderen Signalen. Ein einfacher Tipp tut nichts, damit du sie beim Scrollen nicht aus Versehen verstellst.

Unten stehen zwei Listen. In der Band-Aktivität landet alles, was die App decodiert hat, mit Uhrzeit, Rauschabstand, Zeitversatz und Frequenz. Den Zeitversatz kennst du aus WSJT-X als DT (Delta Time): Er zeigt in Sekunden, wie viel früher oder später ein Signal ankommt als erwartet. Zeilen mit grünem Rand sind CQ-Rufe, ein Tipp darauf antwortet. Rot ist, was an dich gerichtet ist, gelb ist, was du selbst sendest. Im QSO-Fenster daneben steht nur, was dich betrifft.

Und dann gibt es den Schalter Auto-Antwort. Ist er an und läuft gerade kein QSO, antwortet die App von selbst auf das erste CQ, das sie hört, und fährt die ganze Sequenz bis 73 durch. Das ist bequem und ein bisschen unheimlich: Die App erledigt allein, wofür man in WSJT-X sonst auf Knöpfe klickt.

Drumherum gibt es ein Log mit ADIF-Export und -Import, ein Textprotokoll wie in WSJT-X und eine Sicherung, die alles in eine Datei packt. Spreizung und Dehnung stellst du in den Profil-Einstellungen ein, und zwar unabhängig voneinander. Für Messungen und Tests gibt es den Reiter Labor, der uns gleich noch begegnet. Die Anleitung ist eingebaut, auf Deutsch und auf Englisch.

3. Die Luft ist kein Kabel

Jetzt kommt der Teil, der mich die meisten grauen Haare gekostet hat. Das Erzeugen der Töne war einfach. Im Simulator ist die Welt ohnehin schön: Das Signal kommt sauber an, die Uhren gehen gleich, und der Lautsprecher spielt, was man ihm sagt. Dann legst du zwei echte Geräte auf den Tisch, und die Wirklichkeit meldet sich zu Wort. Wir gehen der Reihe nach durch die Uhr, den Pegel und die Rechenzeit.

Die Uhr. Für mich war das die größte Nuss. FT8 ist eine Stechuhr: Alle senden zur selben Sekunde los und hören zur selben Sekunde zu. Ich war fest davon ausgegangen, dass Handys die Uhrzeit sowieso aufs Zehntel genau kennen. Meine jedenfalls nicht. Mein Test-PC ging sogar einmal 18 Sekunden falsch, und FT8 verzeiht vieles, aber keine 18 Sekunden. Die Systemuhr zu stellen, lässt kein Gerät einer Web-App durchgehen. Und vor jedem Einsatz erst die Uhr am Handy oder PC zu aktualisieren, ist auf Dauer einfach nervig.

Also ein Kunstgriff. FT8 verzeiht ein paar Zehntelsekunden ohne Murren. Die App fragt deshalb den Webserver, von dem sie geladen wurde, mehrmals nach der Uhrzeit, rechnet die Abweichung auf etwa eine Zehntelsekunde genau aus und arbeitet mit einem eigenen Ausgleich. Die Systemuhr bleibt unangetastet, und beide Geräte ticken trotzdem im selben Takt. Hat geklappt.

Der Pegel. Im ruhigen Raum hatte ich einen Rauschabstand von 41 bis 56 dB, FT8 kommt mit rund −21 dB aus. Da ist also reichlich Luft nach oben, solange niemand dazwischenhustet. Weniger schön ist der Lautsprecher: Bei 500 Hz fehlten mir 26 dB gegenüber 1500 Hz, Handylautsprecher mögen nun mal keine Bässe. Deshalb sendet die App standardmäßig bei 1500 Hz. Dazu kommt, dass Pixel und altes Tablet im Aufnahmepegel rund 12 dB auseinanderlagen. Es lohnt sich also, vor dem ersten QSO den Pegeltest im Labor laufen zu lassen.

Die Rechenzeit. Zwischen dem Ende eines Durchgangs und der Entscheidung, was im nächsten gesendet wird, bleiben nicht einmal zwei Sekunden. In dieser Zeit muss die App das Signal im Rauschen finden und decodieren. JavaScript ist nicht gerade als Rechenkünstler bekannt.

Ja, ich weiß: Es gibt fertige FT8-Decoder für den Browser. Die meisten nutzen WebAssembly, kurz WASM. Das ist ein kompaktes Binärformat, das moderne Browser fast so schnell ausführen wie ein normales Programm auf dem Rechner. Man schreibt den Code in C, C++ oder Rust, übersetzt ihn nach WASM und hat im Browser plötzlich ein Vielfaches an Rechentempo. Nur hatte ich mir mit Spreizung und Dehnung selbst ins Knie geschossen. Die fertigen Bibliotheken können echtes FT8, aber keine gespreizten oder gedehnten Varianten, jedenfalls habe ich nicht herausgefunden, wie man sie dazu überredet. Also blieb es bei JavaScript. Mit Claude Code habe ich den Decoder so lange optimiert, bis er in der knappen Zeit fertig wird. Auf den Handys ist es knapp, aber es reicht. Auf dem PC spielt die Rechenzeit keine Rolle.

Weil das Probieren von Hand mühsam ist, gibt es im Labor einen Verbindungstest. Zwei Geräte liegen nebeneinander, eins wählt „Gerät A“, das andere „Gerät B“, und beide starten zur selben Zeit. A sendet in den geraden Fenstern einen Kurztext, B in den ungeraden, und beide messen, wie gut sie den anderen hören. Am Ende schicken sie sich per Ton eine Zusammenfassung. Man kann das als Selbsthilfegruppe für Handys betrachten, in der jeder erzählt, wie gut er sich verstanden fühlt.

Das Ergebnis trennt zwei Dinge, die vorher in einem Topf lagen. Im mittleren DT beider Richtungen kürzen sich die Uhren heraus, übrig bleiben die Latenzen der Geräte. Der Uhrunterschied zeigt, um wie viel die eine Uhr der anderen vorgeht, wobei der Unterschied der Latenzen noch mit drinsteckt. Wer wissen will, warum sich zwei Handys bei DT nicht einig sind, hat jetzt eine Zahl statt einer Vermutung.

4. Spreizen und Dehnen: was das in Dezibel bringt

Spreizung und Dehnung habe ich ursprünglich nur für meine Ohren gebaut. Natürlich wollte ich trotzdem wissen, ob sie dem Signal auch etwas bringen. Wir rechnen das einmal durch, erst die Dehnung, dann die Spreizung, und schauen am Ende, wo die physikalische Grenze liegt.

Bei FT8 wird der Rauschabstand traditionell auf 2500 Hz bezogen, also auf die Breite eines SSB-Kanals. Für den Decoder zählt aber etwas anderes: wie viel Energie in jedem Bit steckt, verglichen mit dem Rauschen pro Hertz. Fachleute nennen das Eb/N0. Beides hängt über die Bitrate zusammen:

SNR (2500 Hz) = Eb/N0 + 10 · log₁₀(Bitrate / 2500 Hz)

Standard-FT8 schickt 77 Nutzbits in 12,64 Sekunden, das sind gut 6 Bit pro Sekunde. Der zweite Teil der Formel ergibt damit rund −26 dB. Wichtig ist der Gedanke dahinter: Je langsamer die Bits kommen, desto leiser darf das Signal sein.

Die Dehnung. Wenn ich die Zeit verdopple, halbiert sich die Bitrate, und jedes Bit bekommt doppelt so viel Energie. Das sind 3 dB pro Verdopplung.

Fensterlänge	Tondauer	Bitrate	Gewinn gegenüber Standard	Theoretische Grenze (Shannon)
15 s (Standard-FT8)	0,16 s	6,1 bit/s	0 dB	−27,7 dB
30 s	0,32 s	3,0 bit/s	+3,0 dB	−30,7 dB
60 s	0,64 s	1,5 bit/s	+6,0 dB	−33,7 dB
120 s	1,28 s	0,76 bit/s	+9,0 dB	−36,8 dB

Rauschabstand bezogen auf 2500 Hz. Die Grenze gilt für einen perfekten Code mit unendlich langen Blöcken.

Die Simulation in der App sieht das ähnlich, wenn auch nicht ganz so großzügig:

Profil	Fensterlänge	Decodierschwelle in der Simulation
Standard-FT8	15 s	−19,5 dB
achtfach gedehnt	120 s	−27,5 dB

Simulation mit bekannter Zeit und Frequenz, Rauschen bezogen auf 2500 Hz.

Theoretisch bringt die achtfache Zeit gut 9 dB, die Simulation landet bei 8 dB, also knapp darunter. Dafür dauert ein QSO in 120-Sekunden-Fenstern so lange, dass du zwischen zwei Nachrichten bequem Kaffee kochen kannst. Zweimal. Wer das für eine Schnapsidee hält: Joe Taylor hat mit WSPR einen Betriebsmodus gebaut, der nach genau diesem Prinzip knapp zwei Minuten pro Durchgang sendet und dadurch noch Signale um −28 dB aufnimmt.

Die Spreizung. Hier ist die Antwort kurz: Sie bringt null Dezibel. Ein Ton wird nicht kräftiger, nur weil sein Nachbar weiter weg wohnt. Die Energie pro Ton bleibt gleich, und der Decoder lauscht für jeden Ton in einem Frequenzfach, dessen Breite nur von der Tondauer abhängt, nicht vom Abstand. Was sich ändert, ist die belegte Bandbreite:

Tonabstand	Belegte Bandbreite
6,25 Hz (Standard-FT8)	50 Hz
12,5 Hz	100 Hz
25 Hz	200 Hz
50 Hz	400 Hz
100 Hz	800 Hz

Die Spreizung ist also eine Hörhilfe, kein Verstärker. Ein kleiner Bonus bleibt: Weit auseinanderliegende Töne verwechselt der Decoder auch dann nicht, wenn die Frequenz ein wenig wandert oder ein Lautsprecher leicht scheppert. Auf einem echten Band wäre das 16-mal breitere Signal dagegen ziemlich unhöflich gegenüber den Nachbarn.

Wo die Grenze liegt. Die absolute Grenze hat Claude Shannon schon 1948 ausgerechnet. Kein Verfahren der Welt decodiert zuverlässig, wenn Eb/N0 unter −1,6 dB fällt. Für Standard-FT8 heißt das: unterhalb von −27,7 dB ist Schluss, egal wie schlau der Decoder ist. WSJT-X schafft rund −21 dB und liegt damit nur gut 6 dB von dieser Grenze entfernt. Mit einem Code, der in jede Sendung gerade einmal 174 Bits packt, ist das bemerkenswert dicht dran.

Auf dem Papier geht das Spiel mit der Dehnung endlos weiter, jede Verdopplung schenkt dir 3 dB. In der Praxis zieht die Physik vorher die Notbremse. Je länger ein Ton dauert, desto schmaler wird das Frequenzfach, in dem der Decoder lauscht: 6,25 Hz bei Standard-FT8, aber nur noch 0,78 Hz bei 120 Sekunden. Dann muss die Frequenz über fast zwei Minuten auf Bruchteile eines Hertz stabil bleiben, und die Uhr muss entsprechend genau gehen. Zwischen zwei Handys auf dem Tisch klappt das. Über Kurzwelle verschmiert die Ionosphäre ein Signal schnell um ein paar Zehntel Hertz, und dann hilft auch keine Spreizung mehr, denn sie macht die Töne nicht breiter, sondern rückt sie nur weiter auseinander. Dazu kommt, was im Zimmer passiert: Je länger der Durchgang, desto wahrscheinlicher springt mittendrin der Kühlschrank an.

Ein Hinweis ist mir wichtig: Nur das Standardprofil (15 Sekunden, 6,25 Hz) ist echtes FT8, das auch WSJT-X versteht. Das habe ich mit einer WAV-Datei aus der App geprüft, WSJT-X hat sie decodiert. Alles andere nennt die App ausdrücklich FT8-Variante, und die funktioniert nur zwischen zwei Exemplaren von FT8-Horch mit demselben Profil. FT8-Horch sendet ohnehin nur über den Lautsprecher. Falls du irgendwann auf die Idee kommst, die Töne über ein Funkgerät zu schicken: Es gelten die üblichen Regeln des Amateurfunks, und eine Variante hat auf den FT8-Frequenzen nichts verloren.

5. Der Fehlerschutz zum Anfassen

Die ursprüngliche Demo ist nie ganz verschwunden. Sie lebt im Reiter Codierung weiter, der Schritt für Schritt zeigt, wie aus einer Nachricht Bits, Prüfsumme, Codewort und Töne werden und wie der Empfänger den Weg zurückgeht. Mein Lieblingsspielzeug darin ist die Karte „Fehlerschutz ausprobieren“.

Die Karte zeigt alle 174 Bits des Codeworts. Du tippst einzelne an, um sie zu kippen, und siehst, wie viele Prüfgleichungen gerade verletzt sind und ob der Decoder die Fehler wieder wegbekommt. Hier kannst du dem Panzer aus dem ersten Artikel bei der Arbeit zusehen. Mit harten Bits, also ohne die Angabe, wie sicher sich der Empfänger bei jedem Bit ist, korrigiert er bis zu vier gekippte Bits immer, bei zehn in etwa 95 von 100 Fällen, bei fünfzehn nur noch in jedem neunten und ab zwanzig gar nicht mehr. Der Panzer ist also nicht unverwundbar. Ab einer gewissen Zahl Löcher fährt er nicht mehr.

Ein Schalter über dem Raster stellt auf „Weiche Werte“ um. Dann bekommt der Decoder zu jedem Bit eine Sicherheit mitgeliefert, so wie der echte, und schafft deutlich mehr. Anschaulicher kann ich kaum zeigen, warum FT8 so tief im Rauschen noch funktioniert.

6. Was nicht geht

Zeit für die Kehrseite, ohne Weichzeichner.

Was	Stand
Rufzeichen mit /P und Hash-Rufzeichen (Typ 4)	Nicht unterstützt und auch nicht geplant. Die App zeigt solche Nachrichten als „nicht unterstützt“ an.
Volles Band	In einem Vergleich mit 60 Bandaufnahmen findet die App 67,7 Prozent der Nachrichten, die WSJT-X gefunden hat. WSJT-X zieht bereits decodierte Signale ab und findet dadurch mehr. Das fehlt hier.
Funkgerät	Noch nicht ausprobiert. Die Signalform stimmt, wie sich die App an einem echten Funkgerät schlägt, weiß ich noch nicht.
Geräte und Browser	Getestet auf einem Pixel 10a, einem alten Tablet mit Android 10 und einem PC, jeweils mit Chrome. Wie es auf dem iPhone aussieht, weiß ich schlicht nicht.
Rechenzeit bei gedehnter Zeit	Nicht gemessen. Auf den Handys ist sie schon bei 15 Sekunden knapp.

Manches habe ich geplant und wieder gestrichen, bevor es gebaut war: die Nachrichten mit Hash-Rufzeichen (Typ 4), die Tricks fürs volle Band (decodierte Signale abziehen und Ähnliches) und eine Steuerung für Funkgerät und Tonausgabe. Für zwei Handys auf dem Tisch bringt das nichts. Eine Sache habe ich sogar gebaut und wieder ausgebaut: eine Karte, auf der man von Hand wählt, welche Nachricht als Nächstes gesendet wird, samt Freitext. Ich habe sie schlicht nie gebraucht. Man muss nicht alles bauen, was man bauen kann. Diese Erkenntnis würde ich mir gern aufs Handgelenk tätowieren, wenn ich nicht wüsste, dass ich sie spätestens nächste Woche wieder vergessen habe. Der Rest dieses Artikels ist der Beweis.

Auf meinem Zettel für die nächsten Schritte stehen der Dauertest mit zwei echten Handys, danach Praxistests mit einem Funkgerät und die Veröffentlichung des Quelltextes auf GitHub. Fest zugesagt ist davon nichts, aber der Zettel hängt gut sichtbar.

7. Ausprobieren

Die App liegt unter ohrenbeisser.de/app/FT8-horch und läuft im Browser, am besten in Chrome und am besten auf zwei Geräten. So fängst du an:

1. Unter Einstellungen Rufzeichen und Locator eintragen, zum Beispiel DL6LG und JO60.
2. Am Gerät die automatische Uhrzeit eingeschaltet lassen. Kleinere Abweichungen gleicht die App über den Zeitabgleich mit dem Server aus.
3. Im Reiter QSO den Mikrofon-Schalter umlegen und die Mikrofon-Erlaubnis geben.
4. Das zweite Gerät danebenlegen. Ruft eines CQ, antwortet das andere von allein, denn die Auto-Antwort ist beim Start eingeschaltet. Wer lieber selbst bestimmt, tippt auf eine Zeile mit grünem Rand.

Wenn du die Töne einmal selbst auseinanderhalten willst, stell in den Profil-Einstellungen 100 Hz Tonabstand und 120 Sekunden ein, auf beiden Geräten gleich. Dann klingt FT8 plötzlich wie eine sehr langsame, sehr verwirrte Melodie.

Mehr steht in der Anleitung unter Hilfe direkt in der App. Alle Daten bleiben auf deinem Gerät, es gibt keine Konten und keine Auswertung. Die einzige Anfrage, die die App stellt, geht an den eigenen Server und fragt dort nach der Uhrzeit.

Im ersten Artikel steht der Satz, dass aus zwölf Sekunden Rauschen eine einzige grüne Zeile wird. Seit ich die App gebaut habe, weiß ich, wie sich das anhört: ziemlich genau wie zwei Wellensittiche, die sich auf dem Schreibtisch anbrüllen. Wenn du es ausprobierst und dein Nachbar fragt, was da zwitschert: Sag ihm, das ist Mathematik. Ich habe damit bisher nur mäßigen Erfolg, aber ich bleibe dabei.

Und was habe ich nun davon? Eine App, die für den Funkbetrieb ziemlich genau nichts taugt. Und einen Respekt vor Joe Taylor (K1JT) und Steve Franke (K9AN), der beim Bauen mit jeder Woche gewachsen ist. Ich wollte FT8 nur nachbauen, um es zu verstehen. Jedes Problem, über das ich gestolpert bin, hatten die beiden längst gelöst, und zwar gründlicher, als ich es je hinbekommen würde. Wie viel Hirnschmalz in diesem Protokoll steckt und wie robust es ist, merkt man erst, wenn man selbst versucht, ein Signal durch ein Wohnzimmer zu schicken. Der Nobelpreisträger und sein Kollege können also beruhigt sein: Von mir droht keine Konkurrenz.

Wobei, ganz nutzlos muss es nicht bleiben. Der AATiS (Arbeitskreis Amateurfunk und Telekommunikation in der Schule e. V.) hat den ELiSE Photonic Communicator im Programm, ein Lichtsprechgerät als Komplettbausatz mit Optik, Mikrofon und 3D-Druckteilen. Laut AATiS ist er tageslichttauglich und überbrückt auch am Tag 1 bis 2 Kilometer. In einem ihrer Videos wird damit sogar ein SSTV-Bild über 900 Meter empfangen. Wenn Bilder durchs Licht kommen, warum nicht auch FT8? Zwei Handys, zwei Lichtstrahlen und null Watt Hochfrequenz. Ob das klappt, weiß ich noch nicht. Ich werde gegebenenfalls berichten.

73 und bis zum nächsten Wasserfall!