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 <[email protected]>: > 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 <[email protected]>: > >> 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 >> > [email protected] >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > > > _______________________________________________ > Discuss-gnuradio mailing > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
