RTTY
[Top] [All Lists]

[RTTY] Some FSKit thoughts.

To: RTTY Reflector <RTTY@contesting.com>
Subject: [RTTY] Some FSKit thoughts.
From: Kok Chen <chen@mac.com>
Date: Sat, 30 Jul 2011 13:32:00 -0700
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>
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




_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty

<Prev in Thread] Current Thread [Next in Thread>
  • [RTTY] Some FSKit thoughts., Kok Chen <=