[Discuss-gnuradio] This is nice
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
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 > > From: Marcus D. Leech >To: discuss-gnuradio@gnu.org >Sent: Tuesday, March 20, 2012 3:02 PM >Subject: Re: [Discuss-gnuradio] Problem with GRC > > >On 03/20/2012 09:56 AM, Farhad Abdolian wrote: >Hi guys, >>After a long interruption I have started to use GR again and had to install a fresh copy on my laptop. Everything seems to be working, the installation went well and all the tests seems to be OK, except when I try to run GRC. >> >>The GRC starts without problem and I can run the dial_tone.grc without any problem, but none of the other examples seems to work. >> >>For example, when I load the cvsd_sweep.grc file (under the same directory as the previous one), then I can neither generate nor execute the example. >> >>I have attached the screen capture of my GRC. >> >>I am using Ubuntu 10.04 LTS and GR 3.5.1 installed from GIT. >> >>Really appreciate your help to give me a hint of what can be the source of the problem? >> >>Best regards, >>Farhad >> >> ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio You have display items at the same grid positions. GRC cares about that now. > > > > >-- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org >___ >Discuss-gnuradio mailing list >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
[Discuss-gnuradio] unexpected LookupError using gpsdo
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" sensor using the codes : "
usrp->get_mboard_sensor("gps_time") ". The
compilation is ok and I executived the program. Then an unexpected LookupError
occured :
Error: LookupError: Path not found in tree: /mboards/0/sensors/gps_time
I printed all sensor list and there are only two sensor "mimo_locked",
"ref_locked". So I thought that means The gpsdo was not properly set so that
the usrp didn't find any "gps_time" sensors. But when I executived the program
"test_pps_input" at /usr/local/share/uhd/example. The pps seens all right. That
means the gpsdo is ok. What's more, when I used the reference sources
provided by an external GPSDO by the code :
usrp->set_clock_source("external");
usrp->set_time_source("external");
It work well too.
Now I am confused . why is that happen? Was my gpsdo broken? All the two gpsdos
have the same LookupError.
Thanks for your help.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] unexpected LookupError using gpsdo
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 the
things had done, I tried to retrieve the current GPS time by the
"gps_time" sensor using the codes : "
usrp->get_mboard_sensor("gps_time") ". The
> compilation is ok and I
executived the program. Then an unexpected LookupError occured :
>
>
Error: LookupError: Path not found in tree: /mboards/0/sensors/gps_time
>
> I printed all sensor list and there are only two sensor
"mimo_locked", "ref_locked". So I thought that means The gpsdo was not
properly set so that the usrp didn't find any "gps_time" sensors. But
when I executived the program "test_pps_input" at
/usr/local/share/uhd/example. The pps seens all right. That means the
gpsdo is ok. What's more, when I used the reference sources provided by
an external GPSDO by the code :
> usrp->set_clock_source("external");
> usrp->set_time_source("external");
> It work well too.
>
> Now I
am confused . why is that happen? Was my gpsdo broken? All the two
gpsdos have the same LookupError.
>
> Thanks for your help.
Did you
do the post-installation task:
http://files.ettus.com/uhd_docs/manual/html/gpsdo.html#post-installation-task-n-series-only
Also, the "gps_time" is only available once the GPSDO is locked to a
GPS satellite constellation--that's where it gets the time from (and the
phase reference!).
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] segfault in volk_32fc_x2_multiply_32fc_a_sse3 using current master branch
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 segfault. I have attached: - a minimal python script that reproduces the problem for me. - the output from gdb (backtrace and disassemble) OS is 32 bit Ubuntu 11.04 beta. cpu is Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz minimal_segfault.py Description: Binary data gdb.log Description: Binary data ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segfault in volk_32fc_x2_multiply_32fc_a_sse3 using current master branch
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 > connected before the flowgraph starts running then I don't see a > segfault. > > I have attached: > - a minimal python script that reproduces the problem for me. > - the output from gdb (backtrace and disassemble) > > OS is 32 bit Ubuntu 11.04 beta. > cpu is Intel(R) Core(TM) i3-2100 CPU @ 3.10GHz > This is an alignment error. The buffer passed to MOVAPS is not 16-byte aligned when the instruction is called. --n > > ___ > Discuss-gnuradio mailing list > 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
[Discuss-gnuradio] UHD Performance: Reaching 8Msps TX with USB 2.0 (?)
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 (lots of overruns). Everything appears instead fine on the Rx path Is there any workaround to this? ..or did I miss something? thanks everybody PS USB 3.0 seems to be capable enough for the 8 Msps. Is USB3.0 a requirement for 8 Msps on the B100? B100 ./benchmark_rate --tx_rate 8e6 linux; GNU C++ version 4.6.1 20110908 (Red Hat 4.6.1-9); Boost_104600; UHD_003.004.000-325-g7e296167 Creating the usrp device with: ... -- USRP-B100 clock control: 10 -- r_counter: 2 -- a_counter: 0 -- b_counter: 20 -- prescaler: 8 -- vco_divider: 5 -- chan_divider: 5 -- vco_rate: 1600.00MHz -- chan_rate: 320.00MHz -- out_rate: 64.00MHz -- Using Device: Single USRP: Device: B-Series Device Mboard 0: B100 (B-Hundo) RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: WBX RX v3 + Simple GDB TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: WBX TX v3 + Simple GDB Testing transmit rate 8.00 Msps UU Benchmark rate summary: Num received samples:0 Num dropped samples: 0 Num overflows detected: 0 Num transmitted samples: 79931260 Num sequence errors: 0 Num underflows detected: 406 Done! ./benchmark_rate --tx_rate 8e6 --tx_otw sc16 linux; GNU C++ version 4.6.1 20110908 (Red Hat 4.6.1-9); Boost_104600; UHD_003.004.000-325-g7e296167 Creating the usrp device with: ... -- USRP-B100 clock control: 10 -- r_counter: 2 -- a_counter: 0 -- b_counter: 20 -- prescaler: 8 -- vco_divider: 5 -- chan_divider: 5 -- vco_rate: 1600.00MHz -- chan_rate: 320.00MHz -- out_rate: 64.00MHz -- Using Device: Single USRP: Device: B-Series Device Mboard 0: B100 (B-Hundo) RX Channel: 0 RX DSP: 0 RX Dboard: A RX Subdev: WBX RX v3 + Simple GDB TX Channel: 0 TX DSP: 0 TX Dboard: A TX Subdev: WBX TX v3 + Simple GDB Testing transmit rate 8.00 Msps Benchmark rate summary: Num received samples:0 Num dropped samples: 0 Num overflows detected: 0 Num transmitted samples: 79890620 Num sequence errors: 0 Num underflows detected: 696 Done! USRP 1 ./benchmark_rate --tx_rate 8e6 --tx_otw sc16 linux; GNU C++ version 4.6.1 20110908 (Red Hat 4.6.1-9); Boost_104600; UHD_003.004.000-325-g7e296167 *** Warning! *** Benchmark results will be inaccurate on USRP1 due to insufficient features. Creating the usrp device with: ... -- Opening a USRP1 device... -- Using FPGA clock rate of 64.00MHz... Using Device: Single USRP: Device: USRP1 Device Mboard 0: USRP1 (Classic) RX Channel: 0 RX DSP: 0 RX Dboard: B RX Subdev: WBX RX v2 + Simple GDB TX Channel: 0 TX DSP: 0 TX Dboard: B TX Subdev: WBX TX v2 + Simple GDB Testing transmit rate 8.00 Msps U Benchmark rate summary: Num received samples:0 Num dropped samples: 0 Num overflows detected: 0 Num transmitted samples: 80022656 Num sequence errors: 0 Num underflows detected: 5 Done! everything fine with 8bit samples ./benchmark_rate --tx_rate 8e6 --tx_otw sc8 linux; GNU C++ version 4.6.1 20110908 (Red Hat 4.6.1-9); Boost_104600; UHD_003.004.000-325-g7e296167 -- Loading firmware image: /usr/share/uhd/images/usrp_b100_fw.ihx... done Creating the usrp device with: ... -- USRP-B100 clock control: 10 -- r_counter: 2 -- a_counter: 0 -- b_counter: 20 -- prescaler: 8 -- vco_divider: 5 -- chan_divider: 5 -- vco_rate: 1600.000
Re: [Discuss-gnuradio] UHD Performance: Reaching 8Msps TX with USB 2.0 (?)
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 > neither when trying to do that on USRP1 (a few underruns) nor on B100 > (lots of overruns). > > > Everything appears instead fine on the Rx path > > Is there any workaround to this? > > ..or did I miss something? > > > thanks everybody > > PS > USB 3.0 seems to be capable enough for the 8 Msps. > Is USB3.0 a requirement for 8 Msps on the B100? > > Look for other devices on that USB bus using lsusb. Avoid sharing the bus with other peripherals (bluetooth, wlan, etc). You can also modify the transport parameters using --args=recv_frame_size=x,send_frame_size=x. This will give you the same control over receive & send frame size that the old USRP1 drivers had. The default receive/send frame sizes are 16K, which seems to work OK on most machines. For comparison, the USB host controller I'm using is the Intel 6 Series/C200, and on B100 I can use a TX send rate of 10.67Msps without underflow, although occasionally underflows occur at the very beginning of the transmission (likely due to interrupt coalescing on the USB controller). I also have a USB 3.0 controller (an NEC Corporation uPD720200) on this laptop, which fares more poorly, but still easily achieves 8Msps. I don't have a good explanation as to why some USB controllers do better than others. USB 3.0 is certainly not required on B100/USRP1, as neither device uses USB 3.0. --n > > > B100 > > ./benchmark_rate --tx_rate 8e6 > linux; GNU C++ version 4.6.1 20110908 (Red Hat 4.6.1-9); Boost_104600; > UHD_003.004.000-325-g7e296167 > > > Creating the usrp device with: ... > -- USRP-B100 clock control: 10 > -- r_counter: 2 > -- a_counter: 0 > -- b_counter: 20 > -- prescaler: 8 > -- vco_divider: 5 > -- chan_divider: 5 > -- vco_rate: 1600.00MHz > -- chan_rate: 320.00MHz > -- out_rate: 64.00MHz > -- > Using Device: Single USRP: > Device: B-Series Device > Mboard 0: B100 (B-Hundo) > RX Channel: 0 > RX DSP: 0 > RX Dboard: A > RX Subdev: WBX RX v3 + Simple GDB > TX Channel: 0 > TX DSP: 0 > TX Dboard: A > TX Subdev: WBX TX v3 + Simple GDB > > Testing transmit rate 8.00 Msps > > UU > Benchmark rate summary: > Num received samples:0 > Num dropped samples: 0 > Num overflows detected: 0 > Num transmitted samples: 79931260 > Num sequence errors: 0 > Num underflows detected: 406 > > > Done! > > > > ./benchmark_rate --tx_rate 8e6 --tx_otw sc16 > linux; GNU C++ version 4.6.1 20110908 (Red Hat 4.6.1-9); Boost_104600; > UHD_003.004.000-325-g7e296167 > > > Creating the usrp device with: ... > -- USRP-B100 clock control: 10 > -- r_counter: 2 > -- a_counter: 0 > -- b_counter: 20 > -- prescaler: 8 > -- vco_divider: 5 > -- chan_divider: 5 > -- vco_rate: 1600.00MHz > -- chan_rate: 320.00MHz > -- out_rate: 64.00MHz > -- > Using Device: Single USRP: > Device: B-Series Device > Mboard 0: B100 (B-Hundo) > RX Channel: 0 > RX DSP: 0 > RX Dboard: A > RX Subdev: WBX RX v3 + Simple GDB > TX Channel: 0 > TX DSP: 0 > TX Dboard: A > TX Subdev: WBX TX v3 + Simple GDB > > Testing transmit rate 8.00 Msps > > > Benchmark rate summary: > Num received samples:0 > Num dropped samples: 0 > Num overflows detected: 0 > Num transmitted samples: 79890620 > Num sequence errors: 0 > Num underflows detected: 696 > > > Done! > > > USRP 1 > > ./benchmark_rate --tx_rate 8e6 --tx_otw sc16 > linux; GNU C++ version 4.6.1 20110908 (Red H
Re: [Discuss-gnuradio] UHD Performance: Reaching 8Msps TX with USB 2.0 (?)
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 have been marginal before are now over the edge. I'm also not sure what makes a "good" USB controller and a "not so good" USB controller. -Marcus On Wed, 21 Mar 2012 11:59:14 -0700, Nick Foster wrote: > 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 >> neither when trying to do that on USRP1 (a few underruns) nor on B100 (lots of overruns). >> >> Everything appears instead fine on the Rx path >> >> Is there any workaround to this? >> >> ..or did I miss something? >> >> thanks everybody >> >> PS >> USB 3.0 seems to be capable enough for the 8 Msps. >> Is USB3.0 a requirement for 8 Msps on the B100? > > Look for other devices on that USB bus using lsusb. Avoid sharing the bus with other peripherals (bluetooth, wlan, etc). You can also modify the transport parameters using --args=recv_frame_size=x,send_frame_size=x. This will give you the same control over receive & send frame size that the old USRP1 drivers had. The default receive/send frame sizes are 16K, which seems to work OK on most machines. > > For comparison, the USB host controller I'm using is the Intel 6 Series/C200, and on B100 I can use a TX send rate of 10.67Msps without underflow, although occasionally underflows occur at the very beginning of the transmission (likely due to interrupt coalescing on the USB controller). > > I also have a USB 3.0 controller (an NEC Corporation uPD720200) on this laptop, which fares more poorly, but still easily achieves 8Msps. I don't have a good explanation as to why some USB controllers do better than others. USB 3.0 is certainly not required on B100/USRP1, as neither device uses USB 3.0. > > --n > >> B100 >> >> ./benchmark_rate --tx_rate 8e6 >> linux; GNU C++ version 4.6.1 20110908 (Red Hat 4.6.1-9); Boost_104600; UHD_003.004.000-325-g7e296167 >> >> Creating the usrp device with: ... >> -- USRP-B100 clock control: 10 >> -- r_counter: 2 >> -- a_counter: 0 >> -- b_counter: 20 >> -- prescaler: 8 >> -- vco_divider: 5 >> -- chan_divider: 5 >> -- vco_rate: 1600.00MHz >> -- chan_rate: 320.00MHz >> -- out_rate: 64.00MHz >> -- >> Using Device: Single USRP: >> Device: B-Series Device >> Mboard 0: B100 (B-Hundo) >> RX Channel: 0 >> RX DSP: 0 >> RX Dboard: A >> RX Subdev: WBX RX v3 + Simple GDB >> TX Channel: 0 >> TX DSP: 0 >> TX Dboard: A >> TX Subdev: WBX TX v3 + Simple GDB >> >> Testing transmit rate 8.00 Msps >> UU >> Benchmark rate summary: >> Num received samples: 0 >> Num dropped samples: 0 >> Num overflows detected: 0 >> Num transmitted samples: 79931260 >> Num sequence errors: 0 >> Num underflows detected: 406 >> >> Done! >> >> ./benchmark_rate --tx_rate 8e6 --tx_otw sc16 >> linux; GNU C++ version 4.6.1 20110908 (Red Hat 4.6.1-9); Boost_104600; UHD_003.004.000-325-g7e296167 >> >> Creating the usrp device with: ... >> -- USRP-B100 clock control: 10 >> -- r_counter: 2 >> -- a_counter: 0 >> -- b_counter: 20 >> -- prescaler: 8 >> -- vco_divider: 5 >> -- chan_divider: 5 >> -- vco_rate: 1600.00MHz >> -- chan_rate: 320.00MHz >> -- out_rate: 64.00MHz >> -- >> Using Device: Single USRP: >> Device: B-Series Device >> Mboard 0: B100 (B-Hundo) >> RX Channel: 0 >> RX DSP: 0 >> RX Dboard: A >> RX Subdev: WBX RX v3 + Simple GDB >> TX Channel: 0 >> TX DSP: 0 >> TX Dboard: A >> TX Subdev: WBX TX v3 + Simple GDB >> >> Testing transmit rate 8.00 Msps >>
Re: [Discuss-gnuradio] UHD Performance: Reaching 8Msps TX with USB 2.0 (?)
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 to impose? If yes, by what scale? The USB peripherals configuration does not differ when I use the classic libusrp version and the UHD. Also, the difference in terms of underflow amount when using the tx_samples_from_file (UHD) and an equivalent classic, libusrp-based utility is huge using the same USB controller, same hard drive, same OS (fedora 16) in both cases. Actually I'm using the very same machine to do the tests. A friend of mine here in Pisa (Mario di Dio, he's also on the list) has obtained the same results on both Ubuntu 11.10 and Fedora 14. He had almost no underruns apart from some at the very beginning when he used his USB 3.0 port and lots of underruns when using the 2.0 USBs of the same laptop. I think I'm seeing something macroscopic, maybe a macroscopic mistake of mine. May I know what version of UHD you are using and your OS? sorry for the many questions, I'm just trying to figure out what I might be missing in order to properly use UHD for my purposes. thanks Il giorno 21 marzo 2012 19:59, Nick Foster ha scritto: > 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 >> neither when trying to do that on USRP1 (a few underruns) nor on B100 >> (lots of overruns). >> >> >> Everything appears instead fine on the Rx path >> >> Is there any workaround to this? >> >> ..or did I miss something? >> >> >> thanks everybody >> >> PS >> USB 3.0 seems to be capable enough for the 8 Msps. >> Is USB3.0 a requirement for 8 Msps on the B100? >> >> > Look for other devices on that USB bus using lsusb. Avoid sharing the bus > with other peripherals (bluetooth, wlan, etc). You can also modify the > transport parameters using > --args=recv_frame_size=x,send_frame_size=x. This will give you the > same control over receive & send frame size that the old USRP1 drivers had. > The default receive/send frame sizes are 16K, which seems to work OK on > most machines. > > For comparison, the USB host controller I'm using is the Intel 6 > Series/C200, and on B100 I can use a TX send rate of 10.67Msps without > underflow, although occasionally underflows occur at the very beginning of > the transmission (likely due to interrupt coalescing on the USB controller). > > I also have a USB 3.0 controller (an NEC Corporation uPD720200) on this > laptop, which fares more poorly, but still easily achieves 8Msps. I don't > have a good explanation as to why some USB controllers do better than > others. USB 3.0 is certainly not required on B100/USRP1, as neither device > uses USB 3.0. > > --n > > >> >> >> B100 >> >> ./benchmark_rate --tx_rate 8e6 >> linux; GNU C++ version 4.6.1 20110908 (Red Hat 4.6.1-9); Boost_104600; >> UHD_003.004.000-325-g7e296167 >> >> >> Creating the usrp device with: ... >> -- USRP-B100 clock control: 10 >> -- r_counter: 2 >> -- a_counter: 0 >> -- b_counter: 20 >> -- prescaler: 8 >> -- vco_divider: 5 >> -- chan_divider: 5 >> -- vco_rate: 1600.00MHz >> -- chan_rate: 320.00MHz >> -- out_rate: 64.00MHz >> -- >> Using Device: Single USRP: >> Device: B-Series Device >> Mboard 0: B100 (B-Hundo) >> RX Channel: 0 >> RX DSP: 0 >> RX Dboard: A >> RX Subdev: WBX RX v3 + Simple GDB >> TX Channel: 0 >> TX DSP: 0 >> TX Dboard: A >> TX Subdev: WBX TX v3 + Simple GDB >> >> Testing transmit rate 8.00 Msps >> >> UU >> Benchmark rate summary: >> Num received samples:0 >> Num dropped samples: 0 >> Num overflows detected: 0 >> Num transmitted samples: 79931260 >> Num sequence errors: 0 >> Num underflows detected: 406 >> >> >> Done! >> >> >> >> ./benchmark_rate --tx_rate 8e6 --tx_otw sc16 >> linux; GNU C++ version 4.6.1 20110908 (Red Hat 4.6.1-9); Boost_104600; >> UHD_003.004.000-325-g7e296167 >> >> >> Creating the usrp device with: ... >> -- USRP-B100 clock control: 10 >> -- r_counter: 2 >> -- a_counter: 0 >> -- b_counter: 20 >> -- prescaler: 8 >> -- vco_divider: 5 >> -- chan_divider: 5 >> -- vco_rate: 1600.
Re: [Discuss-gnuradio] UHD Performance: Reaching 8Msps TX with USB 2.0 (?)
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 yielded by UHD is larger than what the classic libusrp used to impose? If yes, by what scale? No, the over-the-wire format for USRP1 hasn't changed in years and years. UHD simply makes what's always been there look more "UHD like". Neither the USRP1 firmware nor FPGA images have changed in a long time. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] detecting spectrum holes
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 spectrum sensing, just out of curiosity, what's your use case? > > Are you looking into TV white spaces? [1] > > Most likely you'll want to use the USRP1 with WBX because I assume it has > better sensitivity than TVRX. > > Why would you want to transmit anything if you're just looking into > analyzing spectrum usage in TV channels? > > > > LP0410 is covering the right frequency band for UHF (400 MHz to 1 GHz), > but it is a directional antenna. Is that what you want? Otherwise, you > might be better off using an omni antenna, preferably on a roof... > > Here are a few pointers to papers on TV white spaces: > > http://www.openspectrum.eu/drupal6/node/23 > > I've posted some of the key issues on this list two years ago: > > http://www.ruby-forum.com/topic/205328 > > Dyspan has some nice papers on spectrum sensing as well: > > http://www.ieee-dyspan.org/2010/ > > http://cms.comsoc.org/eprise/main/SiteGen/DYSPAN_2010/Content/Home/Technical_and_Policy_Program.html > > Now to the setup: > > *Hardware / sample data* > > I have a USRP1, two WBX, USRP1 N210 and an PC hardware available as well, > so unless you're in a closed source / NDA environment, we could set up a > code repository on github, and I could provide you with sample recordings > from Hong Kong to cross-check detectors. > > *Regulatory environment / signals too look for* > > What is your location? From your signature, I assume you're in the Middle > East, and I guess we're talking mostly about DVB-T signals. Is there still > analog TV transmission around, wireless microphones, ...? > > *gnuradio packages on Ubuntu* > > The gnuradio packages that come with Ubuntu 10.04 are most likely a bit > outdated, so you might want to upgrade your laptops to 11.10 first. > > 10.04 contains 3.0.4-2ubuntu1 (http://packages.ubuntu.com/hardy/gnuradio) > 11.10 contains 3.2.2.dfsg-1ubuntu7 ( > http://packages.ubuntu.com/oneiric/gnuradio) > > Once you've got 11.10 with the latest packages installed, you might want > to test your setup with some of the gnuradio examples, like a basic FM > receiver to tune in a local radio station. > > Hope this helps for a start - please let us/me know on the mailing list if > you need more input :) > > Alex > > [1] http://en.wikipedia.org/wiki/White_spaces_(radio) > hi , problem 1 i pugged usrp into usb and run usrp_fft.py and i got signal like noise it's amplitude -60 dB. i also can run usrp_spectrum_sense.py but only numbers of frequencies appeared below each other (min freq and max freq). problem 2 when i plugged out usrp from usb and run usrp_fftw.py again it told me that can not open usrp. and when i try benchmark_tx.py and benchmark_rx.py on the other lap, there is an error appeared told me that can not find module usrp_transmit_path problem 3 - when i write usrp_probe i can not get any info about my usrp1. - when i write uhd_find_devices it told me that: Could not locate USRP1 firmware Please install the images package so from these problems some programs can identify the usrp1 and the other not, so what is happening here. Abdelrahman ahmed egypt,cairo arab academy for science and technology and maritime transport ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] This is nice
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 ! > > http://sdr.osmocom.org/trac/wiki/rtl-sdr > ___ > Discuss-gnuradio mailing list > 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
Re: [Discuss-gnuradio] detecting spectrum holes
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 can take. On 3/21/12, Abdelrahman Ahmed wrote: > 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 spectrum sensing, just out of curiosity, what's your use case? >> >> Are you looking into TV white spaces? [1] >> >> Most likely you'll want to use the USRP1 with WBX because I assume it has >> better sensitivity than TVRX. >> >> Why would you want to transmit anything if you're just looking into >> analyzing spectrum usage in TV channels? >> > > >> >> > >> LP0410 is covering the right frequency band for UHF (400 MHz to 1 GHz), >> but it is a directional antenna. Is that what you want? Otherwise, you >> might be better off using an omni antenna, preferably on a roof... >> >> Here are a few pointers to papers on TV white spaces: >> >> http://www.openspectrum.eu/drupal6/node/23 >> >> I've posted some of the key issues on this list two years ago: >> >> http://www.ruby-forum.com/topic/205328 >> >> Dyspan has some nice papers on spectrum sensing as well: >> >> http://www.ieee-dyspan.org/2010/ >> >> http://cms.comsoc.org/eprise/main/SiteGen/DYSPAN_2010/Content/Home/Technical_and_Policy_Program.html >> >> Now to the setup: >> >> *Hardware / sample data* >> >> I have a USRP1, two WBX, USRP1 N210 and an PC hardware available as well, >> so unless you're in a closed source / NDA environment, we could set up a >> code repository on github, and I could provide you with sample recordings >> from Hong Kong to cross-check detectors. >> >> *Regulatory environment / signals too look for* >> >> What is your location? From your signature, I assume you're in the Middle >> East, and I guess we're talking mostly about DVB-T signals. Is there still >> analog TV transmission around, wireless microphones, ...? >> >> *gnuradio packages on Ubuntu* >> >> The gnuradio packages that come with Ubuntu 10.04 are most likely a bit >> outdated, so you might want to upgrade your laptops to 11.10 first. >> >> 10.04 contains 3.0.4-2ubuntu1 (http://packages.ubuntu.com/hardy/gnuradio) >> 11.10 contains 3.2.2.dfsg-1ubuntu7 ( >> http://packages.ubuntu.com/oneiric/gnuradio) >> >> Once you've got 11.10 with the latest packages installed, you might want >> to test your setup with some of the gnuradio examples, like a basic FM >> receiver to tune in a local radio station. >> >> Hope this helps for a start - please let us/me know on the mailing list if >> you need more input :) >> >> Alex >> >> [1] http://en.wikipedia.org/wiki/White_spaces_(radio) >> > > hi , > problem 1 > > i pugged usrp into usb and run usrp_fft.py and i got signal like noise it's > amplitude -60 dB. > i also can run usrp_spectrum_sense.py but only numbers of frequencies > appeared below each other (min freq and max freq). > > problem 2 > > when i plugged out usrp from usb and run usrp_fftw.py again it told me > that can not open usrp. > and when i try benchmark_tx.py and benchmark_rx.py on the other lap, there > is an error appeared told me that > can not find module usrp_transmit_path > > problem 3 > > - when i write usrp_probe i can not get any info about my usrp1. > - when i write uhd_find_devices it told me that: > > Could not locate USRP1 firmware > > Please install the images package > > so from these problems some programs can identify the usrp1 and the > other not, so what is happening here. > > Abdelrahman ahmed > > egypt,cairo > > arab academy for science and technology and maritime transport > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] detecting spectrum holes
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 erked me. > > We can talk about white space.that I can take. > > > > Oh, I think we all know what is meant by "spectrum holes", even though they don't really exist in the physical world. But any energy entering your receiver that is significantly below the equivalent noise temperature of the receiver would be counted as a "hole"--there may be something there, but it's too weak to matter--modulo schemes that place the instantaneous energy below the "noise floor", like certain types of CDMA systems. And with the magic of integration, you can detect the presence of "signals" that are well below the noise temperature of your receiver. Which is how radio astronomy works. > On 3/21/12, Abdelrahman Ahmed wrote: > >> 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 spectrum sensing, just out of curiosity, what's your use case? >>> >>> Are you looking into TV white spaces? [1] >>> >>> Most likely you'll want to use the USRP1 with WBX because I assume it has >>> better sensitivity than TVRX. >>> >>> Why would you want to transmit anything if you're just looking into >>> analyzing spectrum usage in TV channels? >>> >>> >> >> >>> >>> >> >>> LP0410 is covering the right frequency band for UHF (400 MHz to 1 GHz), >>> but it is a directional antenna. Is that what you want? Otherwise, you >>> might be better off using an omni antenna, preferably on a roof... >>> >>> Here are a few pointers to papers on TV white spaces: >>> >>> http://www.openspectrum.eu/drupal6/node/23 >>> >>> I've posted some of the key issues on this list two years ago: >>> >>> http://www.ruby-forum.com/topic/205328 >>> >>> Dyspan has some nice papers on spectrum sensing as well: >>> >>> http://www.ieee-dyspan.org/2010/ >>> >>> http://cms.comsoc.org/eprise/main/SiteGen/DYSPAN_2010/Content/Home/Technical_and_Policy_Program.html >>> >>> Now to the setup: >>> >>> *Hardware / sample data* >>> >>> I have a USRP1, two WBX, USRP1 N210 and an PC hardware available as well, >>> so unless you're in a closed source / NDA environment, we could set up a >>> code repository on github, and I could provide you with sample recordings >>> from Hong Kong to cross-check detectors. >>> >>> *Regulatory environment / signals too look for* >>> >>> What is your location? From your signature, I assume you're in the Middle >>> East, and I guess we're talking mostly about DVB-T signals. Is there still >>> analog TV transmission around, wireless microphones, ...? >>> >>> *gnuradio packages on Ubuntu* >>> >>> The gnuradio packages that come with Ubuntu 10.04 are most likely a bit >>> outdated, so you might want to upgrade your laptops to 11.10 first. >>> >>> 10.04 contains 3.0.4-2ubuntu1 (http://packages.ubuntu.com/hardy/gnuradio) >>> 11.10 contains 3.2.2.dfsg-1ubuntu7 ( >>> http://packages.ubuntu.com/oneiric/gnuradio) >>> >>> Once you've got 11.10 with the latest packages installed, you might want >>> to test your setup with some of the gnuradio examples, like a basic FM >>> receiver to tune in a local radio station. >>> >>> Hope this helps for a start - please let us/me know on the mailing list if >>> you need more input :) >>> >>> Alex >>> >>> [1] http://en.wikipedia.org/wiki/White_spaces_(radio) >>> >>> >> hi , >> problem 1 >> >> i pugged usrp into usb and run usrp_fft.py and i got signal like noise it's >> amplitude -60 dB. >> i also can run usrp_spectrum_sense.py but only numbers of frequencies >> appeared below each other (min freq and max freq). >> >> problem 2 >> >> when i plugged out usrp from usb and run usrp_fftw.py again it told me >> that can not open usrp. >> and when i try benchmark_tx.py and benchmark_rx.py on the other lap, there >> is an error appeared told me that >> can not find module usrp_transmit_path >> >> problem 3 >> >> - when i write usrp_probe i can not get any info about my usrp1. >> - when i write uhd_find_devices it told me that: >> >> Could not locate USRP1 firmware >> >> Please install the images package >> >> so from these problems some programs can identify the usrp1 and the >> other not, so what is happening here. >> >> Abdelrahman ahmed >> >> egypt,cairo >> >> arab academy for science and technology and maritime transport >> >> > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > >
[Discuss-gnuradio] re： unexpected LookupError using gpsdo
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 recv frame size: 1472 bytes
-- Current send frame size: 1472 bytes
Fetching current settings from EEPROM...
EEPROM ["gpsdo"] is "internal"
Setting EEPROM ["gpsdo"] to "internal"...
Power-cycle the USRP device for the changes to take effect.
I think the congfiure is successful. Then I use the GPS function of my phone,
It works. I think the signal of GPS satellite is also available.
But the lookuperror still exists. Why was that? Dose gpsdo can't be used in
China?
By FengZhu
发件人： "mle...@ripnet.com"
收件人： discuss-gnuradio@gnu.org
发送日期： 2012年3月21日, 星期三, 下午 10:16
主题: Re: [Discuss-gnuradio] unexpected LookupError using gpsdo
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 the things had done, I tried to retrieve the current GPS time by the
>"gps_time" sensor using the codes : " usrp->get_mboard_sensor("gps_time") ".
>The
>compilation is ok and I executived the program. Then an unexpected LookupError
>occured :
>
>
>Error: LookupError: Path not found in tree: /mboards/0/sensors/gps_time
>
>
>I printed all sensor list and there are only two sensor "mimo_locked",
>"ref_locked". So I thought that means The gpsdo was not properly set so that
>the usrp didn't find any "gps_time" sensors. But when I executived the program
>"test_pps_input" at /usr/local/share/uhd/example. The pps seens all right.
>That means the gpsdo is ok. What's more, when I used the reference sources
>provided by an external GPSDO by the code :
>usrp->set_clock_source("external");
>usrp->set_time_source("external");
>It work well too.
>Now I am confused . why is that happen? Was my gpsdo broken? All the two
>gpsdos have the same LookupError.
>
>Thanks for your help.
>
Did you do the post-installation task:
http://files.ettus.com/uhd_docs/manual/html/gpsdo.html#post-installation-task-n-series-only
Also, the "gps_time" is only available once the GPSDO is locked to a GPS
satellite constellation--that's where it gets the time from (and the phase
reference!).
___
Discuss-gnuradio mailing list
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
