Re: [Discuss-gnuradio] More on latency
On Thu, Oct 21, 2010 at 12:41:16AM -0400, Marcus D. Leech wrote: I had a flow-graph that earlier today had a latency of roughly 1 second or so. When I tested it this evening, after it had been running for several hours, the latency was back up to *several tens of seconds*!!!. Which means that external events at the source take several tens of seconds to show up at the sinks -- two graphical, and one filesink. WTF? !! The CPU load at the time was modest -- about 38% 38% of what? How many cores? What kind of machine? It's possible that there's a computation in a single block that requires 1 core to compute in realtime. Have you tried oprofile to see where the graph is spending its time? Are you i/o bound? What's the rate that you're writing to the file sink? I believe htop will show you all the threads of the process. Are any of them consuming on the order of 100% of a single core? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] More on latency
On 10/21/2010 02:10 AM, Eric Blossom wrote: On Thu, Oct 21, 2010 at 12:41:16AM -0400, Marcus D. Leech wrote: I had a flow-graph that earlier today had a latency of roughly 1 second or so. When I tested it this evening, after it had been running for several hours, the latency was back up to *several tens of seconds*!!!. Which means that external events at the source take several tens of seconds to show up at the sinks -- two graphical, and one filesink. WTF? !! The CPU load at the time was modest -- about 38% 38% of what? How many cores? What kind of machine? A dual-core machine, an Atom D-510 It's possible that there's a computation in a single block that requires 1 core to compute in realtime. Unlikely. The most computey block is a 1024-bin FFT, and my sample rate is only 400Ksps. There's also an FFT filter, but it typically has only about 40-45 taps. Have you tried oprofile to see where the graph is spending its time? Are you i/o bound? What's the rate that you're writing to the file sink? I'm writing to the file sink at 1Ksps. There's also an audio sink, I'm using the plughw:0,0 device, and it's being pumped at 20Ksps, which generally divides my source rate exactly. I tried turning off that sub-tree the other night, but I didn't let it run very long. Perhaps a residual clock-rate mis-match is causing 'buffer creep', and after a few hours, that 'buffer creep' has grown to several-10s of seconds? I believe htop will show you all the threads of the process. Are any of them consuming on the order of 100% of a single core? Eric Hmm, have to check that. OK, just installed 'htop' and there's no single thread that's chewing on near 100% of a cpu. The top two threads peak at around 70% and 30%, but average somewhat less than that. -- 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
Re: [Discuss-gnuradio] Error when installing Boost
Use a package manager like yum, apt-get etc. and install boost-devel. Actually make sure you have all the dependencies listed in the README file in the GNURadio tarball you have downloaded and trying to build from. Instructions to do this (and distribution specific instructions) are provided here, and clearly.. http://gnuradio.org/redmine/wiki/gnuradio/BuildGuide. For e.g yum install gnu-radio usrp on Fedora would do everything for you to get your hello world program i.e dial_tone.py working! On Wed, Oct 20, 2010 at 10:40 PM, ish13 ish2...@gmail.com wrote: I am new at this. But I was just following the instructions that are on the wiki page. It said that boost needed to be installed. So I was following the steps and I ran into the error message. Which approach am I supposed to take to complete the installation of gnu radio. Ismael Eric Blossom wrote: On Wed, Oct 20, 2010 at 04:47:47PM -0700, ish13 wrote: I get an error with I use ./configure when I am installing boost. The following commands are entered in the terminal when I am installing. Why are you building boost? It's packaged for pretty much every reasonably modern distribution. cd boost_1_44_0 BOOST_PREFIX=/opt/boost_1_44_0 ./tools/jam/src/boehm_gc/configure --prefix=$BOOST_PREFIX --with-libraries=thread,date_time,program_options confchecking if f77 PIC flag -fPIC works... yes checking if f77 static flag -static works... yes checking if f77 supports -c -o file.o... yes checking whether the f77 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... /usr/bin/f77: Illegal option: -print-search-dirs GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking sys/dg_sys_info.h usability... no checking sys/dg_sys_info.h presence... no checking for sys/dg_sys_info.h... no checking whether Solaris gcc optimization fix is necessary... no checking atomic_ops.h usability... no checking atomic_ops.h presence... no checking for atomic_ops.h... no configure: error: Missig libatomic_ops. Can someone help? Thanks Ismael ___ 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/Error-when-installing-Boost-tp30015069p30016337.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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Questions on multiple outputs and produce()
Hi list, Since the API for gr_blocks with multiple outputs was changed a bit with version 3.3.0, I have a couple of questions. 1) The return value for general_work() is no longer relevant for the number of produced output items. Does this eliminate the need to produce all output values at the same rate? 2) If I still want to (or have to) produce all output items at the same rate, wouldn't it be great to have a produce_all() member function, analogous to consume_all()? Is it just waiting to be patched in, or if not, what's the rationale for not including it? 3) If it's possible to produce output at different rates, how does forecast() work? IIUC, forecast() returns the number of input items on every input stream to produce noutput_items output items. But for which output stream is this valid? On a similar note, what meaning does noutput_items in general_work() have? Hmm... MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-3790 Fax: +49 721 608-6071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpi7HwUvQroV.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] More on latency
On Thu, Oct 21, 2010 at 02:23:20AM -0400, Marcus D. Leech wrote: On 10/21/2010 02:10 AM, Eric Blossom wrote: On Thu, Oct 21, 2010 at 12:41:16AM -0400, Marcus D. Leech wrote: I had a flow-graph that earlier today had a latency of roughly 1 second or so. When I tested it this evening, after it had been running for several hours, the latency was back up to *several tens of seconds*!!!. Which means that external events at the source take several tens of seconds to show up at the sinks -- two graphical, and one filesink. WTF? !! The CPU load at the time was modest -- about 38% 38% of what? How many cores? What kind of machine? A dual-core machine, an Atom D-510 It's possible that there's a computation in a single block that requires 1 core to compute in realtime. Unlikely. The most computey block is a 1024-bin FFT, and my sample rate is only 400Ksps. There's also an FFT filter, but it typically has only about 40-45 taps. Have you tried oprofile to see where the graph is spending its time? Are you i/o bound? What's the rate that you're writing to the file sink? I'm writing to the file sink at 1Ksps. There's also an audio sink, I'm using the plughw:0,0 device, and it's being pumped at 20Ksps, which generally divides my source rate exactly. I tried turning off that sub-tree the other night, but I didn't let it run very long. Perhaps a residual clock-rate mis-match is causing 'buffer creep', and after a few hours, that 'buffer creep' has grown to several-10s of seconds? Yes, that would cause it. I've seen it with the FM receiver apps. BTW, it would have been useful to tell us that there was an audio sink in the graph when you first posted the observation. Thanks, Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on multiple outputs and produce()
On Thu, Oct 21, 2010 at 05:06:26PM +0200, Martin Braun wrote: Hi list, Hi Martin! Since the API for gr_blocks with multiple outputs was changed a bit with version 3.3.0, I have a couple of questions. 1) The return value for general_work() is no longer relevant for the number of produced output items. It's still relevant, unless it has the value WORK_CALLED_PRODUCE (I just noticed that the docs for general_work were not updated to reflect this change. Sorry about that.) Does this eliminate the need to produce all output values at the same rate? Yes. That was the reason for the change. 2) If I still want to (or have to) produce all output items at the same rate, wouldn't it be great to have a produce_all() member function, analogous to consume_all()? Is it just waiting to be patched in, or if not, what's the rationale for not including it? To preserve the original behavior, non-negative values of the return value are treated as they were before, in effect calling produce_all. 3) If it's possible to produce output at different rates, how does forecast() work? IIUC, forecast() returns the number of input items on every input stream to produce noutput_items output items. But for which output stream is this valid? On a similar note, what meaning does noutput_items in general_work() have? None of the behavior (or implementation) of those routines has changed. Thus, for any given value of noutput_items, there is guaranteed to be enough output buffer space on each output stream to hold noutput_items. Probably the easiest way to think about this, is that it allows you to return fewer results on one or more output streams than the number returned on the stream returning the maximum number of output streams. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on multiple outputs and produce()
On Thu, Oct 21, 2010 at 09:11:50AM -0700, Eric Blossom wrote: None of the behavior (or implementation) of those routines has changed. Thus, for any given value of noutput_items, there is guaranteed to be enough output buffer space on each output stream to hold noutput_items. Probably the easiest way to think about this, is that it allows you to return fewer results on one or more output streams than the number returned on the stream returning the maximum number of output streams. As usual, thanks for the helpful answer! That clears it all up, I thought I'd found an inconsistency in the API--a fix to the docs would still be great, though. Cheers, MB -- Karlsruhe Institute of Technology (KIT) Communications Engineering Lab (CEL) Dipl.-Ing. Martin Braun Research Associate Kaiserstraße 12 Building 05.01 76131 Karlsruhe Phone: +49 721 608-3790 Fax: +49 721 608-6071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgp5zMtRAlski.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] More on latency
On 10/21/2010 11:41 AM, Eric Blossom wrote: Yes, that would cause it. I've seen it with the FM receiver apps. Any hint about how to cure this problem? I'm perfectly willing to have the audio sink drop samples from time to time in order to prevent/dramatically-reduce buffer creep. How do Linux audio apps deal with this in digital recording studio cases? Where they may have audio inputs/outputs from/to different cards, with unsynchronized clocks, etc? I have *another* GNURadio app, which uses an audio input and an audio output, on different cards. It has been running for several days, and the latency is roughly 1sec. The machine it is running on is a Pentium D dual-core, at 2.4/3.2GHz. Probably 30% more ooomph than the D-510 that is running the other app. Btw, I started the app on the D-510 and let it run overnight. The latency this morning is roughly the same as it was last night when I started it--about 1 to 1.5second. So, I wonder what the condition is that causes buffer creep to become really large? BTW, it would have been useful to tell us that there was an audio sink in the graph when you first posted the observation. Actually, in the first instance, a few days ago, I did. It was an oversight in this most recent post series. Sorry. Thanks, Eric -- 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] GNU Radio meetup at the 2010 SDR Technical Conference, Washington, DC
GNU Radio community, We will be holding a GNU Radio meetup at the SDR Technical Conference on Wednesday, December 1 at 7:30 in the Hyatt Regency Crystal City. Meeting room TBA. For those of you who made it last year, it will be a similar event. Matt Ettus and myself will be there with Ettus Research, LLC sponsoring food and beverages. This is a time for people involved in the community to get to know each other a bit better and share their work and ideas. I'll take some time to provide everyone present with some of our ideas for the future of the project and Matt will be sharing some of his plans for Ettus Research. Importantly, though, I would really love to hear back from all of you about what work you're doing as well as thoughts on the project. We will have 1.5 hours for discussion, including some time at the beginning for food and some informal introductions. For the bulk of it, I would really like to get some good discussion going about GNU Radio and its applications. So please come prepared to share! We will likely head out to a local bar for around 9PM to continue the discussions over beer. This year, we are going to be more formally a part of the SDR Conference, and as such, the organizers of the conference have asked for people to register. You have a few options for registering, including the free option. I will be attending all week and have a presentation on Tuesday as part of an Open Source Software panel session put together by Phil Balister as well as a tutorial on GNU Radio on Thursday. Matt will be there as an exhibitor during the entire conference. That's just to let you know some of the activities going on during the full conference. You can find more here: http://conference.wirelessinnovation.org/ To register, you can see the different options here: http://conference.wirelessinnovation.org/mc/page.do?sitePageId=118975orgId=s1 I apologize for the timing of this email. I realize now that I should have gotten it out sooner since tomorrow is the cut-off of the early registration deadline. Anyway, the organizers are asking people to register, even if that's just the Exhibitors and Exhibits Only Attendee, which is free for pre-registration or $50 for on-site registration. Location information: For those not familiar with the DC area, Crystal City is just south of DC (technically in Arlington, VA) on Rt. 1. Here's the map: http://goo.gl/maps/itPK The bar we will most likely be going to is Bailey's Sports Grill (or The Fox and Hound, depending on where you look). It's a decent pub with a large selection of beer, and I think we all had a pretty good time there last year. Note that this is the one on Crystal City Dr, not Wilson Blvd. http://goo.gl/maps/uaXi RSVP: It's not necessary to tell me that you're coming, but it would help us to get a feel for the amount of food we should plan on. Thanks! And I look forward to seeing many of you there! Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] More on latency
Jack, what a nightmare. I user it to send audio from my ubuntu server to macbook. Used ssh to access gui. According to the docs this is how they deal with sync. 2 soundcards... http://trac.jackaudio.org/wiki/WalkThrough/User/NetJack2 You probably know that if you take two computers, and make them run an audio software, or a Jack server at a given sample rate, they are obviously not running exactly at the same sample rate. That is because they don't have exactly the same master clock. This is the greatest inconvenience that all the digital audio world has ever fought. In the Netjack system, no problem of synchronization because the slave isn't running an audio hardware. It's simply led by a network stream. the incoming stream delivers 64 frames, for example, so the slave have to deal with those 64 frames, then send back 64 frames. There is no other time consideration than the master's cycle last. But if you want to make these 64 frames goes to an audio hardware, you will have to resample because the master's cycle duration will not fit to the new arbitrary slave's. Master and slave have no other way of syncing each other (except for hardware which includewordclock or some other kind of wired sync). Netjack2 includes a system allowing to resample the network stream to send it on a piece of audio hardware. This is done using an in server client called audioadapter. After the slave has been started using the net backend, load the audioadapter client using jack_load: Sent from my iPad On Oct 21, 2010, at 1:46 PM, Nick Foster n...@ettus.com wrote: On Thu, 2010-10-21 at 13:11 -0400, Marcus D. Leech wrote: On 10/21/2010 11:41 AM, Eric Blossom wrote: Yes, that would cause it. I've seen it with the FM receiver apps. Any hint about how to cure this problem? I'm perfectly willing to have the audio sink drop samples from time to time in order to prevent/dramatically-reduce buffer creep. How do Linux audio apps deal with this in digital recording studio cases? Where they may have audio inputs/outputs from/to different cards, with unsynchronized clocks, etc? The cure is to provide a resampling block inside the sink, and to dynamically set its fractional rate based on the buffer consumption of the sink. This is on my todo list for the JACK sink. I'm starting with the JACK sink because the JACK API is the only one that provides detailed info on buffer state. It's possible that ALSA also provides useful information; it's hard to say because of the incomprehensibility of the ALSA API. I haven't looked that hard. I'm not sure that most digital recording studio applications have the capability of reading from one audio card and writing directly to another. If they do, they must have some way of resampling data to match sample rates. I have *another* GNURadio app, which uses an audio input and an audio output, on different cards. It has been running for several days, and the latency is roughly 1sec. The machine it is running on is a Pentium D dual-core, at 2.4/3.2GHz. Probably 30% more ooomph than the D-510 that is running the other app. Btw, I started the app on the D-510 and let it run overnight. The latency this morning is roughly the same as it was last night when I started it--about 1 to 1.5second. So, I wonder what the condition is that causes buffer creep to become really large? Hard to say. It could be that on that machine the audio card's clock is very close to what it's supposed to be; e.g., its 44100Hz is really 44100Hz. BTW, it would have been useful to tell us that there was an audio sink in the graph when you first posted the observation. Actually, in the first instance, a few days ago, I did. It was an oversight in this most recent post series. Sorry. Thanks, Eric ___ 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] Import Error with howto module
Hello, I am an RF engineer who is just starting to play around with Linux and gnuradio for fun. I have been successfully making some simple applications work on my USRP2. I would like to write my own DSP blocks and when I try to import the howto module into another python program I get: *Traceback (most recent call last): File USRP2_FFT.py, line 5, in module from gnuradio import gr, gru, eng_notation, usrp2, blks2, howto ImportError: cannot import name howto* I downloaded the gr-howto-write-a-block-3.3.0 file and did the following successfully: *cd gnuradio/gr-howto-write-a-block-3.3.0 ./bootstrap ./configure sudo make sudo make check sudo make install* At someone's suggestion I also did the following in the gr-howto-write-a-block-3.3.0 successfully: *cd lib sudo make install sudo make check cd .. cd python sudo make install sudo make check* What else do I need to do to be able to use the howto module? Thanks, Mike ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] question about UCLA zigbee libraries problem
Hi everyone I installed both of Gnuradio and UCLA Zigbee on ubuntu 9.04, and I have this problem the install path of UCLA zigbee libraries is by default /usr/local/lib/python2.6/site-packages/gnuradio but others gnuradio libraries are in /usr/lib/python2.6/site-packages/gnuradio., I saw in the gnuradio mailing list that one of the member ( Daniele Bertussi) had this problem before and he was able to solve it Please can he or anybody tell me how to solve it? Thank you ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] question about UCLA zigbee libraries problem
On 10/21/2010 04:56 PM, harvy samir wrote: Hi everyone I installed both of Gnuradio and UCLA Zigbee on ubuntu 9.04, and I have this problem the install path of UCLA zigbee libraries is by default /usr/local/lib/python2.6/site-packages/gnuradio but others gnuradio libraries are in /usr/lib/python2.6/site-packages/gnuradio., I saw in the gnuradio mailing list that one of the member ( Daniele Bertussi) had this problem before and he was able to solve it Please can he or anybody tell me how to solve it? That shouldn't be a problem. Either set your environment variables like PYTHONPATH appropriately or configure your software with the same --prefix. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Import Error with howto module
On 10/21/2010 01:53 PM, Michael Civerolo wrote: Hello, I am an RF engineer who is just starting to play around with Linux and gnuradio for fun. I have been successfully making some simple applications work on my USRP2. I would like to write my own DSP blocks and when I try to import the howto module into another python program I get: *Traceback (most recent call last): File USRP2_FFT.py, line 5, inmodule from gnuradio import gr, gru, eng_notation, usrp2, blks2, howto ImportError: cannot import name howto* I downloaded the gr-howto-write-a-block-3.3.0 file and did the following successfully: *cd gnuradio/gr-howto-write-a-block-3.3.0 ./bootstrap ./configure sudo make sudo make check sudo make install* Where did make install put the python files? Set your PYTHONPATH environment variable appropriately. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Moon Bounce Experiment
On Oct 20, 2010, at 11:19 PM, Marcus D. Leech wrote: On 10/21/2010 01:02 AM, Joseph Craig wrote: On Oct 20, 2010, at 7:07 PM, Eric Blossom wrote: On Wed, Oct 20, 2010 at 06:49:21PM -0600, Joseph Craig wrote: Hi Marcus, Thanks for the quick reply... On Oct 20, 2010, at 5:51 PM, Marcus D. Leech wrote: On 10/20/2010 07:13 PM, Joseph Craig wrote: I have managed to install gnuradio and run usrp_fft.py with success! Now for the questions... 1) I'm always seeing... Exception RuntimeError: 'maximum recursion depth exceeded while calling a Python object' in type 'exception.AttributeError' ignored . What does this mean, and how to fix it? In what application are you seeing this error? python Which version of GNU Radio are you using? tarball? If so, which one? git? If so, which branch? I've install gnuradio from Synaptic Package Manager. Looks like 3.0.4 I see this error when every gnuradio python application is run. thanks, Joe Craig Eric My recollection is that there was a compatibility issue between older Gnu Radio code, and the Python2.6 that's in Ubuntu 9.X and more recent. Really, you'll have much better joy if you install from GIT source, following the directions found here: http://gnuradio.org/redmine/wiki/gnuradio/BuildGuide You'll have to uninstall the version that Synaptic installed. Gnu radio is still very much a rapidly-evolving beast, which means that installing from GIT source is really a good way to go. The packagers for various Linux distributions can't possibly keep up with the codebase. Ok, I've been reinstalling with GIT distro for some time now. I'm almost there. I'm on Ubuntu 8.04 and I seem to have all the packages, the only things left are: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi gr-video-sdl gr-qtgui When I run usrp_fft.py ... File usrp_fft.py, line 24, in module from gnuradio import usrp File /usr/lib/python2.6/dist-packages/gnuradio/usrp/__init__.py, line 25, in module File /usr/lib/python2.6/dist-packages/gnuradio/usrp/usrp_swig.py, line 6, in module ImportError: No module named _usrp_swig thanks for the help. Joe -- 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
Re: [Discuss-gnuradio] Moon Bounce Experiment
On 10/22/2010 12:17 AM, Joseph Craig wrote: Ok, I've been reinstalling with GIT distro for some time now. I'm almost there. I'm on Ubuntu 8.04 and I seem to have all the packages, the only things left are: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi gr-video-sdl gr-qtgui You don't need any of the above for basic functionality. When I run usrp_fft.py ... File usrp_fft.py, line 24, in module from gnuradio import usrp File /usr/lib/python2.6/dist-packages/gnuradio/usrp/__init__.py, line 25, in module File /usr/lib/python2.6/dist-packages/gnuradio/usrp/usrp_swig.py, line 6, in module ImportError: No module named _usrp_swig thanks for the help. Joe Have you set your PYTHONPATH variable to point to /usr/lib/python2.6/dist-packages ? -- 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
Re: [Discuss-gnuradio] Moon Bounce Experiment
On Oct 21, 2010, at 10:29 PM, Marcus D. Leech wrote: On 10/22/2010 12:17 AM, Joseph Craig wrote: Ok, I've been reinstalling with GIT distro for some time now. I'm almost there. I'm on Ubuntu 8.04 and I seem to have all the packages, the only things left are: gcell gr-gcell gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi gr-video-sdl gr-qtgui You don't need any of the above for basic functionality. When I run usrp_fft.py ... File usrp_fft.py, line 24, in module from gnuradio import usrp File /usr/lib/python2.6/dist-packages/gnuradio/usrp/__init__.py, line 25, in module File /usr/lib/python2.6/dist-packages/gnuradio/usrp/usrp_swig.py, line 6, in module ImportError: No module named _usrp_swig thanks for the help. Joe Have you set your PYTHONPATH variable to point to /usr/lib/python2.6/dist-packages ? It is... for line in sys.path: print line ... /usr/lib/python2.6 /usr/lib/python2.6/plat-linux2 /usr/lib/python2.6/lib-tk /usr/lib/python2.6/lib-old /usr/lib/python2.6/lib-dynload /usr/lib/python2.6/dist-packages /usr/lib/python2.6/dist-packages/Numeric /usr/lib/python2.6/dist-packages/PIL /usr/lib/python2.6/dist-packages/gst-0.10 /var/lib/python-support/python2.6 /usr/lib/python2.6/dist-packages/gtk-2.0 /var/lib/python-support/python2.6/gtk-2.0 /usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode /usr/local/lib/python2.6/dist-packages -- 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
