I am looking for RTTY AFSK specifications. I am a little confused when coding the Baudot code; not the normal characters, but the symbols and numbers.


1 Answer 1


The 5-bit Baudot code only has 32 combinations, so a special trick is used to encode 52 different letters, numbers and special symbols.

The key concept is that the receiver can be in one of two different states or modes, and two of the 32 codes are reserved for putting it into one state or the other. 11111 puts it into "letters" mode, while 11011 puts it into "figures" mode.

There are a few control codes that do the same thing regardless of which mode the receiver is in:

  • 00000 is "null"
  • 00010 is line feed
  • 00100 is space
  • 01000 is carriage return

The remaining 26 codes are interpreted according to the current mode of the receiver. In "letters" mode, they represent the letters of the alphabet. In "figures" mode, they represent the digits and various special characters.

As an example, to transmit "N3AOA", you would send the following string of codes:

11111 01100 11011 00001 11111 00011 11000 00011
LTRS    N   FIGS    3   LTRS    A     O     A

Does this address your confusion?

  • $\begingroup$ yes thanks...it was very usefull...my fellow radioamateurs are going to be happy :) i am trying to implment a microcontoller based rtty decoder... $\endgroup$ May 29, 2016 at 19:58
  • $\begingroup$ @dave oh man. Shannon and Huffman would have a bit to say about that coding. And it would not be nice. But that's the way of standards. $\endgroup$ May 29, 2016 at 21:51
  • 1
    $\begingroup$ @DuarteFerreiraDias: In that case, there is one other subtlety that you might need to be aware of. Many receivers implement a feature called "unshift on space", which means that any space character also has the side-effect of putting the receiver in "letters" mode. This is an optimization that reduces the number of explicit LTRS codes that need to be sent, since most RTTY traffic is alphabetical. $\endgroup$ May 29, 2016 at 22:21
  • $\begingroup$ @MarcusMüller: If you read the Wikipedia article that I linked to, you'll see that this code was highly optimized in its own ways that were relevant at the time. Ultimate coding efficiency wasn't all that important. $\endgroup$ May 29, 2016 at 22:25
  • $\begingroup$ @DaveTweed Indeed, fair point! Usability for a certain use case and device was probably much more important than saving a few Hz of bandwidth $\endgroup$ May 30, 2016 at 13:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .