[RTTY] 300hz or 500hz IF filter?

[Kok Chen]

On Aug 23, 2013, at 10:15 PM, Ed Muns wrote:

> Fourth, when I tried opening up the bandwidth on difficult decoding
> situations, many times decoding improved.  When 2Tone came along I found
> that a 500 Hz receiver bandwidth decoded much better than a narrower
> bandwidth, even in high QRM and pile-up conditions, most of the time. 

Ed hit the nail on the head!

The reason Ed has to widen the receiver filter (i.e., the modem sound card's roofing filter) is because the filter in 2Tone is already optimal, and therefore what I showed in Figure 2.2 in http://www.w7ay.net/site/Technical/RTTY%20Transmit%20Filters/index.html applies.

In short, the filter in the receiver is doing nothing but adding intersymbol interference (ISI) to the already optimized demodulation filter in G3YYD's 2Tone program. 

If you had tried the same experiment on the version of fldigi that was released in the last 6 or 9 months, you will find the same thing to also be true.  It is well known that wider receive filters are better for RITTY and cocoaModem.

This applies doubly to the so called twin peak filters (what was called a Comb filter by Frank Gaude back in the RTTY Bulletins back in the 1960s).

Use a "twin peak" filter in front of 2Tone, and you will find that the ISI from then will cause even more harm to 2Tone than narrow roofing filters.

The reason narrower filters (and twin peak filters) work better with MMTTY is because the filter inside MMTTY is not optimal for 45.45 baud RTTY.  Narrowing the receiver's crystal filter probably improved the SNR for MMTTY, and that took precedence over the increased ISI

On Ed's second point regarding QRM and wide filters with 2Tone: the reason the widened filter will not cause any harm at all to 2Tone in the presence of QRM is that its already the narrowest filter you can build for RTTY without causing ISI.    This holds true until the point where a very strong QRM causes the sound card to clip.

If you have a sound card that has better dynamic range than the receiver, then you never have to worry about clipping the sound card before the receiver itself folds.  If you don't have a good sound card, then you would need to ride the RF gain control of the receiver so the sound card stops clipping, and everything will again work fine as long as the sound card's dynamic range is no smaller than the difference between the QRM and the weaker signal you are trying to copy. 

If the QRM or its keyclicks is overlapping and louder than the weak signal, then all bets are off.  The only thing that will save that situation is possibly diversity RTTY, but that is a different topic altogether.

-----

On a slight tangent, while we are on the subject of optimal RTTY filters, the optimal Raised Cosine filter is all good when there is no multipath.  Andy K0SM and I were just discussing this aspect offline earlier.  

If you look at the impulse response of the Raised Cosine (especially when beta is less than 1), it rings like crazy.  Yet the ringing does not cause it to wipe out the next bit. The reason is that while Nyquist filters ring, they always pass precisely through zero at the middle of the bits that follows it, and that is where the next bits are sampled -- and thus no ISI.  

However, there are also two cases that cause these "perfect" filters to break down -- the first is if you use some bit period that is not precisely 22ms.  This can be the result of not using exactly 45.4545 baud, or when you use hardware bit-banging to perform FSK, where the bit periods will jitter from bit to bit.

The second case where the Raised Cosine will no longer be optimal for RTTY decoding is when there is multipath (I am told that area of 2Tone still needs improvement).  Multipath will cause the Mark and Space bits to advance or retard relative to one another.  ITU HF Simulation models have the bits advancing and retarding by up to an average of 7 ms (with a Gaussian probability density function) during severe high latitude flutter and during poor NVIS conditions.  

So how much harm does multipath and wrong baud rates contribute to ISI?  Turns out to be quite a bit.  

If you go look at Figure 8 here http://w7ay.net/site/Technical/Extended%20Nyquist%20Filters/index.html , you will find a red curve for the impulse response of a raised cosine filter, there is ISI when the red curve does not pass exactly through zero at the middle of the "next" bit(s).  

Notice that the red curve rises steeply when the distance between the two successive bits are shortened -- so much so that if the multipath is 11 ms long, the ISI is only 6 dB below the signal itself -- i.e., you have lost 6 dB of SNR due to ISI -- equivalent to reducing your transmit power by four.

The moral of the story are 

(1) the Raised Cosine is optimal only during good conditions, just don't bet on it being very good when there is multipath, a good modem will need other mechanisms to counter multipath -- perhaps a bank of different voting filters or an adaptive equalizer that changes the relative delays between mark and space demodulators (cocoaModem uses multiple delays that goes through a voting mechanism, for example). 

(2) if you cannot get precisely 45.45 baud (e.g., the MicroHam microkeyers), choose a baud rate that is *slower* than 45.45 baud.  I.e, if you can choose between 45.0 or 46.0 baud, choose 45.0, since it will fall on the "shallower" side of the Raised Cosine's ISI curve.  Do not choose the higher baud rate to shave a few milliseconds from a contest exchange.  You can send your exchange faster with faster baud rate, but you will also be asked for more repeats since the other end cannot copy you as well.  To optimized your transmit signal for the good modems at the other end, always use 45.45 baud precisely and never, ever use bit banging techniques.

Finally, a hint for those interested in copying through polar flutter... of all Nyquist filters, a Matched Filter is the one that is the most immune to multipath ISI since its impulse response is a rectangle.  K6STI was no fool when he chose a Matched Filter for RITTY.

73
Chen, W7AY