[Discuss-gnuradio] This is nice

2012-03-21 Thread David Kierzkowski
The osmocom guys are using a 20$ USB catv tuner as a RF source in gnuradio. 3.2MS/s ! http://sdr.osmocom.org/trac/wiki/rtl-sdr ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Problem with GRC

2012-03-21 Thread Farhad Abdolian
HI Marcus, Found the problem, had some issues with the installation, so I used the script from http://www.sbrac.org/files/build-gnuradio that removed the old installation and installed a clean GR. Now everything seems to work properly. Thanks a lot everyone, BR, Farhad >

[Discuss-gnuradio] unexpected LookupError using gpsdo

2012-03-21 Thread Fengzhu FengzhuYe
Hi, I have bought two gpsdos and install them to my usrp n210. Then I congfiured them step by step according to the following link provided by ettus LLC http://files.ettus.com/uhd_docs/manual/html/gpsdo.html. After all the things had done, I tried to retrieve the current GPS time by the "gps_time

Re: [Discuss-gnuradio] unexpected LookupError using gpsdo

2012-03-21 Thread mleech
On Wed, 21 Mar 2012 21:23:39 +0800 (CST), Fengzhu FengzhuYe wrote: > Hi, > I have bought two gpsdos and install them to my usrp n210. Then I congfiured them step by step according to the following link provided by ettus LLC http://files.ettus.com/uhd_docs/manual/html/gpsdo.html. > After all

[Discuss-gnuradio] segfault in volk_32fc_x2_multiply_32fc_a_sse3 using current master branch

2012-03-21 Thread Ben Reynwar
I'm seeing a segfault in volk_32fc_x2_multiply_32fc_a_sse3 and am using the current master branch. It occurs when I connect a gr.multiply_cc to a running flowgraph (using tb.lock() and tb.unlock()). If the multiply_cc block is connected before the flowgraph starts running then I don't see a segfa

Re: [Discuss-gnuradio] segfault in volk_32fc_x2_multiply_32fc_a_sse3 using current master branch

2012-03-21 Thread Nick Foster
On Wed, Mar 21, 2012 at 10:57 AM, Ben Reynwar wrote: > I'm seeing a segfault in volk_32fc_x2_multiply_32fc_a_sse3 and am > using the current master branch. > > It occurs when I connect a gr.multiply_cc to a running flowgraph > (using tb.lock() and tb.unlock()). If the multiply_cc block is > conn

[Discuss-gnuradio] UHD Performance: Reaching 8Msps TX with USB 2.0 (?)

2012-03-21 Thread Vincenzo Pellegrini
HI fellows, I was wondering if anybody has been trying to reach 8 Complex Msps over the USB 2.0 on the Tx path. While this has always been OK with old libusrp (and USRP 1) it appears to be no longer possible by means of UHD neither when trying to do that on USRP1 (a few underruns) nor on B100 (lot

Re: [Discuss-gnuradio] UHD Performance: Reaching 8Msps TX with USB 2.0 (?)

2012-03-21 Thread Nick Foster
On Wed, Mar 21, 2012 at 11:42 AM, Vincenzo Pellegrini wrote: > HI fellows, > > I was wondering if anybody has been trying to reach 8 Complex Msps over > the USB 2.0 on the Tx path. > While this has always been OK with old libusrp (and USRP 1) it appears to > be no longer possible by means of UHD >

Re: [Discuss-gnuradio] UHD Performance: Reaching 8Msps TX with USB 2.0 (?)

2012-03-21 Thread mleech
My sense is that a couple of things are "in play" in these scenarios: o UHD seems a little better at reporting under/overflow than "classic" o UHD consumes a slightly-larger amount of CPU in some critical parts of the USB processing than in "classic". Which means that situations that may

Re: [Discuss-gnuradio] UHD Performance: Reaching 8Msps TX with USB 2.0 (?)

2012-03-21 Thread Vincenzo Pellegrini
Hi Nick, thanks for the suggestions. I will test the args. What is the best (maximum?) possible value for the send_frame_size in order to minimize the overhead yielded by UHD? Would it be correct to assume that the over-the-wire overhead yielded by UHD is larger than what the classic libusrp used

Re: [Discuss-gnuradio] UHD Performance: Reaching 8Msps TX with USB 2.0 (?)

2012-03-21 Thread Marcus D. Leech
On 03/21/2012 05:45 PM, Vincenzo Pellegrini wrote: Hi Nick, thanks for the suggestions. I will test the args. What is the best (maximum?) possible value for the send_frame_size in order to minimize the overhead yielded by UHD? Would it be correct to assume that the over-the-wire overhead yield

Re: [Discuss-gnuradio] detecting spectrum holes

2012-03-21 Thread Abdelrahman Ahmed
2012/3/19 Alexander List > ** > On 01/-9/-28163 03:59 AM, Abdelrahman Ahmed wrote: > > i'm new to this ,i need your help on how to start detecting spectrum in TV > band and holes in this spectrum. > > > Ahmed, > > though others will probable be able to give you more in-depth directions > wrt spec

Re: [Discuss-gnuradio] This is nice

2012-03-21 Thread Andrew Davis
Saw it on Reddit a couple days ago, already have one on order. Then I might work on making a GnuRadio driver or something for real-time use. On Wed, Mar 21, 2012 at 3:17 AM, David Kierzkowski wrote: > The osmocom guys are using a 20$ USB catv tuner as a RF source in gnuradio. > 3.2MS/s ! > > htt

Re: [Discuss-gnuradio] detecting spectrum holes

2012-03-21 Thread John Ewan
I have had enough about this. What the heck is a spectrum hole. I am pretty sure this is probably a term brought up by some There are NO spectrum holes. Learn about black body radiation and KTB Sorry folks. the term has always erked me. We can talk about white space.that I c

Re: [Discuss-gnuradio] detecting spectrum holes

2012-03-21 Thread Marcus D. Leech
On 21/03/12 11:25 PM, John Ewan wrote: > I have had enough about this. What the heck is a spectrum hole. > I am pretty sure this is probably a term brought up by some > > > There are NO spectrum holes. Learn about black body radiation > and KTB > > Sorry folks. the term has always e

[Discuss-gnuradio] re: unexpected LookupError using gpsdo

2012-03-21 Thread Fengzhu FengzhuYe
Hi mleech, thanks for your help. I have done the post-installation task by using the command :sudo ./usrp_burn_mb_eeprom --args=addr=192.168.10.2 --key=gpsdo --val=internal The terminal return: Creating USRP device from address: addr=192.168.10.2 -- Opening a USRP2/N-Series device... -- Current