[hpsdr] Mercury: Selection of frequency Segments

[Ahti Aintila]

Hi Bob,

Some comments:

2009/1/7 Bob McGwier <rwmcgwier at gmail.com>:
> ***** High Performance Software Defined Radio Discussion List *****
>
> Alex takes 7 independent bands each N kHz wide where N is (say) 200 kHz
> wide.
>
> With polyphase filter banks, one on each of the of the 7 independent bands,
> we construct M parallel receivers in software.  If we make these 500 Hz wide
> channels,  then we have  7 * 200 kHz / .5 kHz = 2800 channels!!!!!!!!  I
> assure you the computation to process each of the 2800 channels is only
> slightly more expensive than the 7 200 kHz channels and then only because of
> the need to do fine tuning or recombining of adjacent 500 Hz channels to
> make a 4 kHz channel (say).  The critical pieces needed to do this are
> efficient structures for the channel filters in the polyphase filter banks.
>
> Believe it or not,  I am about to lead us back to IIR filters.  I do this
> because we need good filter shape with less computation and less latency.
> Now, I had my eyes completely opened by fred harris this past summer.  I do
> NOT need to sacrifice "good enough" linear phase to accomplish this AND I
> get to cut latency by about 2/3's at the same time.  I take an IIR low pass
> filter, follow it by an appropriately designed all pass filter and this
> becomes the channel filter.  Another approach would be, if we really do need
> large FIR filters,  fred harris and I proved new Nobel identities.  You can
> do the polyphase filter bank where the channel filters are accomplished in
> the frequency domain.  The new Nobel identity, which should have been
> obvious but apparently has not been, is that you can do the IFFT on the
> other side of the "Butler matrix" or polyphase synthesis/analysis DFT to
> return the channels to the time domain.
>
> This is a tremendous amount of work to put into code and people are getting
> impatient for me to finish so I am pushing like mad as soon as I return from
> vacation (PR is nice!!).

Take your time. We'll wait, impatiently though!
>
> We are entering brave new world but let me continue to comment on other
> notes:
>
> I disagree with Ahti on the QSD.

I am happy that you disagree and work for that!

> My recent work shows that with the QSD,
> and suitable modifications we can achieve un heard of IMD DR3,  BDR's that
> would make even Elecraft owners happy,  <<BUT>> all of this is completely
> contingent on getting suitable DDS's with low enough phase noise that our
> measurements of receiver dynamics are NOT phase noise limited.
>
> My perfect system?  Several QSD based receivers running in parallel with
> QS1R/Mercury style receiver and Penelope style DUC.  The Penelope has
> sufficient dynamic range and performance to do anything I can think of.  I
> can still outperform any A/D based receiver with an appropriately designed
> QSD based receiver.  I have tested my wideband image rejection algorithm at
> Flex and it reduces the image across the band to the noise floor and no loss
> in MDS that I can detect.  The "see I can do it" implementation is in DttSP
> on cgran and in the test iqtest branch for Flex.
I really miss this wideband image rejection software for the receiver
as well as the transmitter!
>
>
> SO with a finally good DDS with really good phase noise and low spurious
> emission,  no shortcuts taken on components in the QSD (good comparators
> rated well beyond the frequency range of interest),  the balanced design QSD
> will still produce the better single channel receiver.
Agreed!
>
> That said,  there is a a serious limitation to the QSD.  I just cannot see
> it listening to 80, 40, 20, part of 15, part of 10, and ALL at the same
> time.  THAT we can get with QS1R and Mercury.  I cannot wait.
Ditto!

Thank you Bob and 73,

Ahti OH2RZ

> _______________________________________________
> HPSDR Discussion List
> To post msg: hpsdr at hpsdr.org
> Subscription help: http://lists.hpsdr.org/listinfo.cgi/hpsdr-hpsdr.org
> HPSDR web page: http://hpsdr.org
> Archives: http://lists.hpsdr.org/pipermail/hpsdr-hpsdr.org/
>

 1231355918.0