Re: [Discuss-gnuradio] Problem in usable Python.h header file.
Tarun Tiwari wrote: Hi, I am installing GNU Radio 3.0 on Linux Mandriva Official 2007.0, when I am trying to do ./configure I receive an error like unable to find usable Python.h header file I found my Python.h file is in /usr/local/include/python2.4 whereas . /configure command alwasy look for /usr/linclude/python2.4 I used export PYTHONPATH=/usr/local/include/python2.4 but that is not working. Can someone tell me where is the problem, and what do i need to do to resolve this issue? Thank you. Tarun Mani Tiwari ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio Python 2.4 did not work with GNU Radio 2.8 (so we used 2.3). I'm not sure if it works with 3.0 or not. You may want to try Python 2.3. Thanks, Written -- View this message in context: http://www.nabble.com/Problem-in-usable-Python.h-header-file.-tf2465188.html#a6875929 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
[Discuss-gnuradio] SDR Hardware Functions
All, In using usrp_rx_cfile.py, I pull complex I and Q data off of the USRP. I was wondering if this data is handled in any analog fashion in the mixed signal processor, or if the data is only handled in the FPGA. To be specific, I want to know if, when using the GNU Radio USRP functions (like those called by usrp_rx_cfile.py), if the USRP is behaving as a TRUE software-defined radio, or if any filtering or other such software-implementable functions are instead being handled by the hardware on the USRP itself I may not have my understanding of the way the hardware handles signals quite correct, but hopefully it's coherent :) Thanks, Written -- View this message in context: http://www.nabble.com/SDR-Hardware-Functions-tf2460074.html#a6856884 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
[Discuss-gnuradio] SVN account
All, I am using TortoiseSVN for Windows, and upon entering the URL http://gnuradio.org/svn/usrp-hw/trunk;, I am asked for a username and password. I couldn't find any way to register an account on http://gnuradio.utah.edu/trac, either. What do I do? Thanks, Written -- View this message in context: http://www.nabble.com/SVN-account-tf2438706.html#a6800502 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] SVN account
I had tried blank fields previously, but now I tried with a '/' at the end of the URL, but none of it worked. Thanks, Written Johnathan Corgan wrote: Written wrote: I am using TortoiseSVN for Windows, and upon entering the URL http://gnuradio.org/svn/usrp-hw/trunk;, I am asked for a username and password. The repository allows anonymous read-only access, so please try (if you haven't already) a blank name and password field. I don't know if TortoiseSVN allows this, though. You might also try adding a '/' to the end of your URL, though this is guesswork on my part. I couldn't find any way to register an account on http://gnuradio.utah.edu/trac, either. There isn't. Only developers with check-in privileges need an account. --- Johnathan Corgan, AE6HO [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://www.nabble.com/SVN-account-tf2438706.html#a6801300 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] SVN account
Well, I guess I didn't know what I'm doing... I was previously trying TortoiseSVN - Import, but when I just tried SVN Checkout, it worked fine. Sorry about that, Written Matt Ettus wrote: Written wrote: I had tried blank fields previously, but now I tried with a '/' at the end of the URL, but none of it worked. Are you behind a firewall? That blocks DAV? Also, can you try the command line client? Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://www.nabble.com/SVN-account-tf2438706.html#a6801803 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] Help getting started
Hi Dan, What daughterboards are you using? Thanks, Written Dan Halperin wrote: Hi all, I'm just beginning grad school and trying to get my USRP board up and running so I can start playing. I've tested our equipment on two different machines now; one an older box running FC4, 512MB ram, with an Intel(R) Celeron(R) CPU 2.40GHz. I've also tried one on a newer laptop (compaq v3000 series) running Gentoo Linux, with 2GB of memory. I've had /all kinds/ of interesting phenomena: I first tried installing the way on the old wiki http://www.comsec.com/wiki?UniversalSoftwareRadioPeripheral (first link on Google for USRP), and then again using the new say (svn source checkout using the instructions on the new wiki), on both machines. On the older machine, I don't get any rx/tx over/underruns (or maybe just one when initializing) and a throughput of 32MB/s in both directions, and on the laptop I get exactly 41 under/over runs with a throughput of ~31MB/s in the RX direction and around 24 in the TX direction. As far as I could tell, these used the same version of the source, but then again the SVN repository has jumped from rev. 3772 to rev. 3785 since yesterday morning. Anyway, installation, make check, and the ./test_standard_?x scripts work fine (the LED behaves as expected and the benchmarks seem reasonable), however I get nothing when running the usrp_oscope or usrp_wfm_rcv scripts as directed in the instructions. Both dial tone scripts work fine, by the way. The scope and FM receive scripts run fine, but I hear just hear/see static. If I set the oscope to 900MHz and bring my cordless 900MHz phone around, there's no change in the scope. If I can the entire FM spectrum in the other script, I don't get anything but static anywhere. My little portable CD player can hear the radio just fine in this lab, so I figure the foot-long copper antenna that came with the USRP ought to as well. I don't know a lot about communications... Also, the different test_digital_loopback and test_counting scripts seem to not work very well at all. I don't know if they're expected to, but about 50% of the tests that look vaguely expected 517, got 0 fail. Is there any advice you can offer as to how to determine what, if anything, is wrong here? Thanks, Dan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://www.nabble.com/Help-getting-started-tf2432797.html#a6784198 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] Help getting started
Well, I've never used the TX boards before, but looking through the files I found fm_tx.py, which makes narrow band fm. You may have to use usrp_nbfm_rcv.py (or whatever it's called) to pick it up, but now I'm just guessing. -Written Dan Halperin wrote: Fair enough; I figured since my officemate's pocket CD player could pick up FM radio the big ole' antenna ought to be able to. Is there a script to make a custom FM station using a BasicTX board (I have another USRP if necessary) to get around that problem? -Dan Written wrote: Well, all I can think of is using the basic rx daugtherboard along with usrp_wfm_rcv.py and tuning to some local FM stations, or using the scope, but it sounds like you've already done that pretty much. Make sure the gain on the scope is set to about mid-point for the specific daughterboard being used. I had the best luck with this. Depending on your scanning bandwidth, I don't know if you'll actually pick up any listenable stations, so I'd just use the aforementioned file for FM testing purposes. Written Dan Halperin wrote: I've used the 2.4GHz RX/TX board, but I have since been using the Basic RX and Basic TX boards. -Dan Written wrote: Hi Dan, What daughterboards are you using? Thanks, Written Dan Halperin wrote: Hi all, I'm just beginning grad school and trying to get my USRP board up and running so I can start playing. I've tested our equipment on two different machines now; one an older box running FC4, 512MB ram, with an Intel(R) Celeron(R) CPU 2.40GHz. I've also tried one on a newer laptop (compaq v3000 series) running Gentoo Linux, with 2GB of memory. I've had /all kinds/ of interesting phenomena: I first tried installing the way on the old wiki http://www.comsec.com/wiki?UniversalSoftwareRadioPeripheral (first link on Google for USRP), and then again using the new say (svn source checkout using the instructions on the new wiki), on both machines. On the older machine, I don't get any rx/tx over/underruns (or maybe just one when initializing) and a throughput of 32MB/s in both directions, and on the laptop I get exactly 41 under/over runs with a throughput of ~31MB/s in the RX direction and around 24 in the TX direction. As far as I could tell, these used the same version of the source, but then again the SVN repository has jumped from rev. 3772 to rev. 3785 since yesterday morning. Anyway, installation, make check, and the ./test_standard_?x scripts work fine (the LED behaves as expected and the benchmarks seem reasonable), however I get nothing when running the usrp_oscope or usrp_wfm_rcv scripts as directed in the instructions. Both dial tone scripts work fine, by the way. The scope and FM receive scripts run fine, but I hear just hear/see static. If I set the oscope to 900MHz and bring my cordless 900MHz phone around, there's no change in the scope. If I can the entire FM spectrum in the other script, I don't get anything but static anywhere. My little portable CD player can hear the radio just fine in this lab, so I figure the foot-long copper antenna that came with the USRP ought to as well. I don't know a lot about communications... Also, the different test_digital_loopback and test_counting scripts seem to not work very well at all. I don't know if they're expected to, but about 50% of the tests that look vaguely expected 517, got 0 fail. Is there any advice you can offer as to how to determine what, if anything, is wrong here? Thanks, Dan ___ 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 -- View this message in context: http://www.nabble.com/Help-getting-started-tf2432797.html#a6785003 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] J. Cooley's 3-D waterfall display
Would someone please look at this? Furthermore, I imagine that many Gnu Radio users would like to be able to perform 3-dimensional FFT displays. -Written Written wrote: All, Mr. Cooley wrote this code sometime early last year, and unfortunately something in the gnuradio or wxgui code has changed, and this code is no longer operable. The error I got in trying to run it with gnuradio 2.8 is: gnuradio_swig_python.py expects a std::vectorfloat,std::allocatorfloat I had an email exchange with Mr. Cooley, and he would like to fix his code, so any effort would be appreciated in that. And, as he said in our exchange, Now that I think about it, the waterfall Python OpenGL code that I did was based largely upon the similar wxgui-based fft. So, following the format of the wxgui versions may help lead you to the right functional calls, and get the right calls on the GnuRadio side. http://alumni.media.mit.edu/~jcooley/gr_experiments/experiments/fft_3d_time/gr_3d_fft_time.htm J. Cooley's site -- View this message in context: http://www.nabble.com/J.-Cooley%27s-3-D-waterfall-display-tf2388233.html#a6721235 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
[Discuss-gnuradio] J. Cooley's 3-D waterfall display
All, Mr. Cooley wrote this code sometime early last year, and unfortunately something in the gnuradio or wxgui code has changed, and this code is no longer operable. The error I got in trying to run it with gnuradio 2.8 is: gnuradio_swig_python.py expects a std::vectorfloat,std::allocatorfloat I had an email exchange with Mr. Cooley, and he would like to fix his code, so any effort would be appreciated in that. And, as he said in our exchange, Now that I think about it, the waterfall Python OpenGL code that I did was based largely upon the similar wxgui-based fft. So, following the format of the wxgui versions may help lead you to the right functional calls, and get the right calls on the GnuRadio side. http://alumni.media.mit.edu/~jcooley/gr_experiments/experiments/fft_3d_time/gr_3d_fft_time.htm J. Cooley's site -- View this message in context: http://www.nabble.com/J.-Cooley%27s-3-D-waterfall-display-tf2388233.html#a6657892 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
[Discuss-gnuradio] gnuradio code at a moment in time
All, I was wondering if there is any way to get all contemporary versions of gnuradio-essential code (gnuradio-core, gr-usrp, gr-wxgui, usrp) at any given time in its history. Put another way, I want to time travel and pretend today is February 15, 2005 (for example). How then could I download all of the latest versions of these files, as they were on Feb. 15, 2005? I also don't have access to the internet via my Linux box, so this will have to be done from Windows. Thanks a bunch, -Written -- View this message in context: http://www.nabble.com/gnuradio-code-at-a-moment-in-time-tf2358870.html#a6571489 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] USRP access via sockets
I don't know how much it helps my overall problem, but I found a site that has some files that helped me get my bearings. I am able to play the USRP radio on one computer by running a client program on another one. Here's the site: http://alumni.media.mit.edu/~jcooley/gr_experiments/experiments/gr_socket.htm Still, any advice on this matter is appreciated. -- View this message in context: http://www.nabble.com/USRP-access-via-sockets-tf2223875.html#a6199704 Sent from the GnuRadio forum at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP access via sockets
After a little debugging, I found where exactly the pipe seems to break. Please forgive the redundancy to follow, those of you who are already familiar with the gnuradio graph class hierarchy. AFTER the socket connection between the two computers is established: 1.) usrp_rx_cfile.my_graph.run() is called, and usrp_rx_cfile.__init__ is progressed through 2.) then at the end of it, flow_graph.run() is called. ( located in /usr/local/lib/python2.3/...(etc).../gr/flow_graph.py ) 3.) Control goes to flow_graph, and scheduler.py is called via self.scheduler.start() 4.) and at line 57 in scheduler.py, thread.start() is called. After it is called (probably sometime during it, rather), the pipe breaks. I don't know Python very well, and I am not proficient at network programming. Any help is appreciated. Sorry I cannot easily post output to the forum; this LAN is isolated from the internet. Written Eric Blossom wrote: On Tue, Sep 05, 2006 at 03:50:12PM -0700, Written wrote: Hello again, Here is my setup. I have a Debian Sarge linux LAN isolated from the outside world. I have the USRP hooked up to one computer, and I am trying to have that computer feed another computer data via Python sockets. On the computer being fed (the one WITHOUT the USRP), I am running a program very similar to usrp_fft.py. This program, instead of accessing the USRP directly, accepts data from gr.file_descriptor_source AFTER I have established a socket with the computer feeding this one the data. As for the feeding computer, it is running usrp_rx_cfile.py with the sink, instead of gr.file_sink, is now gr.file_descriptor_sink. This computer is listening for the other computer in order to create a connection with it. Then, for the actual process: I run the feeding computer, then run the computer being fed, but there is an error. The feeding computer starts listing the USRP data (Rev number, etc.), but then it says gr.file_descriptor_sink: broken pipe. It's almost certain that the file handle corresponding to the file descriptor you are using has gone out of scope and thus has been closed. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://www.nabble.com/USRP-access-via-sockets-tf2223875.html#a6181035 Sent from the GnuRadio forum at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP access via sockets
Hello again, Here is my setup. I have a Debian Sarge linux LAN isolated from the outside world. I have the USRP hooked up to one computer, and I am trying to have that computer feed another computer data via Python sockets. On the computer being fed (the one WITHOUT the USRP), I am running a program very similar to usrp_fft.py. This program, instead of accessing the USRP directly, accepts data from gr.file_descriptor_source AFTER I have established a socket with the computer feeding this one the data. As for the feeding computer, it is running usrp_rx_cfile.py with the sink, instead of gr.file_sink, is now gr.file_descriptor_sink. This computer is listening for the other computer in order to create a connection with it. Then, for the actual process: I run the feeding computer, then run the computer being fed, but there is an error. The feeding computer starts listing the USRP data (Rev number, etc.), but then it says gr.file_descriptor_sink: broken pipe. Any suggestions or comments? Thanks a bunch, Written -- View this message in context: http://www.nabble.com/USRP-access-via-sockets-tf2223875.html#a6161917 Sent from the GnuRadio forum at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
