Hi Jan,
thanks for the feedback!
PFBs are a topic I discussed with my mentors and we decided to not
use them because of the following reasons. When using PFBs, there
is a trade-off between band resolution and calculation effort (few
filters lead to low number of possible frequency bands, many
filters may have a high cpu usage). Since the band separation is
not dependend on the input siganls, I think I can have a more
efficient solution with „customized“ FIR filters for each signal.
The second reason is the implementation effort that needs to be
done (not only for the PFB but also for recombining the bands again
to reconstruct the signals) is quite higher than for using FIR
filters. We were afraid that time would be too short for
implementing this (since all this should work until the midterms in
four weeks).
We assume to have a moderate number of signals in the input
spectrum (let’s say less than 5) and I think the FIR filter
approach is more attractive here. But of course cpu usage is a
topic which I have to deal with. Therefore I plan to use a
lookup-table with precalculated taps for different bandwidths and
steepnesses. Also, steepness (or something similiar) should be a
parameter of the block, so the user can can somehow control the cpu
usage with that.
I hope that answers your question!
Regards,
Sebastian
Am 28. Mai 2016 um 12:45:49, Jan Krämer
(address@hidden)
schrieb:
Hey Sebastian,
great work in your first week. Looking pretty
good.
One question though. At the end you propose to seperate the
signals with a filterbank of xlating FIRs. Is there a use case or a
way to do that with a polyphase filterbank? Cause multiple FIRs are
going to become a major burden for the CPU if their number rises,
especially if the filterorder gets pretty high e.g. for narrowband
signals.
Anyway keep up the good work.
Cheers,
Jan