Chen,
Fascinating explanation. Best technical treatment of this subject I've
seen.
The summary trade-off compromise (if I am understanding your comments
properly) is something like this:
1. With a more narrow bandwidth, we have a better ability to suppress
adjacent strong stations, especially their sideband amplitude - which will
somewhat increase the SNR of our desired station.
2. However, with a more narrow bandwidth, we ALSO cut more of the desired
station sidebands off - which reduces the received energy from the target
station, and thereby reduces the SNR of our desired station.
3. Complication: **AND** Various implementations of the transmitted RTTY
signal (as well as the keying sequence of the data) - all effect the actual
bandwidth.
With this summary, assuming it's correct, what do we conclude the best
overall contest-duty -6db bandwidth filter for RTTY - in the case we assume
a PERFECTLY centered and tuned desired station in the passband?
73/jeff/ac0c
--------------------------------------------------
From: "Kok Chen" <chen@mac.com>
Sent: Thursday, August 27, 2009 2:42 AM
To: "RTTY Reflector" <rtty@contesting.com>
Cc: "Jeff Blaine AC0C" <keepwalking188@yahoo.com>
Subject: Re: [RTTY] Crystal filter width preferences for RTTY contesting
>
> On Aug 26, 2009, at 11:08 PM, Jeff Blaine AC0C wrote:
>
>> I think this helps
>> to explain why there is quite a bit of satisfaction with the K3
>> using this
>> filter on RTTY.
>
> Jeff, bear in mind when you select filters the following two points:
>
> 1) optimal receive filtering has nothing to do with FCC 47 Part 2.202
> definition of occupied bandwidth (which is over 400 Hz in the case of
> steam RTTY).
> 2) keying sidebands from nearby stations can never be removed with a
> receiving filter (comments below).
>
> To see what keying sidebands of an RTTY signals are like, you can take
> a look at (you can see that this topic rears its head every couple of
> years :-):
>
> http://homepage.mac.com/chen/Technical/FSK/sidebands.html
>
> In the above, I had looked at FSK (where you switch between mark and
> phase with no regards of any continuity), phase continuous FSK (where
> the transition between mark and space are continuous, but is not slope
> continuous -- this is why FSK (vs AFSK) sidebands are wider than
> neccessary), an AFSK signal that is well filtered and still provides
> the receiving matched filter with something that is still pretty
> decent, and finally an AFSK signal that is too narrow (this is the
> same case as a receive filter that is too narrow).
>
> Now, when you pass all that through a practical transmitter, the
> behavior is not as obvious, but still visible. I took some samples
> last night of the FT-1000MP's transmitter. The FT-1000MP feeds a
> dummy load through a directional coupler, and I used transformer
> coupling from the directional coupler (to minimize any ground loops)
> into the antenna input of a K3, from which I recorded the following
> two plots.
>
> The first plot is that of the FT-1000MP running in FSK mode.
>
> http://homepage.mac.com/chen/Technical/FSK/foxFSK.png
>
> The data is a bunch of repeated "The quick brown fox jumps over the
> lazy dog" with lots of spectral averaging (each FFT bin is
> individually exponentially filtered).
>
> The second is the FT-1000MP running in AFSK mode (no ALC, naturally)
> with audio from cocoaModem that uses a moderately tight Blackman-
> Harris windowed filter.
>
> http://homepage.mac.com/chen/Technical/FSK/foxAFSK.png
>
> Notice that the transmit phase noise predominates in the spectrum
> beyond 100 Hz away from the FSK carriers. Even with that, you can
> still see that the AFSK signal is a bit narrower (look at the 600 Hz
> region and the 1600 Hz region and you can tell that the FSK signal is
> wider than the AFSK signal, even though both are using 170 Hz shift.
> The difference would be more obvious with a rig that has better
> transmit phase noise.
>
> In any case, take a look at both FSK or AFSK signals 200 Hz away from
> the FSK carriers. They are only about 35 dB down from the carriers
> themselves. I.e., an S9+35 dB signal will clobber an S9 signal even
> if it is 200 Hz away. No filter is going to fix this problem. I.e.,
> there is no need to be so anal about filter bandwidths, and in any
> case, let your software demodulator do the heavy lifting in the
> filtering department. The crystal filter only needs to provide a
> protection against clipping the sound card.
>
> [Note that you can also "just" see the difference of the keying rate
> differences between the two plots. The FSK plot is keyed at 45.00
> baud (MicroHAM microKeyer II's FSK generator) and the AFSK is keyed at
> 45.45 baud.]
>
> From the last picture in the html page, you can see what a filter
> that is too narrow would do to a matched filter. In the presence of
> noise, noise would also go down by a little with a reduced bandwidth,
> but not by as much as the peak of the matched filter goes down by
> (this should not be a surprise, all the textbooks on matched filtering
> tells you that :-). That last picture has a filter cutoff just beyond
> the third harmonic of the keying signal, i.e., 22.725*3 Hz; in other
> words, a perfectly tuned RTTY signal inside a 306 Hz brickwall filter.
>
> Conclusion: if there is a strong RTTY station close by, a 306 Hz
> brickwall filter will not be able to get rid of of QRM if it is more
> than 35 dB louder than the signal you are trying to copy, and in the
> meantime, you are losing a bit in the ability to copy a weak signal
> because you are cutting off too much of the keying sidebands.
>
> Fortunately, even Inrad 250 Hz crystal filters don't really cut away
> much at 300 Hz.
>
> You might want to use the captured spectra (the PNG files) to
> determine your personal rule of thumb of how far you want to be away
> from a nearby loud station during a contest, both for your sanity and
> the sanity of the nearby station (if he is loud at your QTH, you will
> likely be equally loud at his QTH :-).
>
> 73
> Chen, W7AY
>
>
> _______________________________________________
> RTTY mailing list
> RTTY@contesting.com
> http://lists.contesting.com/mailman/listinfo/rtty
>
_______________________________________________
RTTY mailing list
RTTY@contesting.com
http://lists.contesting.com/mailman/listinfo/rtty
|
