The following is another in my s

A single tone in AFSK is basically the same as a carrier wave on a designated RF frequency -- in other words, CW, and sent at a VERY slow speed! (Infinitely slow, in fact.) Therefore, a shorthand tone takes up practically no bandwidth, which reduces the signal-to-noise ratio required by the decoding software to a much lower level than that required for decoding multi-tone FSK441 signals. A shorthand tone at 10 dB below the noise floor can be decoded with a high level of confidence if it is detected multiple times with the same frequency offset, or "DF". (Understanding and working with the DF parameter is beyond the scope of this article.)

The implication of this is obvious: To complete an FSK441 QSO, only one "strong" audible ping is required in each direction: one ping going one way for Tx1 (both calls), and another ping going the other way for Tx2 (both calls plus reports). Once these two encoded messages have been received clearly, shorthand tones can take over at a much higher sensitivity level.

The presence of a particular shorthand tone is like a binary "1", saying that some singular thing exists rather than does not exist. That is ALL the information a single tone can carry! Therefore, shorthands cannot be used to represent callsigns and combinations of callsigns, of which there are potentially millions. The four designated shorthand tones can represent ONLY messages Tx3 (two tones standing for either R26 or R27), Tx4 (RRR), or Tx5 (73). The definition of what each tone frequency means is contained within the FSK441 protocol and is global, so there is no room for alternative meanings.

Since the shorthand tone cannot, by definition, represent any callsign or other identifying information, it is only meaningful and "legal" when there is no doubt as to the identity of the station transmitting the tone. This identity must be determined beyond doubt in the previous two steps of the QSO (Tx1 and Tx2). Confirming that the shorthand tone being heard comes from the same station thus identified is covered below in section "Accurate visual and aural decoding of weak shorthand messages."

Many WSJT users assume that, by marking the Sh Msg checkbox in the main screen, shorthand messages will always be transmitted and automatically decoded by WSJT. This is not true! It's not that simple.

First, the Sh Msg checkbox is a transmit-only control. It has no effect on any receive behavior. Marking it will not cause WSJT to decode received shorthand tones!

Second, marking the Sh Msg checkbox allows WSJT to transmit messages Tx3, Tx4, and Tx5 as shorthand tones only if the messages that appear in these fields are the unaltered default texts. For example, if message field Tx3 contains only R26 (or R27) and the Sh Msg checkbox is marked, then a shorthand tone will be transmitted for the appropriate signal report. If, however, you manually modify the text to say "WVO R26", this message will NOT be sent as a shorthand tone, even if you have the Sh Msg box marked. It can't be -- there is no way to encode a call suffix in a single tone, because there are thousands of different call suffixes. This message will be encoded as regular FSK441 text.

WSJT will tell you whether it is transmitting a shorthand tone or encoded text, even if you're not audibly monitoring what you are transmitting. If WSJT is transmitting a shorthand tone, the transmit/receiving status field in the lower-right corner of the main screen will have a CYAN (blue) background. If WSJT is transmitting encoded text, this field will have a YELLOW background. (If WSJT is receiving, it will have a GREEN background.) Get into the habit of checking this field as you begin to transmit.

WSJT can be set up to automatically decode shorthand tones or to ignore them. The control to turn this capability on or off is in the main screen menu bar. Click Decode => FSK441 and observe the state of the No shorthands menu option. If there is a checkmark next to it, then automatic decoding of shorthand tones is disabled. If there is no checkmark, then WSJT will try to decode shorthand tones it thinks it detects. The recommended state of this option is CHECKED (shorthand tone decoding disabled). Why?

First, decoding shorthand codes is easily done visually on the waterfall display as well as aurally (audibly). Your eyes and ears are at least as sensitive and accurate as the WSJT software for detecting shorthand tones, and oftentimes more so.

Second, various samplings of signal and noise can cause false shorthand decodes when no shorthand tones are actually being received. While a false shorthand decode is obvious to an experienced FSK441 user, it can be very confusing to the newbie who tends to trust the software implicitly. The most common false shorthand message decode is R27, but any of the four can pop up as false decodes. The only sure-fire way to eliminate false shorthand decodes is to turn shorthand decoding OFF.

Third, simply enabling shorthand decoding won't necessarily cause shorthand tones to be decoded correctly unless they are quite strong -- strong enough to have allowed decoding of the equivalent FSK441 message in the first place! In order to get WSJT to decode a shorthand tone that is extremely weak (below the noise floor), you must make a number of adjustments both to WSJT and to your transceiver. Learning everything you need to know in order to do this correctly is beyond the scope of this article.

First, make sure you and your QSO partner are alone on the frequency, and above all make sure you are not on the calling frequency. By convention, shorthands are not used on the calling frequencies (50260 kHz and 144140 kHz) because stations worldwide use these frequencies to make and respond to random unscheduled calls. Please do not use shorthand messages on the calling frequencies!

Second, be aware of any birdies on the chosen radio frequency. If you have a birdie exactly on one of the four shorthand audio tone frequencies, then this is not a good place for the use of shorthand messages. Find another radio frequency before you start the QSO — one where the birdies, if any, are clearly distinguishable in frequency from the four shorthand tone frequencies.

Third, know which shorthand message tone frequency you are expecting based on where you are in the QSO protocol, and assume any other tone you think you hear or see is not legitimate. If you're certain the other operator is truly sending this incorrect tone, it usually means the QSO attempt must be started over.

Fourth, verify that the tone's frequency offset makes sense when compared with the DF recorded for the station's FSK441-encoded message (Tx1 or Tx2). If the Tx1 or Tx2 DF was positive, then the shorthand tone's horizontal trace on the SpecJT waterfall display should be proportionately above the level of the appropriate hashmark. Conversely, if the DF was negative, then the shorthand tone's position should be proportionately below the appropriate hashmark. You may want to put a ruler or paper edge up on the screen to see more clearly whether the suspected shorthand trace is above or below the hashmark for the expected tone, and by how much. Do this in SpecJT, not in the main screen waterfall, which has lower resolution.