High noise (QRN) and weak signals:
This is its primary use. If the background noise is so high that the decoder constantly detects “false starts” (incorrect start bits), the flywheel ensures that only edges that are in sync with the RTTY signal are accepted.
Diddles (idle signals):
When the transmitter sends “diddles” (usually the LTRS character) between words, the flywheel remains perfectly synchronized. It prevents short bursts of noise during the pauses from disrupting the decoder’s synchronization.
Longer texts:
With continuous text, the flywheel offers tremendous stability. Once synchronized, the decoder “knows” when the next character is coming and almost completely ignores interference in between.
Very strong and clean signals:
If the signal is far above the noise floor, a flywheel is unnecessary. A purely asynchronous decoder reacts a fraction of a second faster to the very first character of a transmission because it doesn’t require a synchronization phase (the first character).
Transmitters with unstable timing:
Some very old mechanical teletypes or poorly programmed controllers have slightly jittery timing (the bits are not exactly the same length). The flywheel could mistakenly block valid start bits if they are slightly outside the expected range.
Short bursts:
If only very short bursts of information (e.g., a short “R R” or “73”) are transmitted, the flywheel could miss the beginning while waiting for synchronization.
Transmitters with unstable timing:
If you’re still searching for the correct frequency, it’s often better to leave the flywheel off so the decoder reacts immediately to each edge, allowing you to see if anything decodable is actually arriving.
In practice, the flywheel is usually left off with modern software decoders as long as the signal is easily readable. As soon as the signal becomes lost in noise or “garbage characters” appear during pauses, it’s switched on to stabilize the decoding.