QMF benefits/tradeoffs

"Marc" <marc.saab@mail.mcgill.ca> wrote in message
news:1123793788.973405.134150@g49g2000cwa.googlegroups.com...
> Hi Bhaskar,
>
> Thanks for the detailed response.
>
> The issue is that I am trying to decide if I should emulate the design
> (due to all these wonderful benefits) or if I should simply criticize
> it (due to *some* detriments).   Can you perhaps comment on some of the
> tradeoffs involved in such an implementation, such as increased
> computation time, complexity, ripple, estimation noise, or whatever
> else might be sacrificed for the aforementioned benefits.

I'm not sure what to comment on.
Are you trying to build a SSB modulator? (based on this block diagram). If
so, I don't know much about SSB modulators and various possible
architectures to comment on pros and cons.
If you are trying to build band pass filters for use in a (unknown) design
and are considering the method shown in your reference to implement BP
filters, then we can perhaps talk about trade-offs.
Things like computation time and complexity are dependent on how you want to
implement 'it'. For example, you could be looking at a pure HW solution,
pure SW or combination of both.

More information would help in making more comments.
What are you trying to do? I think we can give you good references based on
the answer to that.

Cheers
Bhaskar

> Since I
> don't know much about this sort of implementation, I decided to rely on
> you guys as my source of information.  I was unable to find any other
> useful information or reference (most likely due to my lack of a clear
> definition of the implementation).
>
> Thanks.
>
> Marc
>

Hi Bhaskar,

Sorry to be vague.  As you suggested, the application is simply a
digital bandpass filter for use in a software application.  It's a
real-time medical data analysis program that displays, records, and
analyzes various incoming biosignals.  As it is, we use all kinds of
different filters in the software and even provide optional filter
design for the user.  What we include so far are the standard filter
types (FIR, IIR, Butterworth, Chebychev, etc...) but it has been
suggested that the benefits of this QF implementation are so wonderful
that we must include it as well.  What I'd like to be able to do is
silence the excitement that arises whenever simplicity is replaced with
complexity for the sole purpose of answering to, for lack of a better
term, "hype".

While these benefits seem to be accurate, I'm sure the tradeoffs are
not worth the effort.  I just wanted to be able to quote some specific
reasons and I couldn't find anything anywhere about this
implementation.  I even contacted Professor Vaidyanathan (author of
"Multirate Systems and Filter Banks") and he said he couldn't suggest a
good reference.

Thanks Bhaskar, I appreciate your input.

Marc

P.S.  Good low frequency response is critical!  It can be as low as
below 5 Hz.  We don't necessarily need to use the QF implementation for
that, but if it adds value I'd love to hear about it.  Thanks!

Marc wrote:
> Hi Bhaskar,
> 
> Sorry to be vague.  As you suggested, the application is simply a
> digital bandpass filter for use in a software application.  It's a
> real-time medical data analysis program that displays, records, and
> analyzes various incoming biosignals.  As it is, we use all kinds of
> different filters in the software and even provide optional filter
> design for the user.  What we include so far are the standard filter
> types (FIR, IIR, Butterworth, Chebychev, etc...) but it has been
> suggested that the benefits of this QF implementation are so wonderful
> that we must include it as well.  What I'd like to be able to do is
> silence the excitement that arises whenever simplicity is replaced with
> complexity for the sole purpose of answering to, for lack of a better
> term, "hype".
> 
> While these benefits seem to be accurate, I'm sure the tradeoffs are
> not worth the effort.  I just wanted to be able to quote some specific
> reasons and I couldn't find anything anywhere about this
> implementation.  I even contacted Professor Vaidyanathan (author of
> "Multirate Systems and Filter Banks") and he said he couldn't suggest a
> good reference.
> 
> Thanks Bhaskar, I appreciate your input.
> 
> Marc
> 
> P.S.  Good low frequency response is critical!  It can be as low as
> below 5 Hz.  We don't necessarily need to use the QF implementation for
> that, but if it adds value I'd love to hear about it.  Thanks!

What it boils down to is that some frequency bands are simpler to work 
with, and that low-pass filters have fewer elements than band-pass 
filters of the same selectivity. The simplicity of a particular regime 
will usually be far outweighed by the complexity needed to shift the 
signal's frequency "there and back". The method is likely to be 
attractive only when the the shift is part of the desired result.

Even if your time is free, there's no gain from driving ten miles out of 
your way to get to a filling station where fuel is 2 cents cheaper.

The stuff about envelope detection without delay is a crock. The delay 
is in getting I and Q. It's like the bank that gives you an instant loan 
after spending a week reviewing your background.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

"Marc" <marc.saab@mail.mcgill.ca> wrote in message
news:1123857658.899080.274160@g44g2000cwa.googlegroups.com...
> Hi Bhaskar,
>
> Sorry to be vague.  As you suggested, the application is simply a
> digital bandpass filter for use in a software application.  It's a
> real-time medical data analysis program that displays, records, and
> analyzes various incoming biosignals.  As it is, we use all kinds of
> different filters in the software and even provide optional filter
> design for the user.  What we include so far are the standard filter
> types (FIR, IIR, Butterworth, Chebychev, etc...) but it has been
> suggested that the benefits of this QF implementation are so wonderful
> that we must include it as well.  What I'd like to be able to do is
> silence the excitement that arises whenever simplicity is replaced with
> complexity for the sole purpose of answering to, for lack of a better
> term, "hype".

I think it would help to know what you have in place right now - how do you
currently implement your filtering?
With this as a basis, I'm sure several of us can comment on what this new
technique (atleast from your perspective as well as several other
colleagues?) will buy you.
This method could very well turn out to be 'hype' for what you are
doing...on the other hand, it might improve certain things. Hard to say
without having something as a basis.

Cheers
Bhaskar


> While these benefits seem to be accurate, I'm sure the tradeoffs are
> not worth the effort.  I just wanted to be able to quote some specific
> reasons and I couldn't find anything anywhere about this
> implementation.  I even contacted Professor Vaidyanathan (author of
> "Multirate Systems and Filter Banks") and he said he couldn't suggest a
> good reference.
>
> Thanks Bhaskar, I appreciate your input.
>
> Marc
>
> P.S.  Good low frequency response is critical!  It can be as low as
> below 5 Hz.  We don't necessarily need to use the QF implementation for
> that, but if it adds value I'd love to hear about it.  Thanks!

Good stuff.  That's what I was thinking, that it wouldn't be worth the
gain.  Thanks Jerry.

We have streaming data sampled at either 256 (or 2K) Hz, transmitted in
pakets of 16 (or 128) samples from an A/D to the software via an API.
There are two main threads in the software:  1) data collection and
graphic display and 2) algorithm processing.  The software buffers the
data (up to 10 seconds) but normally processes data 16 times per
second, so if there are no logjams, the data is streaming in
"real-time".  Based on a user selection of epoch size (1 or 2 seconds,
for example), the compuation function (in this case a BPF) buffers the
data in its own memory and outputs the result as soon as it is done.
The display in the software will update 16 times per second as new data
is available.

The way we currently implement the filtering is to design (calculate
coefficients base don user input of filter type) at initialization and
to process using a simple difference equation to run the sampled data
through the filter taps (two nested loops, one to process the
numerator, one for the denominator).   Sometimes we use that, other
times we use a filtering function in the National Instruments CniMath
library (like ButterworthLowPass for example).  

Marc

Marc,

What are the bandpass bandwidths used at each sample rate? If there is
a range, then what are the limits?

Do you have any REAL current requirement to reduce computations?

What is the throughput delay allowed, or is this basically not a
problem so far?

In your application does the user (Doctors?) change the design of these
filters during use?

Dirk


Marc wrote:
> Hi Bhaskar,
>
> Sorry to be vague.  As you suggested, the application is simply a
> digital bandpass filter for use in a software application.  It's a
> real-time medical data analysis program that displays, records, and
> analyzes various incoming biosignals.  As it is, we use all kinds of
> different filters in the software and even provide optional filter
> design for the user.  What we include so far are the standard filter
> types (FIR, IIR, Butterworth, Chebychev, etc...) but it has been
> suggested that the benefits of this QF implementation are so wonderful
> that we must include it as well.  What I'd like to be able to do is
> silence the excitement that arises whenever simplicity is replaced with
> complexity for the sole purpose of answering to, for lack of a better
> term, "hype".
>
> While these benefits seem to be accurate, I'm sure the tradeoffs are
> not worth the effort.  I just wanted to be able to quote some specific
> reasons and I couldn't find anything anywhere about this
> implementation.  I even contacted Professor Vaidyanathan (author of
> "Multirate Systems and Filter Banks") and he said he couldn't suggest a
> good reference.
>
> Thanks Bhaskar, I appreciate your input.
>
> Marc
>
> P.S.  Good low frequency response is critical!  It can be as low as
> below 5 Hz.  We don't necessarily need to use the QF implementation for
> that, but if it adds value I'd love to hear about it.  Thanks!

The hardware limited bandwidth is 0.2 - 128 Hz (at 256 Hz) and 0.2 -
1024 Hz (at 2K Hz).   The default software setting is to have no
digital filter active.  The filter specs are determined by the user if
they decide to use digital filtering.  We provide basic filter types
for LP, HP, BP and notch such as butterworth, chebychev, eliptical,
etc...

No REAL requirements for computation reduction and no throughput delay
issues for now.  Not sure that would be the case if we start
implementing more complex computations.  Sorry, I'm not sure exactly
what the cieling is on the time available.      

Thanks Dirk.

Marc

"Marc" <marc.saab@mail.mcgill.ca> wrote in message
news:1124119076.328218.131110@o13g2000cwo.googlegroups.com...
> The hardware limited bandwidth is 0.2 - 128 Hz (at 256 Hz) and 0.2 -
> 1024 Hz (at 2K Hz).   The default software setting is to have no
> digital filter active.  The filter specs are determined by the user if
> they decide to use digital filtering.  We provide basic filter types
> for LP, HP, BP and notch such as butterworth, chebychev, eliptical,
> etc...
>
> No REAL requirements for computation reduction and no throughput delay
> issues for now.  Not sure that would be the case if we start
> implementing more complex computations.  Sorry, I'm not sure exactly
> what the cieling is on the time available.

Seems like the biggest 'feature' of the block diagram ( I refuse to call
them Quadrature filters) that you referenced is the fact that your BP
filters will have very similar response to your LP filters (I got the
impression this is important in your application).
If you are currently implementing BP digital filters using some other
method, then it might be useful to use one of the techniques that someone (I
think Dirk) pointed out earlier. It assumes your data path consists of I,Q
components. So you can take a LP filter and make it a BP filter by
multiplying the coeffs of the filter with e^jwt where w is the center freq
of the BP filter. So now you a BP filter with exactly the same
behavior/response as your LP filter.

In a way, this is doing pretty much exactly what the block diagram showed
you but instead of moving the signal down to baseband, it is moving the LP
filter up to your carrier or center frequency. It doesn't add any more
compuations to your filter processing but adds a little more processing when
computing the filter coeffs.

Cheers
Bhaskar

>
> Thanks Dirk.
>
> Marc
>

Thanks Bhaskar.

What about the overall tradeoffs between this sort of implementation
(either the one in the block diagram or the one Bhaskar mentions just
above) and a simple difference equation solution?  Is there actually a
benefit in using the I and Q components as far as computation is
concerned.  I'm trying to get an idea of the cost of using this
implementation.   Can anyone comment on Jerry's reply: "Even if your
time is free, there's no gain from driving ten miles out of your way to
get to a filling station where fuel is 2 cents cheaper." ?

Thanks. 
Marc