Viel Rauschen (QRN) und schwachen Signalen:
Dies ist der Haupteinsatzzweck. Wenn das Grundrauschen so hoch ist, dass der Decoder ständig „Fehlstarts“ (falsche Startbits) erkennt, sorgt das Flywheel dafür, dass nur Flanken akzeptiert werden, die zeitlich im Rhythmus des RTTY-Signals liegen.
Diddles (Leerlauf-Signale):
Wenn der Sender zwischen den Worten „Diddles“ (meist das LTRS-Zeichen) sendet, bleibt das Flywheel perfekt synchronisiert. Es verhindert, dass kurzes Prasseln in den Pausen den Decoder aus dem Tritt bringt.
Längeren Texten:
Bei einem fließenden Text bietet das Flywheel eine enorme Stabilität. Einmal synchronisiert, „weiß“ der Decoder, wann das nächste Zeichen kommt, und ignoriert Störungen dazwischen fast vollständig.
Sehr starken und sauberen Signalen:
Wenn das Signal weit über dem Rauschen liegt, ist ein Flywheel nicht nötig. Ein rein asynchroner Decoder reagiert hier einen Tick schneller auf den allerersten Buchstaben einer Sendung, da er keine Synchronisationsphase (das erste Zeichen) benötigt.
Sendern mit instabilem Timing:
Manche sehr alten mechanischen Fernschreiber oder schlecht programmierte Controller haben ein leicht „jitterndes“ Timing (die Bits sind nicht exakt gleich lang). Das Flywheel könnte hier gültige Startbits fälschlicherweise blockieren, wenn sie leicht außerhalb des erwarteten Fensters liegen.
Kurzen „Bursts“:
Wenn nur ganz kurze Infos (z. B. ein kurzes „R R“ oder „73“) gesendet werden, könnte das Flywheel den Anfang verschlucken, während es noch auf die Synchronisation wartet.
Abstimmvorgang:
Wenn du noch nach der richtigen Frequenz suchst, ist es oft besser, das Flywheel auszulassen, damit der Decoder sofort auf jede Flanke reagiert und du siehst, ob überhaupt etwas dekodierbares ankommt.
In der Praxis lässt man das Flywheel bei modernen Software-Decodern meist aus, solange das Signal gut lesbar ist. Sobald das Signal im Rauschen versinkt oder „Müll-Zeichen“ in den Pausen erscheinen, schaltet man es ein, um die Dekodierung zu stabilisieren.