# Filter bank and massive “DDD” messages

**URL:** <https://www.ruby-forum.com/t/filter-bank-and-massive-ddd-messages/242429>\
**Category:** GNU Radio\
**Created:** [June 23, 2015, 6:18pm UTC](https://www.ruby-forum.com/t/filter-bank-and-massive-ddd-messages/242429 "2015-06-23T18:18:32Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![musicdenotation](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/ea666f/32.png) [@musicdenotation](https://www.ruby-forum.com/u/musicdenotation)\
**Post date:** [June 23, 2015, 6:18pm UTC](https://www.ruby-forum.com/t/filter-bank-and-massive-ddd-messages/242429/1 "2015-06-23T18:18:32Z")

</div>

Hi,

I’m trying to filter 14 frequency bands (channels), which are dispersing  
within spectrum of 25 MHz (from 2 MHz - 27 MHz to be more specific) and  
each band has a different bandwidth. For example: 1th channel with 198  
KHz  
(bandwidth), 2nd channel with 360 kHz, 3. channel with 650 kHz, and so  
on.

Until now, I have tried 3 scenarios on GRC in order to get these 14  
channels and verify that the first step of my project (filtering) is  
working. For testing, I used just 4 of the 14 channels to see its  
functionality and CPU requirement.

General configuration:

USRP N200 ----------- channelizer — [ch1] -----GUI FFT Sink

```
                                            ----[ch2 - ch4] ---- 

```

Null  
Sink

USRP setup -\> samp\_rate= 25 MHz, and Center Freq = 14,2 MHz.

Scenario 1: channelizer = 4 band pass filters.

Scenario 2: channelizer = 4 Xlating FIR filters.

Scenario 3: channelizer = Polyphase channelizer, 5 equal channels of 5  
MHz.

For the 3 configurations I got massive “DDDDD…” at the console output.  
Moreover:

Scenario 1: CPU 100% and stop the application.

Scenario 2: CPU between 75 % and 95 %.

Scenario 3: CPU between 53 % and 95 %

Therefore, I really appreciate if you could give me some tips to avoid  
this  
massive “DDD” messages or alternatives to optimize the resource  
consumption  
for the filter bank, due to the results showed that the band pass filter  
(scenario 1) will not be a good option for me, or maybe I did something  
wrong.

In the attached files you will find the 3 different GRC configurations.

Thanks in advance,

Luis Grajales

---

<div class="post-metadata">

**Author:** ![Luis\_Grajales](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ecd19e/32.png) [@Luis\_Grajales](https://www.ruby-forum.com/u/Luis_Grajales)\
**Post date:** [June 23, 2015, 6:22pm UTC](https://www.ruby-forum.com/t/filter-bank-and-massive-ddd-messages/242429/2 "2015-06-23T18:22:02Z")

</div>

Luis,

can you please confirm/deny that streaming e.g. into a null sink works?

Thanks,  
Martin

---

<div class="post-metadata">

**Author:** ![Luis\_Grajales](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ecd19e/32.png) [@Luis\_Grajales](https://www.ruby-forum.com/u/Luis_Grajales)\
**Post date:** [June 24, 2015, 8:36am UTC](https://www.ruby-forum.com/t/filter-bank-and-massive-ddd-messages/242429/3 "2015-06-24T08:36:10Z")

</div>

Hi Martin,

Thank you for your message.

I was looking into the null sink blocks documentation and I couldn’t  
find  
any method or function where I can get an intermediate value into this  
block. Then, I just verified data at the input of this block, which is  
the  
confirmation of the streaming at the output of each channel. For this  
case  
I used a file sink block.

Please let me know if I need to do something else, or what is your  
general  
idea of the streaming verification into a null sink blocks.

Thanks again,

Luis

2015-06-23 18:20 GMT+02:00 Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

---

<div class="post-metadata">

**Author:** ![Luis\_Grajales](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ecd19e/32.png) [@Luis\_Grajales](https://www.ruby-forum.com/u/Luis_Grajales)\
**Post date:** [June 24, 2015, 9:39am UTC](https://www.ruby-forum.com/t/filter-bank-and-massive-ddd-messages/242429/4 "2015-06-24T09:39:51Z")

</div>

Hi Luis,

I guess the idea was to look whether your CPU was really your  
bottleneck; filter banks are one of the most CPU-hungry signal  
processing steps one can think of, and hence, your "D"ropped packets  
could be caused by that. If I understand correctly, with the null sink  
(and/or the file\_sink) you don’t get that behaviour?  
If that’s the case, your PC can’t keep up to both the calculations  
needed for the filters and receiving the data from your USRP.

I think your polyphase filter bank approach has the brightest future  
(basically because I think polyphase filter banks are cool, and because  
they are really quite efficient), but your filter parameters are  
frightening: A transition bandwidth of 10kHz at a sampling rate of 25MHz  
is 0.04% transition width, which leads to a filter of more than 8000  
taps. Relax that transition width!  
I’d say: start gr\_filter\_design, and design a filter there, playing  
around with the parameters until things look better.

Generally, you don’t even closely seem to need the full 25MS/s you get  
from the USRP in your flow graphs, but you select different subbands in  
each flow graph (and in your original mail). What is the real span you  
need from lower edge of your lowest channel to upper edge of your  
highest channel? You should let the USRP do as much decimation for you  
as possible. It’s its job!

Best regards,  
Marcus

---

<div class="post-metadata">

**Author:** ![Luis\_Grajales](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ecd19e/32.png) [@Luis\_Grajales](https://www.ruby-forum.com/u/Luis_Grajales)\
**Post date:** [June 24, 2015, 7:42pm UTC](https://www.ruby-forum.com/t/filter-bank-and-massive-ddd-messages/242429/5 "2015-06-24T19:42:49Z")

</div>

Hi Marcus,

Thank you! I wrote the answers according to your last email.

\<1\>\<I guess the idea was…If that’s the case, your PC can’t keep up  
to  
both the calculations needed for the filters and receiving the data from  
your USRP.\>

you are right. For this reason I checked my CPU behavior by each option  
(scenario 1, 2, and 3) to do my filter bank selection. However, I had a  
doubt between USRP and my PC.

I know that there is a direct relationship between BW to be processing  
and  
consumed PC resources, but I’m wondering, how will be this relationship  
between the whole set (USRP + GNU Radio), I mean in order to sect an  
appropriate PC hardware requirements. (sorry if it is an obvious  
question) .

\<2\>\<I think your polyphase filter bank approach …I’d say: start  
gr\_filter\_design, and design a filter there, playing around with the  
parameters until things look better.\>

I think the same, even though at the end I will need to put many  
channels  
to the null sink because this polyphase filter bank has equal channel  
bandwidths and my subbands have not equal bandwidth but I think that FFT  
will be a perfect solution after the filtering process.

I know that there is a work related with unequal channel bandwidths  
(Fred  
Harris • Elettra Venosa • Xiaofei Chen) but I couldn’t find some  
examples  
about it or projects related with GNU Radio.

By the way, thank you so much for your comment. I’m gonna check the  
gr\_filter\_design tool and playing around the parameters.

\<3\>\<Generally, you don’t even closely seem to need the full 25MS/s  
…\>

Exactly, I don’t need to process the full 25 MHz of bandwidth but the  
problem is that my different subbands are into this spectrum. For  
example:

Subband 1: 2,3 MHz to 2,510 MHz (BW: 210 KHz)

* * *

Subband 14: 25,600 MHz to 26,100 MHz (BW: 490 Khz)

The lowest bandwidth is 120 KHz and the biggest is 800 Khz. In that  
case,  
I was doing some approximation and channels of 200 Khz will be ok, that  
means, 100MHz/(500) = 200 Khz and I will have 125 channels with the  
decimation factor 500. Please correct me if I am wrong.

If I can do that, it will be an excellent option as well.

Now, the question is: multiplex USRP those 125 channel and will be the  
new  
rate 200 Ksps?

Thank you so much for all your help,

Luis

2015-06-24 9:38 GMT+02:00 Marcus Müller [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

---

<div class="post-metadata">

**Author:** ![Luis\_Grajales](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ecd19e/32.png) [@Luis\_Grajales](https://www.ruby-forum.com/u/Luis_Grajales)\
**Post date:** [June 24, 2015, 7:58pm UTC](https://www.ruby-forum.com/t/filter-bank-and-massive-ddd-messages/242429/6 "2015-06-24T19:58:36Z")

</div>

Hi Anderson,

Thanks for your tips.

Actually, my N200 has the recent firmware (usrp\_n200\_fw.bin) and FPGA  
image  
(usrp\_n200\_r4\_fpga.bin). So I’m working on the filter design with less  
taps.

Best regards,  
Luis

2015-06-24 16:47 GMT+02:00 Anderson, Douglas J.  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid):

---

<div class="post-metadata">

**Author:** ![Luis\_Grajales](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ecd19e/32.png) [@Luis\_Grajales](https://www.ruby-forum.com/u/Luis_Grajales)\
**Post date:** [June 24, 2015, 4:49pm UTC](https://www.ruby-forum.com/t/filter-bank-and-massive-ddd-messages/242429/7 "2015-06-24T16:49:18Z")

</div>

I recently faced a similar problem with my USRP N210 with a resampler  
chewing up my CPU. These steps helped a lot:

1. Design a filter with less taps (as Marcus recommended)

2. Build the latest GNURadio and UHD from git, and flash the N210 with  
the recently released FPGA update.

Not sure if the recent FGPA image update affects the N200 as well, but  
if it does, take advantage of it.

-Doug

* * *

From: [discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid](mailto:discuss-gnuradio-bounces+danderson=removed_email_address@domain.invalid)  
[discuss-gnuradio-bounces+danderson=removed\_email\_address@domain.invalid] on behalf  
of Marcus M. [removed\_email\_address@domain.invalid]  
Sent: Wednesday, June 24, 2015 1:38 AM  
To: [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
Subject: Re: [Discuss-gnuradio] Filter bank and massive DDD messages

Hi Luis,

I guess the idea was to look whether your CPU was really your  
bottleneck; filter banks are one of the most CPU-hungry signal  
processing steps one can think of, and hence, your "D"ropped packets  
could be caused by that. If I understand correctly, with the null sink  
(and/or the file\_sink) you don’t get that behaviour?  
If that’s the case, your PC can’t keep up to both the calculations  
needed for the filters and receiving the data from your USRP.

I think your polyphase filter bank approach has the brightest future  
(basically because I think polyphase filter banks are cool, and because  
they are really quite efficient), but your filter parameters are  
frightening: A transition bandwidth of 10kHz at a sampling rate of 25MHz  
is 0.04% transition width, which leads to a filter of more than 8000  
taps. Relax that transition width!  
I’d say: start gr\_filter\_design, and design a filter there, playing  
around with the parameters until things look better.

Generally, you don’t even closely seem to need the full 25MS/s you get  
from the USRP in your flow graphs, but you select different subbands in  
each flow graph (and in your original mail). What is the real span you  
need from lower edge of your lowest channel to upper edge of your  
highest channel? You should let the USRP do as much decimation for you  
as possible. It’s its job!

Best regards,  
Marcus

On 06/24/2015 08:34 AM, Luis Grajales wrote:  
Hi Martin,

Thank you for your message.

I was looking into the null sink blocks documentation and I couldn’t  
find any method or function where I can get an intermediate value into  
this block. Then, I just verified data at the input of this block, which  
is the confirmation of the streaming at the output of each channel. For  
this case I used a file sink block.

Please let me know if I need to do something else, or what is your  
general idea of the streaming verification into a null sink blocks.

Thanks again,

Luis

2015-06-23 18:20 GMT+02:00 Martin B.  
\<[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)\>:  
Luis,

can you please confirm/deny that streaming e.g. into a null sink works?

Thanks,  
Martin

On 23.06.2015 09:16, Luis Grajales wrote:

> USRP N200 ----------- channelizer — [ch1] -----GUI FFT Sink  
> Scenario 2: channelizer = 4 Xlating FIR filters.  
> Scenario 2: CPU between 75 % and 95 %.
> 
> * * *
> 
> Discuss-gnuradio mailing list  
> [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
> [Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

* * *

Discuss-gnuradio mailing list  
[removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)  
[Discuss-gnuradio Info Page](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)

---

<div class="post-metadata">

**Author:** ![Luis\_Grajales](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ecd19e/32.png) [@Luis\_Grajales](https://www.ruby-forum.com/u/Luis_Grajales)\
**Post date:** [June 24, 2015, 9:23pm UTC](https://www.ruby-forum.com/t/filter-bank-and-massive-ddd-messages/242429/8 "2015-06-24T21:23:55Z")

</div>

Hi Luis,

> I mean in order to sect an appropriate PC hardware requirements.  
> (sorry if it is an obvious question) .  
> No, that’s a very valid question. Generally, the computational load of a  
> filter is basically (n\_taps x sampling rate).  
> So, the computational load for the _same_ filter scales linearly with  
> rate. BUT:  
> The sharper, measured in 1/sampling rate, a filter is, the more taps it  
> needs.  
> There are approximate formulas for filters where the passband ripple  
> $\delta\_1$ gets designed to be equal to the stoppband ripple; I’ve  
> learned that with $\delta\_2$, the stoppband attenuation and the relative  
> transition with $b\_\text{rel}$ ($\frac{\text{transition  
> width}}{\text{sampling rate}}$) the length N of the filter amounts to:  
> $N\approx \frac{-20\log\_{10}{\sqrt{\delta\_1 \delta\_2}} -  
> 13}{14 b\_\text{rel}}$  
> That approximation is “pretty good” in my experience.

Now, since N is proportional to the sampling rate, and since the  
computational load is both proportional to sampling rate and N, you get  
quadratic dependency on sampling rate for a fixed transition width.

Back to your original question: The USRP doesn’t really care about the  
sampling rate. It can, without a problem produce the 25MS/s (or even  
50MS/s with 8bit samples), the only limit here is the bandwidth of  
gigabit ethernet. Everything that can go wrong happens on your PC.  
Generally, “D” is the worst form of failure, because it means that even  
your Operating System didn’t have enough time to process all the  
samples.  
So considering requirements for your PC: With your 8000 real taps  
filter, you probably won’t be able to find a computer that can deal with  
that like it is. Without taking advantage of polyphase technologies,  
that would be 16000 real multiplications and 16000 additions per sample  
– that’s a whopping 16000 FMAC/S \* 25MS/s = 400GFMAC/s.

GNU Radio has pretty good optimization for filters, so you might get  
considerable speed up. It’s pretty hard hence to say what you need,  
because it depends so much on what you want to do.

> Exactly, I don’t need to process the full 25 MHz of bandwidth but the  
> problem is that my different subbands are into this spectrum. For example:  
> Yeah, but how much bandwidth do you **really** need at once?  
> Now, the question is: multiplex USRP those 125 channel and will be the  
> new rate 200 Ksps?  
> Sorry, I don’t really understand your question.

Best regards,  
Marcus

---

<div class="post-metadata">

**Author:** ![Luis\_Grajales](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/ecd19e/32.png) [@Luis\_Grajales](https://www.ruby-forum.com/u/Luis_Grajales)\
**Post date:** [June 25, 2015, 12:36am UTC](https://www.ruby-forum.com/t/filter-bank-and-massive-ddd-messages/242429/9 "2015-06-25T00:36:43Z")

</div>

* * *

Discuss-gnuradio mailing list  
removed\_email\_address@domain.invalid  
[https://lists.gnu.org/mailman/listinfo/discuss-gnuradio](https://lists.gnu.org/mailman/listinfo/discuss-gnuradio)