> The only reason I am continuing to beat the dead horse is
> that the filter, when pressed in double-duty CW service as
> well as RTTY service, a wider number than necessary for RTTY
> may cause an a drop in user happiness - if the bandwidth were
> allowed to grow to wide.
This is why the bandwidth of available filters seems to settle
into the 350 Hz (Icom FL232) to 400 Hz (INRAD) range. While
some might prefer a slightly wider bandwidth for normal CW,
the 350 to 400 Hz range is probably optimal for RTTY and is not
overly tight for most CW operation.
Excluding additional processing (e.g., DSP filters), critical
CW operation may want a filter as tight as 125 Hz (INRAD) to
200 Hz (Elecraft) but those bandwidths are certainly unusable
for RTTY.
To bring this full circle, I doubt that any IF filter will
provide significant improvement for the FT-2000 - it has
too many other problems ahead of a potential filter insertion
point.
73,
... Joe, W4TV
> -----Original Message-----
> From: Jeff Blaine AC0C [mailto:keepwalking188@yahoo.com]
> Sent: Thursday, August 27, 2009 6:56 PM
> To: lists@subich.com
> Cc: 'RTTY Reflector'
> Subject: Re: [RTTY] Crystal filter width preferences for RTTY
> contesting
>
>
> Joe,
>
> Thanks for catching my error. The wider bandwidth improves
> the SNR to an
> extent. I would think this is an asymptotic curve to a point...
>
> You make good points about the practical nature of this discussion.
> However, for the purposes of the conversation, we are setting
> aside the
> availability of further processing (be it DSP powered bandwidth, or
> something more exotic in the rig or in the application itself).
>
> The filter under discussion would fall in the 2nd IF and we
> are assuming the
> 1st IF chain, through the 2nd mixer and to this point has
> provided a nice
> clean although somewhat wide (3khz approx) signal up to this
> point. The
> comparison of the 2nd IF in the 1000MP - and also assuming no
> further DSP is
> available - would be a suitable way to envision the question.
>
> The unanswered question is the anticipated benefit of opening
> up the filter
> width further, to the 400 or 500 hz level. It's a way of
> saying "all other
> things being equal, what is the theoretical difference of bw
> A vs. bw B).
> And Chen's explanation is the only comment that I have seen
> that puts actual
> numbers to the question. Which is really very nice to see.
> It takes the
> various comments of the K3/250/Inrad filter as working fine
> and helps to
> explain why that in fact is the case.
>
> The only reason I am continuing to beat the dead horse is
> that the filter,
> when pressed in double-duty CW service as well as RTTY
> service, a wider
> number than necessary for RTTY may cause an a drop in user
> happiness - if
> the bandwidth were allowed to grow to wide.
>
> 73/jeff/ac0c
>
>
> --------------------------------------------------
> From: "Joe Subich, W4TV" <lists@subich.com>
> Sent: Thursday, August 27, 2009 5:07 PM
> To: "'Jeff Blaine AC0C'" <keepwalking188@yahoo.com>
> Cc: "'RTTY Reflector'" <rtty@contesting.com>
> Subject: RE: [RTTY] Crystal filter width preferences for RTTY
> contesting
>
> >
> > Jeff,
> >
> > I don't believe you can consider the IF filter ("roofing
> filter") to
> > be the only source of selectivity in any modern RTTY
> environment. Even
> > the old "loading coil" TUs included some degree of additional
> > selectivity in their channel filters. Since most modern
> RTTY is done
> > with sound cards in one form or another, the software
> implements some
> > rather effective DSP filtering.
> >
> > With that in mind, there is little to be lost with a wider
> "roofing"
> > filter as long as the increased bandwidth does not cause the sound-
> > card to saturate (additional signals), allow the IF chain
> to overload
> > (generating IMD), or allow the adjacent channel signals to
> "pump" the
> > receive AGC.
> >
> >> What I am wondering is if we can distill the argument to
> something as
> >> simple as this:
> >>
> >> Width SNR impact
> >> ------- ---------------
> >> 306 hz 0 (baseline)
> >> 370 hz -1.5
> >> 400 hz ?
> >> 500 hz ?
> >
> > I think you have the 306 and 370 Hz cases reversed ... 306 Hz (3rd
> > harmonic of the 22 ms bit rate) is 1.5 dB inferior to the
> 370 Hz case.
> > Greater widths are difficult to categorize as the impact on S/N is
> > only related to the AGC/saturation/IMD issues which are highly
> > correlated to the quality of the receiver and nature of the
> adjacent
> > signals.
> >
> > This would continue to point to an "optimum solution" using
> "roofing"
> > filter between 370 Hz (the so called "250Hz" Inrad K3 filter) and a
> > true 400 Hz filter.
> >
> > 73,
> >
> > ... Joe, W4TV
> >
> >
> >
> >> -----Original Message-----
> >> From: rtty-bounces@contesting.com
> >> [mailto:rtty-bounces@contesting.com] On Behalf Of Jeff Blaine AC0C
> >> Sent: Thursday, August 27, 2009 4:24 PM
> >> To: Kok Chen
> >> Cc: RTTY Reflector
> >> Subject: Re: [RTTY] Crystal filter width preferences for RTTY
> >> contesting
> >>
> >>
> >> Chen,
> >>
> >> I met my Chinese wife when I lived in China and wanted to learn
> >> Chinese. So from 3rd language standpoint, I consider your
> English to
> >> be really excellent. And I also 100% understand your meaning. As
> >> non-English writers, it's quite difficult to notice your
> writing is
> >> of 3rd language
> >> standpoint. The fault of understanding is mine.
> >>
> >> So let me rephrase the question then because I am hoping
> we can put a
> >> number value to the trade-off between width and SNR...
> For the case
> >> of our discussion, I am assuming there is NO software optimization
> >> capability - no
> >> DSP - just a "dumb demodulator" who's performance is better
> >> or worse based
> >> on the quality of the signal fed to it. I do agree with you
> >> in the "anal"
> >> case of the practical world, but here we can consider the
> >> theoritical ideal
> >> and hopefully I am not driving you crazy with these many
> follow-ups.
> >>
> >> 1. Let's assume the same single filter is to serve selectivity
> >> purposes in a dual-duty mode format, meaning we want this
> filter to
> >> work for our RTTY
> >> **AND** CW mode for the contest environment.
> >>
> >> 2. Allowing for the variable of keying sideband widths in
> either mode
> >> - we can say - generally - a somewhat narrower filter than 306 hz
> >> is better for
> >> the CW op - and a somewhat wider RTTY filter is better for
> >> the RTTY op.
> >>
> >> 3. Let's also assume that 306 hz is the absolute minimum
> acceptable
> >> width for the RTTY application. And so our filter needs
> to be 306 or
> >> wider.
> >>
> >> 4. Finally, let's say that this is a single signal case -
> meaning no
> >> other keying sidebands are involved - only the pure signal of our
> >> target and
> >> desired RTTY signal.
> >>
> >> In that context. Can we estimate what the relative SNR
> improvement
> >> is by expanding the passband to a little bit wider value? Let me
> >> suggest, based
> >> on the popular comment, that the alternative widths are 400
> >> hz and 500 hz?
> >>
> >> I see from the examples on the web site, assuming I am
> readying the
> >> charts properly, the difference between a filter of 370 hz (100 hz
> >> per side) width
> >> vs. the 306 hz (3rd harmonic cut point) is around 1.5 db.
> >>
> >> What I am wondering is if we can distill the argument to
> something as
> >> simple as this:
> >>
> >> Width SNR impact
> >> ------- ---------------
> >> 306 hz 0 (baseline)
> >> 370 hz -1.5
> >> 400 hz ?
> >> 500 hz ?
> >>
> >> Does that make sense?
> >>
> >> 73/jeff/ac0c
> >>
> >>
> >> --------------------------------------------------
> >> From: "Kok Chen" <chen@mac.com>
> >> Sent: Thursday, August 27, 2009 2:49 PM
> >> To: "Jeff Blaine AC0C" <keepwalking188@yahoo.com>
> >> Cc: "RTTY Reflector" <rtty@contesting.com>
> >> Subject: Re: [RTTY] Crystal filter width preferences for RTTY
> >> contesting
> >>
> >> >
> >> > On Aug 27, 2009, at 11:31 AM, Jeff Blaine AC0C wrote:
> >> >
> >> >> 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.
> >> >
> >> > I think that you may have misunderstood. I apologize
> that I write
> >> > horribly; English is my third language, even though I
> >> should not be using
> >> > it as an excuse considering the fact that I have been in
> >> this country for
> >> > longer than the majority of people who were born here, and
> >> have all but
> >> > forgotten my first two languages! :-).
> >> >
> >> > The point of those plots is to show that a narrower
> >> receiver bandwidth
> >> > will NOT help you suppress the keying sidebands from a
> >> close by strong
> >> > FSK transmitter. Once the strong sidebands encroaches on
> >> the weak signal
> >> > you are trying to copy, it is too late to do anything. (Similar
> >> > situation to SSB signals that are too close to one another,
> >> no amount of
> >> > receiving filter will get rid of what people complain as
> >> "splatter.") A
> >> > narrower I.F. filter will not help in that case, and yet
> >> the narrower
> >> > I.F. filter will hurt when it comes to copying weak
> >> signals when there is
> >> > no QRM.
> >> >
> >> > My personal methodology: use a relatively wide I.F. filter --
> >> > something that is only narrow enough to (1) keep my
> sound card from
> >> saturating and
> >> > (2) keep the AGC from pumping due to very strong close
> in signals
> >> > (something that has not been brought up yet in this
> >> thread). Then find
> >> > some software that lets me change the demodulation
> >> bandwidth to match the
> >> > situation.
> >> >
> >> > I do not tell everyone else that they must, or even should
> >> do the same
> >> > thing. But I do recommend that they do study the
> problem carefully
> >> > before choosing their own solution.
> >> >
> >> > The advice I usually give is to never ever, ever, ever,
> >> ever allow the
> >> > sound card to saturate, not even for a millisecond, while
> >> making sure
> >> > that the weak signal is a good 10 or 20 dB above the sound
> >> card's noise
> >> > floor.
> >> >
> >> > 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
|