Re: [Discuss-gnuradio] UHD USRP2 full duplex mystery solved
Just saw this thread now... I'm seeing this problem with my USRP2s and the WBX board. However, I'm not using UHD. Do you know a fix for this outside of UHD? On Tue, Sep 14, 2010 at 5:28 PM, Josh Blum wrote: > FYI - in the future this will go away in the future when tx flow control > becomes host-based (and away from ethernet pause frames). -Josh > > > On 09/14/2010 01:56 PM, Marc Epard wrote: > >> I've been attempting to do a full duplex send/recv using UHD on a USRP2 >> with an XCVR2450. >> >> The major problem I had was that issue_stream_cmd nearly always resulted >> in a runtime error of "usrp2 no control response". It worked fine if I >> transmitted w/o receiving or received w/o transmitting. The same code also >> worked when using a 2nd USRP2 for receiving. >> >> After a session with Wireshark and the UHD host source, I had my "Well, >> duh" moment. When you call send, the data starts streaming to the USRP2 >> right away -- even if you specify a timestamp in the future. The USRP2 >> starts sending back PAUSE frames almost immediately, which throttles not >> only additional send data, but also any commands to the control port. >> >> The solution is to call issue_stream_cmd first (and start the recv >> thread), then start the send thread. This was simple enough in my app >> because I was specifying start times in the future anyway. It does prevent a >> method I was going to use on a WBX where I start the send thread once and >> scan through several receive frequencies before stoping the send thread. >> >> Perhaps most of you knew about this gotcha already, but I hope this will >> help someone else who encounters the problem. Anyway, it was fun >> investigating and I learned a lot more about the UHD host code and protocols >> >> -Marc >> >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2+WBX full duplex doesn't receive
Did you ever get this fixed? I'm seeing the same problem... On Wed, Aug 25, 2010 at 5:53 PM, Marcus D. Leech wrote: > > > > On Aug 24, 2010, at 11:16 PM, George Nychis wrote: > > > > > >> I don't think I've had this issue with my WBX and USRP2. I will check > tomorrow for you > >> > > Thanks! I'd appreciate it. > > > > I've now replicated the problem with a XCVR2450, so I don't think it's > WBX-specific. > > > Just to note that the XCVR2450 has only a single VFO, so full-duplex on > different frequencies can't work--the hardware > isn't capable of it. But full-duplex on the WBX should work provided > that you use the RX/RX port for transmit and the RX2 > (secondary receive) antenna port for Rx. > > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortium > http://www.sbrac.org > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP as Network Analyzer?
Hi Is it possible to use USRP as simple Network Analyzer? We could use RX Part as Spectrum Analyzer and TX Part as Tracking Generator. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Printing gr_vector_sink_f data
So what you are saying is when I create an instance of the class, only the data and blocks are initialized and glued together, but the object didn't run yet. So source will never get to sink unless I use the run() method and then I can print the data. Let me know if this if I am correct. I did fix it. I put self.result_data = self.dst.data() in the print_data method and made the necessary changes and it worked. Josh Blum-2 wrote: > > > > On 09/22/2010 12:01 PM, sirjanselot wrote: >> >> Hello, >> >> I tried to print what data gr_vector_sink_f contains in the following >> code: >> >> #!/usr/bin/env python >> >> import howto >> from gnuradio import gr, gru >> from gnuradio.gr import firdes >> from optparse import OptionParser >> from gnuradio import blks2 >> >> class howto_square (gr.top_block): >> def __init__(self): >> gr.top_block.__init__(self) >> src_data = (-3, 4, -5.5, 2, 3) >> expected_result = (9, 16, 30.25, 4, 9) >> src = gr.vector_source_f (src_data) >> sqr = howto.square_ff () >> dst = gr.vector_sink_f () >> self.connect (src, sqr) >> self.connect (sqr, dst) >> self.result_data = dst.data() > > right here, you collect the data before running the flow graph > > -josh > >> >> def print_data(self): >> print self.result_data >> >> if __name__ == '__main__': >> #parser = OptionParser(option_class=eng_option, usage="%prog: >> [options]") >> #(options, args) = parser.parse_args() >> hw = howto_square() >> hw.run() >> hw.print_data() >> >> But it is always empty. >> >> Any thoughts? >> >> Thanks > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- View this message in context: http://old.nabble.com/Printing-gr_vector_sink_f-data-tp29782854p29783239.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Printing gr_vector_sink_f data
On 09/22/2010 12:01 PM, sirjanselot wrote: Hello, I tried to print what data gr_vector_sink_f contains in the following code: #!/usr/bin/env python import howto from gnuradio import gr, gru from gnuradio.gr import firdes from optparse import OptionParser from gnuradio import blks2 class howto_square (gr.top_block): def __init__(self): gr.top_block.__init__(self) src_data = (-3, 4, -5.5, 2, 3) expected_result = (9, 16, 30.25, 4, 9) src = gr.vector_source_f (src_data) sqr = howto.square_ff () dst = gr.vector_sink_f () self.connect (src, sqr) self.connect (sqr, dst) self.result_data = dst.data() right here, you collect the data before running the flow graph -josh def print_data(self): print self.result_data if __name__ == '__main__': #parser = OptionParser(option_class=eng_option, usage="%prog: [options]") #(options, args) = parser.parse_args() hw = howto_square() hw.run() hw.print_data() But it is always empty. Any thoughts? Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Printing gr_vector_sink_f data
Hello, I tried to print what data gr_vector_sink_f contains in the following code: #!/usr/bin/env python import howto from gnuradio import gr, gru from gnuradio.gr import firdes from optparse import OptionParser from gnuradio import blks2 class howto_square (gr.top_block): def __init__(self): gr.top_block.__init__(self) src_data = (-3, 4, -5.5, 2, 3) expected_result = (9, 16, 30.25, 4, 9) src = gr.vector_source_f (src_data) sqr = howto.square_ff () dst = gr.vector_sink_f () self.connect (src, sqr) self.connect (sqr, dst) self.result_data = dst.data() def print_data(self): print self.result_data if __name__ == '__main__': #parser = OptionParser(option_class=eng_option, usage="%prog: [options]") #(options, args) = parser.parse_args() hw = howto_square() hw.run() hw.print_data() But it is always empty. Any thoughts? Thanks -- View this message in context: http://old.nabble.com/Printing-gr_vector_sink_f-data-tp29782854p29782854.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Setting buffer size when using UHD
On 09/22/2010 07:17 AM, Per Zetterberg wrote: Is the receiver buffer size in bytes or samples ? bytes Its a direct proxy for SO_REVBUF socket option. http://www.boost.org/doc/libs/1_41_0/doc/html/boost_asio/reference/basic_datagram_socket/receive_buffer_size.html http://msdn.microsoft.com/en-us/library/ms740476%28VS.85%29.aspx -Josh From: discuss-gnuradio-bounces+perz=kth...@gnu.org [discuss-gnuradio-bounces+perz=kth...@gnu.org] on behalf of Josh Blum [j...@joshknows.com] Sent: Monday, September 20, 2010 5:07 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Setting buffer size when using UHD The buffer size setting is used across all motherboards in the mimo setup. So, if specified, its only specified once: http://www.ettus.com/uhd_docs/manual/html/usrp2.html#resize-the-send-and-receive-buffers If this is linux, I recommend setting sysctl and letting UHD automatically pick the size. sudo sysctl -w net.core.rmem_max=5000 -Josh On 09/20/2010 03:36 AM, Per Zetterberg wrote: Hi All, How do I set the buffer size when using uhd::usrp::mimo_usrp ? BR/ Per ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 FM TX and FM RX working together
Jorge, Your sample rates do not match. The sample rates your USRP2 is operating at is fixed for a given decimation/interpolation, and you must choose sample rates in your upstream and downstream blocks to match. For instance, in your receiver chain, you are using a decimation rate of 64. This means that your USRP2 will provide samples to the rest of your flowgraph at 1.5625Msps. This is connected to an FFT sink operating at 200ksps -- this is not correct. If you want to operate at 200ksps you must provide a resampling block to get there. Likewise, your rational resampler at (32/25) outputs a sample rate of (1.5625e6 * (32/25)) = 2e6 samples per second. Your low pass filter which follows is expecting a sample rate of 256k. This will cause the filter coefficients to be incorrectly calculated, and eventually will cause over/underruns when you finally get to a block which operates at a fixed sample rate, like your audio sink. The "" you are seeing is caused by the audio sink being overrun by providing it with 250ksps when it is expecting 32ksps. Nick On Wed, 2010-09-22 at 08:30 +0200, Jorge Miguel wrote: > Sorry, in my previous email the code was corrupted.. This is the right > code of my GRC: > > > > Wed Sep 22 08:14:26 2010 > > variable_slider > > id > tune_filter > > > _enabled > True > > > label > LPF Cutoff Freq > > > value > 75000 > > > min > 15000 > > > max > 15 > > > num_steps > 1000 > > > style > wx.SL_HORIZONTAL > > > converver > float_converter > > > grid_pos > > > > notebook > > > > _coordinate > (0, 127) > > > _rotation > 0 > > > > gr_frequency_modulator_fc > > id > gr_frequency_modulator_fc_0 > > > _enabled > True > > > sensitivity > 0.980 > > > _coordinate > (454, 315) > > > _rotation > 0 > > > > blks2_rational_resampler_xxx > > id > blks2_rational_resampler_xxx_0_0 > > > _enabled > True > > > type > fff > > > decim > 1 > > > interp > 5 > > > taps > [] > > > fractional_bw > 0 > > > _coordinate > (233, 68) > > > _rotation > 0 > > > > note > > id > Chain1 > > > _enabled > True > > > note > MODULATOR > > > _coordinate > (233, 9) > > > _rotation > 0 > > > > note > > id > Chain1_0 > > > _enabled > True > > > note > DEMODULATOR > > > _coordinate > (181, 427) > > > _rotation > 0 > > > > blks2_rational_resampler_xxx > > id > blks2_rational_resampler_xxx_1 > > > _enabled > True > > > type > fff > > > decim > 1 > > > interp > 4 > > > taps > [] > > > fractional_bw > 0 > > > _coordinate > (699, 122) > > > _rotation > 0 > > > > wxgui_fftsink2 > > id > wxgui_fftsink2_0_0 > > > _enabled > True > > > type > complex > > > title > FFT Plot > > > samp_rate > 20 > > > baseband_freq > 200 > > > y_per_div > 10 > > > y_divs > 10 > > > ref_level > 50 > > > fft_size > 512 > > > fft_rate > 50 > > > peak_hold > False > > > average > False > > > avg_alpha > 0 > > > grid_pos > > > > notebook > > > > _coordinate > (370, 568) > > > _rotation > 0 > > > > audio_sink > > id > audio_sink_0 > > > _enabled > True > > > samp_rate > 32000 > > > device_name > plughw:0,0 > > > ok_to_block > True > > > num_inputs > 1 > > > _coordinate > (607, 648) > > > _rotation > 0 > > > > usrp2_sink_ > > id > usrp2_sink__0 > > > _enabled > True > > > type > complex > > > interface > >
Re: [Discuss-gnuradio] GNU Radio and usrp_standard.h: No such file or directory
Tom, that is exactly the conclusion I came to after lots of googleing !. Thanks a lot for the really good help. I am glad that now guys who adventure in c++ development will have this piece of info. Regards, Fabrizio On Wed, Sep 22, 2010 at 4:42 PM, Tom Rondeau wrote: > On Tue, Sep 21, 2010 at 2:26 PM, Thomas Tsou wrote: >> On Tue, Sep 21, 2010 at 10:20 AM, Fabrizio Tappero >> wrote: >>> Dear All, >>> I'd like to add a little piece of information about this problem. >>> if I try to compile the previously mentioned code with: >>> g++ usrp_test_c++.cpp -o testusrp `pkg-config --cflags usrp` >>> `pkg-config --libs usrp` >>> >>> and I change: >>> #include "usrp_standard.h" >>> in: >>> #include "usrp/usrp_standard.h" >>> #include >>> >>> the code from here: >>> http://gnuradio.org/redmine/wiki/1/UsrpFAQCppInterface >>> >>> almost compile... >> >> As you discovered, there are a number of problems with the example >> code. I made some quick changes to the wiki page, which was quite >> dated. It should now compile with gnuradio 3.3 and recent Linux >> distributions. >> >> Thomas > > > Fabrizio, > > I made some edits to the FAQ page you pointed to > (http://gnuradio.org/redmine/wiki/1/UsrpFAQCppInterface). I added more > information about how to set up and use pkg-config for linking to > libusrp when GNU Radio isn't installed in the standard paths. > > Hope this helps... > > Tom > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio-companion error
On Fri, Sep 17, 2010 at 7:08 AM, zhang wei wrote: > > The log is as following: > > cl...@ubuntu:~$ gnuradio-companion > <<< Welcome to GNU Radio Companion v3.3.1git-53-gc81312ce >>> > > Loading: "/home/cliff/t1.grc" Done > > Showing: "/home/cliff/t1.grc" > > Generating: "/home/cliff/top_block.py" > > Executing: "/home/cliff/top_block.py" > > Done > > > >> > > Is grc showing any error message in the console window ? > > On Fri, Sep 17, 2010 at 12:28 PM, zhang wei wrote: > Hi Josh, > > I have installed the python-opengl (See the Accessories). > But I still can't see the waveform. > > > Cliff Do any of the examples in gnuradio-examples/grc/ work for you? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio and usrp_standard.h: No such file or directory
On Tue, Sep 21, 2010 at 2:26 PM, Thomas Tsou wrote: > On Tue, Sep 21, 2010 at 10:20 AM, Fabrizio Tappero > wrote: >> Dear All, >> I'd like to add a little piece of information about this problem. >> if I try to compile the previously mentioned code with: >> g++ usrp_test_c++.cpp -o testusrp `pkg-config --cflags usrp` >> `pkg-config --libs usrp` >> >> and I change: >> #include "usrp_standard.h" >> in: >> #include "usrp/usrp_standard.h" >> #include >> >> the code from here: >> http://gnuradio.org/redmine/wiki/1/UsrpFAQCppInterface >> >> almost compile... > > As you discovered, there are a number of problems with the example > code. I made some quick changes to the wiki page, which was quite > dated. It should now compile with gnuradio 3.3 and recent Linux > distributions. > > Thomas Fabrizio, I made some edits to the FAQ page you pointed to (http://gnuradio.org/redmine/wiki/1/UsrpFAQCppInterface). I added more information about how to set up and use pkg-config for linking to libusrp when GNU Radio isn't installed in the standard paths. Hope this helps... Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Setting buffer size when using UHD
Is the receiver buffer size in bytes or samples ? From: discuss-gnuradio-bounces+perz=kth...@gnu.org [discuss-gnuradio-bounces+perz=kth...@gnu.org] on behalf of Josh Blum [j...@joshknows.com] Sent: Monday, September 20, 2010 5:07 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Setting buffer size when using UHD The buffer size setting is used across all motherboards in the mimo setup. So, if specified, its only specified once: http://www.ettus.com/uhd_docs/manual/html/usrp2.html#resize-the-send-and-receive-buffers If this is linux, I recommend setting sysctl and letting UHD automatically pick the size. sudo sysctl -w net.core.rmem_max=5000 -Josh On 09/20/2010 03:36 AM, Per Zetterberg wrote: > Hi All, > > How do I set the buffer size when using uhd::usrp::mimo_usrp ? > > BR/ > Per > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem using benchmark_rx.py with XCVR2450 Transceivers
On Wed, Sep 22, 2010 at 2:54 AM, Lebowski80 wrote: > > Hello > > I'm trying to utilize benchmark_tx.py and benchmark_rx.py using 2 USRPs with > XCVR2450 Transceivers. When I consider a bit rate equal or greater than 124k > everything works well. With bit rates smaller than 124k only the > ./benchmark_tx.py can run, while ./benchmark_rx.py can't receive any signal. > > Can someone tell me why? > > Thanks in advance! The main problem is setting the interpolation and decimation rates in the USRPs. Since they have limits on how low their sample rates can go based on an upper bound of the interp/decim rates, that kind of limits the bit rates you can use. This is somewhat gotten around by increasing the number of samples per symbol in the modulators/demodulators, but that's problematic for another reason. In the current way of doing the digital demod, we use an M&M clock recovery loop that doesn't like to work with large samples per symbol (the parameters have to be hand-tuned...). We've mostly fixed this issue in the newer code that will become the default soon enough. If you are using the code from a git checkout, look for the version 2 of the benchmark scripts. These run a different receiver and the transmitter has an arbitrary resampler in it to enable more sample rates. This _should_ perform better. I think I was able to transmit and receive at something like 10 or 15 kbps. Another thing to keep in mind is the frequency offset. When you're bandwidth gets smaller, the frequency offsets in the two USRPs become more problematic and maybe out of the bandwidth of the receiver and frequency locking system. If you see that there is a large frequency offset, you can try to manually tune the receiver to be closer to the correct frequency. If that works, than you can try opening the bandwidth of the receiver more to account for the large offset. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] General question concerning usrp & audio
On Tue, Sep 21, 2010 at 5:36 PM, Thomas Seidel wrote: > Thanks a lot for your help! > > file2.py now looks like this: > > class soundcheck(gr.top_block): > > def __init__(self): > gr.top_block.__init__(self) > > self.decim_rate = 256 > self.u = usrp.source_c(0, self.decim_rate) > > self.rx_subdev_spec = usrp.pick_rx_subdevice(self.u) > self.subdev = usrp.selected_subdev(self.u, self.rx_subdev_spec) > self.input_rate = self.u.adc_freq() / self.decim_rate > > res = self.u.tune(0, self.subdev, 13.56e6) > if res: > print 'frequency successfully changed to 13.56Mhz' > else: > print 'tuning failed' > sys.exit(1) > > > interp = gru.lcm(self.input_rate, 48000) / self.input_rate > decim = gru.lcm(self.input_rate, 48000) / 48000 > interp = int(interp) > decim = int(decim) > > print 'interp = %d, decim = %d' % (interp, decim) > rr = blks2.rational_resampler_ccc(interp, decim) > > > self.sndsink = audio.sink(48000, 'plughw:0,0') > self.magblk = gr.complex_to_mag() > self.connect(self.u, rr, self.magblk, (self.sndsink, 0)) > > > As one can see I added the reational_resampler_ccc(), hoping that it does the > magic work needed that I can hear a nice sine wave, but still there is only > noise. On the transmitting side a gr.sig_source_c(48000, gr.GR_SIN_WAVE, > 4000, 1000) is used with the interpolation of the USRP set to a factor of 32. > Maybe I still lack of a proper understanding of the whole issue so that I > would really appreciate your help. > > Tom I always find it useful to test a new transmitter by looking at the received signal coming from the USRP. You can use usrp_fft.py to see what's happening in the spectrum. You should be seeing a clean tone at the frequency you're transmitting at. If the one isn't clean or isn't there, you're still doing something wrong (probably be with the sample rates). When you're comfortable with the transmitter, then you can work on the receiver (and Alexandru Csete's follow-up has good suggestions). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP2 FM TX and FM RX working together
I forgot to mention, but I get a lot of messages like: .SSS SSaUSSS. I did the calculations and with the 104 interpolation USRP sink and 208 decimation USRP source and 16 bits per sample means that less than 100Mbs are taken from the 1Gbps ethernet wire. So there souldn't be any overload. Furthermore I still don't know why is necessary the multiply cont block in the modulator. Can anybody help me? I am very close ! Regards, Jorge. On 21 September 2010 18:59, Rafael Diniz wrote: > Hi Jorge, > Can you copy the .grc file you created? > > > Hello community! > > > > I initiated myself in GNU radio two weeks ago and I am learning as fast > as > > I > > can. To begin with, I decided to play with GRC and my URSP2. > > I successfully built a FM modulator that works fine. > > I successfully built a FM demodulator that works fine. > > But there are still several things I do not understand. > > > > While building the FM modulator: > > 1)Wave file source > > 2)Rational resampler > > 3)LPF > > 4)Rational resampler > > 5)Frequency Mod > > 6)Multiply const > > 7)USRP2 sink > > > > Why is block 6 necessary? I tried with lots of values over 2 and all of > > them > > are ok. I realized that the smaller the number, the higher the noise in > my > > receiver (my mobile phone). Is it related to the amplitude of the > > modulated > > signal? > > > > Another thing very strange is that if I create a GRC file with both, > > transmitter and receiver with exactly the same blocks and the same > > parameters I cannot hear any demodulated signal. I can see information > > with > > a FFT block connected to the receiver chain, and I am able to demodulate > > the > > signal with my mobile phone when the example is running but in my > computer > > I > > do not hear anything else besides noise mixed with some sort of > > non-understandable signal. Thus, I guess I have to change something in > the > > receiver chain although it works alone in my FM demodulator. I changed > > every > > single parameter but I cannot get any improvement. > > > > Any suggestions? > > > > Many thanks in advance, > > Jorge. > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
