[RTTY] Some FSKit thoughts.

[Kok Chen]

I think most ARRL members on this reflector must have read Doug K4DSP's article in the August QST by now.  Except for the yearly Roundup pages by WS7I, how often do you read an article in QST that pertains to RTTY? :-)

The FSKit causes me to think a bit about FSK keying.  Please hit the delete key if you have no interest in the topic.  I would be the last person to be offended :-).

Those who are long time readers of this reflector know that Doug had played with the "FSK regeneration" for a while now.  It started with this:

http://lists.contesting.com/_rtty/2005-03/msg00035.html

That effort later evolved to this:

http://lists.contesting.com/archives//html/RTTY/2008-03/msg00052.html

And in turn, I think it led to Doug building an updated PC board, and making it available as the FSKit.

The same idea has also been brought up by others over time.  See this thread

http://lists.contesting.com/archives//html/RTTY/2008-02/msg00168.html

The above links, and Doug's QST article already mentions the reason for the need of such a contraption, so I won't go over it again.

I had been mulling over the term "regeneration" as used in this context.  Notice that this is very different and should not be confused with "regeneration" that is available in the HAL ST-8000 and Timewave 599zx.  

In the HAL and Timewave case, the AFSK from a receiver is demodulated into the on-and-off symbol bits, just as it would do to send to a Baudot decoder.  But instead of decoding further, the HAL regenerator sends this signal (which is precisely one-to-one with an FSK keying signal when you are transmitting) is sent to an AFSK generator to produce a clean audio output that is modulated between two audio tones ("AFSK").  

The clean AFSK from the HAL and Timewave regenerator can then be fed to lesser performance modems to decode.  Since the regenerated tones has a SNR north of 40 dB, the "lesser" modems will not add any additional demodulation errors.  The lesser modem will produce output exactly as the regenerating modem sees it.

The regenerating modem is operating purely as a hardware filter that sits between the receiver and the "actual" modem (e.g., KAM) that you use.  You do not need software to ruse the regenerator. 

The regenerators can also be used to front end a software modem -- but in this case, many software modems are superior to the HALs and the Timewaves themselves (or at least more flexibly adjustable to different propagation conditions), so there is not much of a reason to use regenerators ahead of the software modems.

Anyhow, what the regenerators do is

Receiver --- (dirty AFSK)  --- demodulator in modem --- (FSK) --- regenerator in modem --- (clean AFSK) --- demodulator in modem --- (bit stream representing FSK) --- Baudot Decoder in modem.

OK, back to the FSKit...  what it does is:

Baudot Encoder in modem --- (bit stream representing FSK) --- modulator in AFSK Modem --- (clean AFSK) --- demodulator in FSKit --- (FSK) --- Transmitter.

Notice that the FSKit is almost a mirror image of a HAL regenerator.  The HAL regenerates a clean AFSK signal, while the FSKit regenerates the original "FSK" keying bit stream.  

Since the modem's modulator produces clean AFSK, the FSKit's demodulator can be very simple and yet for all practical purposes, does not add any error. 

To distinguish between the two, perhaps one can call the HAL case a "receiving regenerator" and the FSKit case a "transmitting regenerator."

An alternate way also exists for keying an FSK transmitter through a sound card.  The modulation method is in fact the first "digital modulation" mode that one encounters in communications classes, and that is the simple On-Off Keying (OOK) method.  See for example 

http://en.wikipedia.org/wiki/On-off_keying

For a comparison between OOK and FSK, see here (ASK is like OOK, but switching between two amplitudes instead of switching between a full on tone and a filly off tone):

http://www.rfm.com/corp/appdata/ook.pdf

OOK is indeed the original mode used in amateur RTTY.  (For that matter, CW is also an OOK mode.)  

However, OOK is not that great through HF propagation because selective fading can take that single toe out completely and you are left with nothing to decode with.  For that reason, hams doing RTTY moved on to using two tones and switching between them (FSK).  When one tone vanishes, you can use the other tone to decode with.  FSK also has a crest factor that is 3 dB lower than OOK.  If you transmit with the same peak RF power, then FSK has a large SNR advantage over OOK.

But, OOK does not suffer any of the HF propagation problem, if you don't transmit it over the air.

There are even commercial interfaces in the ham market (e.g., the MicroHAM USB Interface III and their DigiKeyer II) that will accept OOK tones and turn them into a FSK and CW keying signals.  Completely error free and with minimal jitter.  Since USB audio is declared to be isochronous, it is never allowed to drop a single sample by computer operating systems.

However, to my knowledge there are only two software modems that produces OOK tones -- fldigi and cocoaModem.  fldigi does not call it OOK, but the functionality is there.  In cocoaModem, OOK is not done by just simply removing one of the transmitted AFSK tone -- cocoaModem performs AFSK waveshaping, so that waveshaping is removed when transmitting in OOK to reduce any possible bit jitter in the decoder.  In addition, to further reduce any jitter of the leading edge or trailing edge of the keying pulse, the frequency of the OOK tones that cocoaModem uses for both CW and RTTY are deliberately chosen to be high.

OOK is very easy to implement, both in the interface hardware and in the modem software.   I am certain that detecting the presence and absence of a tone in the USB Interface III is much easily implemented than the AFSK demodulator in the FSKit.  In a software modem, I can't see it taking more than a line or two of additional code over an existing AFSK implementation.  

Unfortunately, OOK is a chicken-and-egg problem.  Few software modems has the capability, so commercial interfaces find no market for it and as a result few commercial interfaces implement a decoder to convert OOK to FSK keying, or to convert OOK to CW keying.  That in turn causes a vicious cycle since the software developers that wants to be "popular" do not waste their time implementing things that few users can make use of.

IMHO, we should push for more software modems to implement OOK -- that may cause more commercial interface manufacturers to implement OOK to FSK keying.  Or, alternately push for FSKit type functionality in more commercial interfaces, so they can be use with any software RTTY modems for generating FSK keying.

Anyhow, if you have read this far, you are either crazy, or you are a certifiable RTTY nutcase.  (I suppose that is a redundant statement. :-).

73
Chen, W7AY