RTTY
[Top] [All Lists]

Re: [RTTY] 300hz or 500hz IF filter?

To: RTTY Reflector <rtty@contesting.com>
Subject: Re: [RTTY] 300hz or 500hz IF filter?
From: Kok Chen <chen@mac.com>
Date: Fri, 23 Aug 2013 10:13:44 -0700
List-post: <rtty@contesting.com">mailto:rtty@contesting.com>
(Warning... as often true with my postings, this is long and technical.  Please 
don't hesitate to use your Delete key).

On Aug 23, 2013, at 8:19 AM, Jay WS7I wrote:

> Joe-
> 
> You are just simply wrong. 


When Joe threw out his red herring, he also caused the original thread to 
splinter, in a non-obvious fashion for those who do not intimately follow RTTY. 
 I am sure people who build demodulators know full well what I am going to say, 
but I want to clear it up a little for the general audience.

The original poster had asked for what receiving filter to use, which has to do 
with the demodulated bit stream, and not of some bureaucratic definition of the 
"bandwidth" of a transmitted signal, which the ITU chooses to use as a 
standard.  The former has to do with what *receiving* filter to use and the 
latter has to do with some standard to classify different emission modes (i.e., 
transmitter bandwidth).

As a few of us (including Andy K0SM and myself) have shown, especially in the 
past year, a transmitted RTTY signal can occupy very different transmitted 
bandwidths.  And all are different from what the ITU states.  

The widest form of transmitted RTTY is the so called "phase coherent" AFSK or 
FSK generation.  With this method, the Mark and Space tones come from two 
different coherent sources (which can be individually phase locked at the 
receiver).  And to bit modulate for RTTY, you simply switch between these two 
oscillators.  The Mark and Space are treated as two separate OOK (on-off 
keying) signals.

(This, by the way, is probably closest to what the ITU consider to be FSK 
"bandwidth.")

The result is a very broad sin(x)/x spectrum for each Mark and Space signal.

We know that the best narrow band receiving filter for RTTY is a Raised Cosine 
that goes to zero outside a single fundamental of the keying signal (i.e., 
45.45 Hz divided by 2), so all those extra keying sidebands from a phase 
coherent FSK signal is completely wasted.  Not only are you QRM'ing other 
stations, but you are also wasting transmit power that you can otherwise focus 
on to the main Mark and Space lobes (not much wasted power, but the extra SNR 
can probably affect your contest score -- so it behooves a contester to use as 
narrow a transmitted signal as possible -- thus my RTTY TRansmit Filter article 
which I mentioned a day ago).  When you clean up your signal, not only are you 
a better neighbor, but you are also spending all your transmit power where it 
matters to the receiving end.  This probably outweighs any "millisecond 
shaving" efforts.

The next form of RTTY generation is called the "phase continuous" FSK/AFSK.  In 
this form, a single oscillator is used to represent both the Mark and Space 
carriers.  However, when you switch between Mark and Space, you do it in a 
manner so that the instantaneous phase does not change during a transition.  

Back in the 1960s, Irv Hoff had suggested a form of AFSK generation where you 
switch between Mark and Space right when they cross zero voltage.  
Mathematically, it is absolutely identical to the phas continuous case, but 
suffers from the fact that you need to choose Mark and Space frequencies that 
perfectly divides 22.0 milliseconds.  I.e., you no longer have the standard 
2125/2995 Mark/Space tones.  This method is so identical to the 
phase-continuoys method that it has the same precise higher order 
discontinuities. No one uses Hoff's method in software, since phase continuous 
is just as easy and much cleaner to implement.  

(Switching at zero crossing is used in PSK31, by the way as a mechanism to 
reduce bandwidth; but they only have a single carrier frequency to worry about, 
not the two we have in RTTY.)

The EE's among you will immediately see how much the keying sidebands are 
reduced by going to phase continuity.  However, just because instantaneous 
phase is continuous, the higher order derivatives of phase cannot also be 
continuous (otherwise the signal will be output as a single unmodulated tone, 
HI HI).  These higher order derivatives will also generate unwanted and 
unneeded keying sidebands, albeit, very much attenuated compare to the phase 
coherent case above.

The next step is to get rid of the unwanted keying sidebands from the phase 
continuous RTTY.  This can be done in software/firmware by using waveshaping, 
or can be done in software/hardware by applying a narrow bandpass filter.  
Examples of this: 2Tone uses waveshaping and cocoaModem uses filtering.

This extra filtering can be implemented both in the modem or in the FSK 
transmitter, as the K3 has shown when Elecraft modified their firmware after 
Andy showed how dirty an FSK signal from a K3 was before the modification.

OK, none of this is new.  I am just trying to refresh everyone's memory on what 
transmit occupancy of an RTTY signal means.  Indeed, I had written the "FSK 
Sidebands" article back in 2005 that shows the spectra of the three methods 
(phase coherent, phase continuous and filtered phase continuous) mentioned 
above:

http://www.w7ay.net/site/Technical/RTTY%20Sidebands/sidebands.html

Note that although the ITU assigns a single "bandwidth" number to all three 
cases of RTTY (ITU does not distinguish between them), they do not have the 
same actual bandwidths.  

Now, as to receiving filters, a Raised Cosine filter will behave identically to 
all the three transmitted methods.  An optimal Raised Cosine will indeed lop 
off lots of the keying sidebands from any of the transmitted signal above.  The 
transmitted keying sidebands are neither used by the demodulator, nor are they 
helpful for RTTY demodulation when a Raised Cosine is used at the receiver.

K6STI's RITTY and cocoaModem both use Matched Filters instead of Raised Cosine 
filtering.   As such, they have a slight edge with both phase coherent and 
phase continuous signals over the filtered RTTY transmitters.  By how much?  
Take a look at Figure 4 here:

http://w7ay.net/site/Technical/Extended%20Nyquist%20Filters/index.html

For the signals that we encounter in weak signal RTTY (about 3% character error 
rate), the Matched Filter beats out a Raised Cosine by perhaps 0.25 dB.

However, a Matched Filter is very wide and really only suitable for digging out 
your call sign from that elusive weak DX.  There will be too much QRM under 
contest conditions to use a Matched Filter, where what you want is a Raised 
Cosine (a Raised Cosine is way more narrow than any crystal filters than can be 
manufactured without group delays).

Indeed, it is the quest for some filter whose bandwidth that is in between a 
Raised Cosine and a Matched Filter that lead to my work which resulted in this 
"Extended Nyquist Filter" article.  It is probably the crown jewel of my RTTY 
work.  The recursion in both the time domain (impulse response) and frequency 
domain (transfer function) was especially satisfying :-).

In conclusion: you can use the ITU bandwidth as a *regulatory* number (like 
when you need it as an argument to present to the FCC when the ARRL again tries 
to force bandwidth numbers on ham bands), but they don't really represent the 
real world of RTTY emissions.   Look at the spectrum that K0SM recorded and 
which Jay displayed in this past ARRL Roundup results.  The bandwidths are all 
different, and I think all of them have equivalent bandwidths that are narrower 
than the ITU number :-).

Furthermore, that ITU transmitted (occupancy) bandwidth has *nothing* to do 
with optimal receiving filters.  Narrow, optimal receive filters that presents 
no intersymbol interference has been with us since Harry Nyquist's 1928 paper.  
Nyquist really developed it for landline telegraphy (OOK).

73
Chen, W7AY





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

<Prev in Thread] Current Thread [Next in Thread>