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=its.bldrdoc....@gnu.org [discuss-gnuradio-bounces+danderson=its.bldrdoc....@gnu.org] on behalf of Marcus Müller [marcus.muel...@ettus.com] Sent: Wednesday, June 24, 2015 1:38 AM To: discuss-gnuradio@gnu.org 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 Braun <martin.br...@ettus.com<mailto:martin.br...@ettus.com>>: 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: > Hi, > > > I'mtrying to filter 14 frequency bands (channels), which are > dispersingwithinspectrum 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 > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org<mailto:Discuss-gnuradio@gnu.org> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
