[Discuss-gnuradio] about benchmark_rx
hi,evryone i am troubled with running usrp demo. i believe i have configured my ursp correctly because there is data displayed while running usrp_spectrumsense.py. however, when i tried benchmark_rx and benchmark_tx on two computers, i got nothing to indicate that the device was recieving on the rx side : [r...@localhost digital]# ./benchmark_rx.py -f 5G -r 500k db_xcvr2450_rx: __init__ Creating new xcvr2450 instance xcvr2450: __init__ with 48b9d10f: 0 >>> gr_fir_fff: using SSE the program stoped here and waited without an end. on the tx side we can see: [r...@localhost digital]# ./benchmark_rx.py -f 5G -r 500k db_xcvr2450_rx: __init__ Creating new xcvr2450 instance xcvr2450: __init__ with 48b9d10f: 0 >>> gr_fir_fff: using >>> SSE . . . . xcvr2450__del__ this question has already been asked and discussed by others for some time. unfortunately, their advices did not settle my problem. i wonder where benchmark_rx stops and what it is waiting for.so i tracked the codes. my_top_block.wait() in benchmark_rx.py which is defined in the class top_block calls top_block_wait_unlocked() gnuradio_swig_py_runtime.py. the definition of the function is followed: def top_block_wait_unlocked(*args): """top_block_wait_unlocked(gr_top_block_sptr r)""" return _gnuradio_swig_py_runtime.top_block_wait_unlocked(*args) in the head of the file gnuradio_swig_py_runtime.py is import _gnuradio_swig_py_runtime. when i want to learn more about the function _gnuradio_swig_py_runtime.top_block_wait_unlocked(*args), i can just find nothing other than two files, _gnuradio_swig_py_runtime.la and _gnuradio_swig_py_runtime.so, which seem to solve nothing. i have no idea where the definition of _gnuradio_swig_py_runtime.top_block_wait_unlocked(*args) is. and i would also appreciate it if anyone can share anything about using benchmark_rx/tx. thanks in advance! philips.c.c ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Marvell Yukon 88E8039 PCI-E Ethernet - USRP2
On Wednesday 31 December 2008 02:37:37 Eric Blossom wrote: > Google tells me that the Marvell Yukon 88E8039 PCI-E Ethernet > controller is a "Fast Ethernet" card; that is 100Mbit, not 1000Mbit. > > The USRP2 requires gigabit ethernet. The 'msk' man page in FreeBSD says it's GigE. Maybe it's not negotiating properly though.. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Info on Ciao Radio
There is someone using Gnu Radio software with Ciao Radio, an Italian SDR (see: http://www.comsistel.com/Ciao%20Radio.htm) for HF rx. Software for this SDR is Windows only and I will use it on my Linux box. On Users Group for this SDR there is no Linux users. On same Users Group there is a description of sw protocol for sending messages to radio and also a C++ set of routines for this job. I am not a software developer but I hnow Python. Can I try some function for initially getting info and signal? Regards Franco ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Tuning issues with DBS RX at 900MHz
Hey all I've got a USRP with a DBS RX that I'm trying to tune to an NTSC signal centered at 909MHz, 6MHz wide (confirmed on a spectrum analyzer). In order to get a usable signal out of the usrp for this, I have to turn down to 905MHz, which is outside of where the source is broadcasting (analyzer shows this is dead air). Looking at similar signals in this range, I always have to tune down 4MHz. I've messed with setting lo_offset to different values with no changes in my results, tho I havnt found where to pull the current lo_offset value from yet (a call to subdev.lo_offset() always yields 0.0). With the same daughter board, I get different results across the bands. A 1.2GHz signal I can pick up at 1.2GHz, just as it should be. An NTSC signal that should be at 2.4895GHz I need to tune to 2.492 GHz to get a usable signal. I realize the DBS RX isn't speced that high, but the signal I'm getting out of the Flex Rx (Flex 2400 Rx Mimo B) is filled with a bunch of high freq noise rendering the signal almost entirely unusable (havnt gotten to looking at why that is yet). Any ideas? I believe I'm still running gnuradio from the revision before gsl was introduced as a dependency. Perhaps this has been fixed if it actually is a bug. I'm building up the latest code now and will test to see if everything is magically sane. Thanks ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Marvell Yukon 88E8039 PCI-E Ethernet - USRP2
On Tue, Dec 30, 2008 at 07:36:41AM +0100, Changkyu Seol wrote: > > Hi > > I recently installed fedora 9 and GNU radio on laptop computer (COMPAQ > Presario V3700, Marvell Yukon 88E8039 PCI-E Ethernet) but USRP2 is not > recognized. (Running "find_usrp" keeps printing "No USRP2 found.") I > have been using USRP2 with other desktop PCs and laptop PCs and I think > there is no problem with USRP2 nor with ethernet on the laptop PC. (I am > using latest GNU radio in trunk and updated FPGA progamming file and > firmware.) I suspect that the problem is that USRP2 is incompatible with > the ethernet. Is there anyone who succeeded in working USRP2 with > "Marvell Yukon 88E8039 PCI-E Ethernet?" Is there anything that I can try > to get those working? Any comments would be appreciated. > > Changkyu Seol > -- Google tells me that the Marvell Yukon 88E8039 PCI-E Ethernet controller is a "Fast Ethernet" card; that is 100Mbit, not 1000Mbit. The USRP2 requires gigabit ethernet. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Some usrp_spectrum_sense.py code Explanation
Hi, > --- On Tue, 12/30/08, Ling Huang wrote: > Hi, Firas > In my opinion the ouput Y[i] has the same dimension with > the power. If we square root the output, and divide it with the fft bin > numbers, then we get the voltage magnitude. Am I right? > > Best Regards, > Ling Yes, If we square root the output, and divide it with the fft size, then we will get the voltage magnitude. Calculating 20 Log10 this value will give us the power. Best Regards, Firas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Some usrp_spectrum_sense.py code Explanation
Interrupting Output Spectrum - The actual mapping from the levels at the daughterboard antenna input port to the output analysis values depends on a lot of factors including the used daughterboard RF gain and decimation specific gain in the digital down converter. You'll need to calibrate the system if you need something that maps to dBm.Currently, the output of usrp_spectrum_sense is the magnitude squared of the FFT output. That is, for each FFT bin[i], the output is Y[i] = re[X[i]]*re[X[i]] + im[X[i]]*im[X[i]]. If you want power, take the square root of the output. Hi, Firas In my opinion the ouput Y[i] has the same dimension with the power. If we square root the output, and divide it with the fft bin numbers, then we get the voltage magnitude. Am I right? Best Regards, Ling -- View this message in context: http://www.nabble.com/Some-usrp_spectrum_sense.py-code-Explanation-tp21209623p21214158.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
