[Elecraft] Ideal RTTY filter.

Sat May 18 09:02:58 EDT 2013

Back in ye olde days of RTTY when we used mechanical printers, the 
thinking was that the minimum bandwidth required was that sufficient to 
pass the 3rd keying sideband without too much attenuation or time shift. 
(This was way before measuring group delay was something that could be 
done other than in a well equipped lab, but if you looked at the output 
of the modem detector after the low pass filter and before the slicer, 
an oscilloscope clearly showed the changes resulting from changing the 
tone filter and low pass filter bandwidths.

60 WPM Baudot RTTY has a data rate of 22 Hz*, so the 3rd keying 
sidebands would be ±66 Hz from the tone. With 170 Hz shift, and a single 
passband filter, the outer (upper and lower) keying sidebands would be 
at 66 Hz above and below. Hence the target filter bandwidth would be 302 
Hz.

A more technical explanation is that the tone filters, post-detection 
low pass filter and slicer work to restore the transmitted waveform and 
that waveform reconstruction becomes more difficult and less accurate 
the more keying sidebands are removed. A Fourier analysis of a square 
wave will show this as you increase the number of terms (harmonics of 
the keying waveform) in the reconstruction.

If you want to tinker a bit, there's an on-line Fourier simulator at 
http://www.facstaff.bucknell.edu/mastascu/elessonsHTML/Freq/Freq4FourierSeriesSimulators.htm 
-- select the square wave and run it with 1, 3, 5, 7 etc. harmonics and 
you will see that passing just the 3rd harmonic yields a not that bad 
appearing square wave.

Where things get a bit more complicated is that these simple rules and 
the Fourier simulator assume the harmonics are passed without 
significant time (or phase if you prefer to think of it that way) shift. 
Depending on the tone filter design, there may well be significant time 
shift between the tone frequency and the keying sidebands. A filter with 
uniform time delay, such as a Bessel will be much better in this regard 
than the same order Chebyshev, for example, but for the same filter 
order and -3 dB bandwidth, the Bessel will demonstrate much wider 
skirts. At least in the days when we built filters from 88mH loading 
coils, there was always tension between designing a filter with a 
picture perfect square sided response but with gross time distortion and 
one with a rounded nose and gentle flank selectivity and low  time 
distortion. A Butterworth filter was used in most modem designs of that 
era as a compromise between time distortion and flank response and also 
the ability to design and implement the filter. DSP based filters are a 
huge improvement over those LC filters and permit good time delay 
performance and skirt selectivity.

Jack K8ZOA ... my first piece of RTTY gear was a model 15 page printer 
acquired surplus in the late 1960's from Michigan Bell Telephone through 
their ham radio - RTTY program.

* 60 WPM Baudo = 368 operations per minute, 7.42 length code = 45.5 
baud, or 22.7 Hz.

On 5/18/2013 8:18 AM, Brian Alsop wrote:
> Ed et al,
>
> As I said in my posting the receive filter info came from a quote 
> attributed to Chen in the QST article.  I pointed out that the link 
> supplied by QST was not for receive.
>
> So we either have to accept the quote of Chen on the receive side 
> (additional data exists that Chen has?) or the QST author got it wrong.
>
> Nothing at all was said about dual peak filtering which is used by 
> many of us in conjunction with a 400 or "250" filter.
>
> It would be nice to someday finally nail this whole RTTY filter issue 
> down.  Also it would be nice to find a set of optimum AGC settings for 
> RTTY.  I suspect there are parameters or a formulation that would 
> produce less spurious clicks.  AGC off is definitely not a practical 
> solution.
>
> 73 de Brian/K3KO
>
> On 5/18/2013 04:17, Ed Muns wrote:
>>
>>
>> Brian K3KO wrote:
>>
>> This comes from June 2013 QST page 59.
>> First of all, Chen's article is about transmit filtering which is not
>> directly translatable to optimal receive filtering.  Second, the cascade
>> effect of the K3 crystal filter and DSP filter must be considered in
>> determining the net receive bandwidth.  So very different net receiver
>> bandwidths result depending on what DSP bandwidth is used with the 
>> engaged
>> crystal filter bandwidth, e.g., KFLA250 which is really a 370 Hz filter.
>> Third, the ideal receive bandwidth for optimal decoding is not the 
>> same as
>> the transmit bandwidth for minimum QRM.  Depending on the decoder, a
>> receiver bandwidth of around 400 Hz is optimum ... unless there is 
>> such a
>> heavy QRM situation that a better overall system trade-off is 
>> obtained with
>> narrower, e.g., 250 Hz, net IF bandwidth.  A transmit filter of 280 
>> Hz is an
>> optimum trade-off between minimizing QRM to neighboring QSOs and 
>> maintaining
>> signal integrity for the intended receiver.  Finally, this transmit 
>> filter
>> can be implemented in either the radio or the encoder.  MMTTY, for 
>> example,
>> provides a number of transmit filter bandwidths and the default 
>> 48-tap TX
>> bandwidth for AFSK meets Chen's proposal.
>>
>>
>> Ed W0YK
>>
>>
>> According to W7AY:
>>
>> The ideal RTTY filter is 280 Hz wide.  Narrowing it further by 60 Hz
>> doubles the error rate.
>>
>> The article references:
>> http://www.w7ay.net/site/Technical/RTTY%20Transmit%20Filters/index.html
>>
>> Which doesn't come out and say the above!  It's talking about transmit
>> filters.  W7AY doesn't like uneven power in transmit tones either.
>>
>> Anyhow this may confirm what has been said on this reflector. The 350 Hz
>> (AKA 250 Hz) filter is probably the narrowest practical choice for RTTY.
>>
>> ______________________________________________________________
>> Elecraft mailing list
>> Home: http://mailman.qth.net/mailman/listinfo/elecraft
>> Help: http://mailman.qth.net/mmfaq.htm
>> Post: mailto:Elecraft at mailman.qth.net
>>
>> This list hosted by: http://www.qsl.net
>> Please help support this email list: http://www.qsl.net/donate.html
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2012.0.2242 / Virus Database: 3162/5835 - Release Date: 
>> 05/18/13
>>
>>
>
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.2242 / Virus Database: 3162/5835 - Release Date: 05/18/13
>
> ______________________________________________________________
> Elecraft mailing list
> Home: http://mailman.qth.net/mailman/listinfo/elecraft
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:Elecraft at mailman.qth.net
>
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
>