[Discuss-gnuradio] Add parameters to a C++ function
Hi, all, I want to get the subcarrier SNR averaged across the whole packet. So I want to trigger the calculation in gr_ofdm_frame_acquisition.cc from gr_ofdm_frame_sink.cc where the packet header is examined to be correct or not. To achieve this, I add one parameter to the construction of gr_ofdm_frame_sink, a pointer pointing to the instance of gr_ofdm_frame_acquistion so that I can access functions in the gr_ofdm_frame_acquisition. However, I got error File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_general.py, line 7039, in ofdm_frame_sink return _gnuradio_swig_py_general.ofdm_frame_sink(*args, **kwargs) TypeError: ofdm_frame_sink() takes at most 8 arguments (9 given) I have changed the gr_ofdm_frame_sink.cc/h to be able to hold 9 arguments. Why does _gnuradio_swig_py_general still report it can only take 8 arguments? What should I modify? Thanks a lot! Best, Pei ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question of tx_ampl range: [0, 1) or [0, 2^15/2) ?
In transmit_path.py ( ..- packet_transmitter - Multiply Const - USRP Sink), I see that the range of Multiply Const is [0, 1). However, in one of the GRC example usrp_tx_dpsk.grc (Random Source - DPSK2 Mod - Multiply Const - USRP Sink), Multiply_Const = tx_ampl*p2p/2 , where p2p = 2^15. There is a multiply_const(2**15) in the transmit_path example. See generic_usrp.py. The gr-usrp sink always takes samples between +/-2**15. See the docs in the USRP sink block in GRC. Does anyone know why the Multiply_Const is set to tx_ampl*p2p/2 and what does p2p refer to? It means peak to peak and the purpose is to scale the signal to the expected range of the usrp sink block. I believe that p2p should actually be 2**16 in this case, but it works. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Add parameters to a C++ function
On 11/08/2010 12:46 AM, Daniel Dekst wrote: Hi, all, I want to get the subcarrier SNR averaged across the whole packet. So I want to trigger the calculation in gr_ofdm_frame_acquisition.cc from gr_ofdm_frame_sink.cc where the packet header is examined to be correct or not. To achieve this, I add one parameter to the construction of gr_ofdm_frame_sink, a pointer pointing to the instance of gr_ofdm_frame_acquistion so that I can access functions in the gr_ofdm_frame_acquisition. However, I got error File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_general.py, line 7039, in ofdm_frame_sink return _gnuradio_swig_py_general.ofdm_frame_sink(*args, **kwargs) TypeError: ofdm_frame_sink() takes at most 8 arguments (9 given) I have changed the gr_ofdm_frame_sink.cc/h to be able to hold 9 arguments. Why does _gnuradio_swig_py_general still report it can only take 8 arguments? What should I modify? Find the swig .i file for this block and see if there is a function signature that needs to be changed. Many of the swig files have copies of the header files so you need to make changes in both places. If thats not the case, its probably just an issue of rebuilding and installing the part of the build tree with the ofdm swig wrapper stuff. -josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] segmentation fault (core dump) -- help needed
Hi all, I'm a newbie in gnu software radio (and in python, and in linux) and got stuck on this segmentation fault issue. I am trying to setup GNU software radio on a machine (HP workstation xw8600 with dual intel Xeon processor). I installed Fedora Core 14 and installed all needed dependencies using YUM as shown below. yum groupinstall Engineering and Scientific Development Tools yum install fftw-devel cppunit-devel wxPython-devel libusb-devel guile boost-devel alsa-lib-devel numpy gsl-devel python-devel pygsl python-cheetah python-lxml yum install sdcc yum install gnuradio yum install gnuradio-examples yum install usrp The installation went ok without any issue. However, when I tried dial tone example at /usr/share/gnuradio/examples/audio/dial_tone.py, it said nothing else but segmentation fault(core dump), and nothing happened. I tried other examples, but this segmentation fault error came up all the time. I found a couple of simple gnu radio examples from google and tried, but the same thing happened. I inserted print statement in the code to see where it failed and it failed in my_top_block().run() function. I want to know why this problem occurs and how to solve it. Can anyone help me out? Any idea/suggestion will be welcomed. I'm still studying GNU software radio blocks, but is there any way to narrow down which block (or which function) cause this segmentation fault? Thanks! Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmentation fault (core dump) -- help needed
On Mon, Nov 08, 2010 at 07:42:25AM -0500, Thomas H Kim wrote: I installed Fedora Core 14 and installed all needed dependencies using YUM as shown below. yum groupinstall Engineering and Scientific Development Tools yum install fftw-devel cppunit-devel wxPython-devel libusb-devel guile boost-devel alsa-lib-devel numpy gsl-devel python-devel pygsl python-cheetah python-lxml yum install sdcc yum install gnuradio yum install gnuradio-examples yum install usrp Hi Thomas, did you install gnuradio from the Fedora repositories? Which version do you have? Just a couple of threads ago someone else had problems with Fedora packages; they are not up to date. Try grabbing a current version from the web site and build it yourself; it's not that hard. The installation went ok without any issue. However, when I tried dial tone example at /usr/share/gnuradio/examples/audio/ dial_tone.py, it said nothing else but segmentation fault(core dump), and nothing happened. I tried other examples, but this segmentation fault error came up all the time. I found a couple of simple gnu radio examples from google and tried, but the same thing happened. I inserted print statement in the code to see where it failed and it failed in my_top_block().run() function. I want to know why this problem occurs and how to solve it. Can anyone help me out? Any idea/suggestion will be welcomed. I'm still studying GNU software radio blocks, but is there any way to narrow down which block (or which function) cause this segmentation fault? Even in an old version, this should not happen. However, if you do have an old version, I recommend upgrading to at least 3.3.0 and trying again. Once it works, you'll simply have much more fun (read: functionality) with a newer GNU Radio. If you do want to debug you installation, a nice place to start might be by starting the Python command line and plugging together tiny flow graphs by hand, to see wether or not they crash. 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 pgplfaDyy63yW.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Basic analog USRP2 transmitter
Do you have an oscilloscope? Is the transmitter actually transmitting? -William On Sun, Nov 7, 2010 at 2:00 PM, alexander levedahl alexanderleved...@gmail.com wrote: I have tried transmitting an analog signal from one USRP2 to another, but when I run usrp2_fft.py on the rx computer, there is no receive signal. The analog signal is supposed to be two tones at 350 and 440 HZ transmitted at 2.6GHz. Can anyone help me figure out what I am doing wrong? I have tried using GRC, but at the most up to date version does not work with Fedora, which is the OS that I have to use, this is for a research project with a professor at my university, and the mandate is to use Fedora, this does not look like it will change in the near future. Alex ___ 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
Re: [Discuss-gnuradio] Dial tone under GNU Radio Companion fails
I tried changing the sampling rate to 44100 and tried using plughw and I get the following results: The following is with plughw: audio_alsa_sink[plughw:0,0]: set_period_time_near failed: Invalid argument Traceback (most recent call last): File /home/al/gnuradio-uhd/gnuradio/gnuradio-examples/grc/audio/dial_tone.py, line 120, in module tb = dial_tone() File /home/al/gnuradio-uhd/gnuradio/gnuradio-examples/grc/audio/dial_tone.py, line 85, in __init__ self.audio_sink = audio.sink(44100, plughw:0,0, True) File /usr/local/lib/python2.6/dist-packages/gnuradio/audio_alsa.py, line 321, in sink return _audio_alsa.sink(*args, **kwargs) RuntimeError: audio_alsa_sink The following is without plugw: audio_alsa_sink[hw:0,0]: set_period_time_near failed: Invalid argument Traceback (most recent call last): File /home/al/gnuradio-uhd/gnuradio/gnuradio-examples/grc/audio/dial_tone.py, line 120, in module tb = dial_tone() File /home/al/gnuradio-uhd/gnuradio/gnuradio-examples/grc/audio/dial_tone.py, line 85, in __init__ self.audio_sink = audio.sink(44100, , True) File /usr/local/lib/python2.6/dist-packages/gnuradio/audio_alsa.py, line 321, in sink return _audio_alsa.sink(*args, **kwargs) RuntimeError: audio_alsa_sink What do I try next? Many thanks, Al Vinegar - Original Message - From: Marcus D. Leech mle...@ripnet.com To: discuss-gnuradio@gnu.org Sent: Sunday, November 07, 2010 10:15 PM Subject: Re: [Discuss-gnuradio] Dial tone under GNU Radio Companion fails On 11/07/2010 10:02 PM, Josh Blum wrote: So, from what I gather, you build and ran 3.2.2 and dial tone worked fine. However, building and running dial done on the next branch gives you the following error? audio_alsa_sink[hw:0,0]: unable to support sampling rate 32000 card requested 44100 instead. Maybe the underlying implementation of the alsa sink changed from 3.2.2 to next? Anybody aware of this? Take a look at the docs in the Audio sink block, I think there is a note to enable the resampler, or just pick a sample rate that your sound card agrees with. -josh When I use alsa audio, I generally use the plughw device, which does resampling. This didn't work for a while on some Fedora distributions a couple of releases back, but I recall that a system update corrected it. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] What is the difference between WBX_NG and WBX_LO
Hi Eric What is the difference between WBX_NG and WBX_LO. If we see in the daughter boards ID's, there are two ID's available for WBX. Which is the right EEPROM ID for WBX daughter board ?. Regards Sanjay ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Website Announcements
Tom, The blog format is rather interesting. One question - would you be able to setup an RSS feed so that those of us that are into using feed readers can be easily alerted when updates/new entries happen? Doug On Mon, Nov 1, 2010 at 5:35 PM, Tom Rondeau trondeau1...@gmail.com wrote: Hello GNU Radio community, I wanted to let everyone know of two projects I've been building up for a few weeks. The first is a new webpage: http://gnuradio.squarespace.com Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmentation fault (core dump) -- help needed
On Mon, Nov 8, 2010 at 11:52 AM, Thomas H Kim thomas.h@aero.org wrote: Steven, Thank you very much for your email. I installed Fedora Core13 x86_64, instead of i386, which I installed on last Friday and it works now. But, I don't understand because i386 should work on 64bit machine (that was what I've thought so far... what do you think?) I guess the problem could be 1) Using FC14 (I don't know think so, but it is possible?) 2) Using x86_64 instead of i386 3) Operator error on gnu radio installation procedure (likely...since I am not really Linux guy) Thank you for your help! Thomas Hi Thomas- (Don't forget to send replies to the mailing list, so we all get the benefit of the troubleshooting process) Just so I understand the sequence of events: under FC14 i386, with gnuradio installed via yum, you got the segmentation faults. Then, you installed FC13 x86_64 on the same machine, without changing the gnuradio installation, and the segfaults were gone? Or did you also reinstall gnuradio? Either way, glad it is working now! -Steven ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Website Announcements
On Mon, Nov 08, 2010 at 10:08:11AM -0500, Douglas Geiger wrote: Tom, The blog format is rather interesting. One question - would you be able to setup an RSS feed so that those of us that are into using feed readers can be easily alerted when updates/new entries happen? Doug Hi Doug, it's all there: http://gnuradio.squarespace.com/home/rss.xml Already subscribed :) 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 pgpPRJBQx8aNc.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Website Announcements
On Mon, Nov 8, 2010 at 12:18 PM, Martin Braun martin.br...@kit.edu wrote: On Mon, Nov 08, 2010 at 10:08:11AM -0500, Douglas Geiger wrote: Tom, The blog format is rather interesting. One question - would you be able to setup an RSS feed so that those of us that are into using feed readers can be easily alerted when updates/new entries happen? Doug Hi Doug, it's all there: http://gnuradio.squarespace.com/home/rss.xml Already subscribed :) Cheers MB Yeah, I also just added some links to the front page to make it more explicit. Tom -- 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 ___ 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
Re: [Discuss-gnuradio] segmentation fault (core dump) -- help needed
On Mon, Nov 8, 2010 at 12:13 PM, Steven Clark steven.p.cl...@gmail.com wrote: On Mon, Nov 8, 2010 at 11:52 AM, Thomas H Kim thomas.h@aero.org wrote: Steven, Thank you very much for your email. I installed Fedora Core13 x86_64, instead of i386, which I installed on last Friday and it works now. But, I don't understand because i386 should work on 64bit machine (that was what I've thought so far... what do you think?) I guess the problem could be 1) Using FC14 (I don't know think so, but it is possible?) 2) Using x86_64 instead of i386 3) Operator error on gnu radio installation procedure (likely...since I am not really Linux guy) Thank you for your help! Thomas Hi Thomas- (Don't forget to send replies to the mailing list, so we all get the benefit of the troubleshooting process) Just so I understand the sequence of events: under FC14 i386, with gnuradio installed via yum, you got the segmentation faults. Then, you installed FC13 x86_64 on the same machine, without changing the gnuradio installation, and the segfaults were gone? Or did you also reinstall gnuradio? Either way, glad it is working now! -Steven Thomas, Thanks. If there is any way you know of to reproduce the problem, I'd be very interested in hearing it. If there is a problem with Fedora 14, then I'd like to know where and hopefully fix it. It shouldn't be a problem with 32 vs. 64-bit and I know people run GNU Radio on Opterons and on Fedora 13. So it sounds right now like Fedora 14 is the variable. Anyone else used Fedora 14 yet? Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What is the difference between WBX_NG and WBX_LO
On Mon, Nov 8, 2010 at 7:06 AM, Sanjay Singh sanjaysinghshyam...@gmail.com wrote: What is the difference between WBX_NG and WBX_LO. If we see in the daughter boards ID's, there are two ID's available for WBX. Which is the right EEPROM ID for WBX daughter board ?. Sanjay, The WBX_LO was a never-released design internal to Ettus Research, the WBX_NG (in libusrp1) is the daughterboard shipping from Ettus Research as the WBX. As we move to the UHD, some of the confusing, unused code and daughterboard IDs will disappear. The WBX dbids are: 0x0053 and 0x0052 Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] What is the difference between WBX_NG and WBX_LO
Thanks for the information Jason. what is the suffix _NG used for ?. Just making sure to understand what it refers to. Thanks and Regards Sanjay On Mon, Nov 8, 2010 at 11:01 PM, Jason Abele ja...@ettus.com wrote: On Mon, Nov 8, 2010 at 7:06 AM, Sanjay Singh sanjaysinghshyam...@gmail.com wrote: What is the difference between WBX_NG and WBX_LO. If we see in the daughter boards ID's, there are two ID's available for WBX. Which is the right EEPROM ID for WBX daughter board ?. Sanjay, The WBX_LO was a never-released design internal to Ettus Research, the WBX_NG (in libusrp1) is the daughterboard shipping from Ettus Research as the WBX. As we move to the UHD, some of the confusing, unused code and daughterboard IDs will disappear. The WBX dbids are: 0x0053 and 0x0052 Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Add parameters to a C++ function
Hi, Thilo, Thanks a lot for your help! We also need to modify the gr_ofdm_frame_sink.i and then it works. Good luck! Best, Pei --- On Mon, 11/8/10, Thilo Mönicke thilo.moeni...@googlemail.com wrote: From: Thilo Mönicke thilo.moeni...@googlemail.com Subject: Re: [Discuss-gnuradio] Add parameters to a C++ function To: Daniel Dekst dolk...@yahoo.com.cn Date: Monday, November 8, 2010, 5:10 PM Hi, have you changed the swig files to? have a look at swig/Makefile.am and swig/yourpakagename.i thilo 2010/11/8 Daniel Dekst dolk...@yahoo.com.cn Hi, all, I want to get the subcarrier SNR averaged across the whole packet. So I want to trigger the calculation in gr_ofdm_frame_acquisition.cc from gr_ofdm_frame_sink.cc where the packet header is examined to be correct or not. To achieve this, I add one parameter to the construction of gr_ofdm_frame_sink, a pointer pointing to the instance of gr_ofdm_frame_acquistion so that I can access functions in the gr_ofdm_frame_acquisition. However, I got error File /usr/local/lib/python2.6/dist-packages/gnuradio/gr/gnuradio_swig_py_general.py, line 7039, in ofdm_frame_sink return _gnuradio_swig_py_general.ofdm_frame_sink(*args, **kwargs) TypeError: ofdm_frame_sink() takes at most 8 arguments (9 given) I have changed the gr_ofdm_frame_sink.cc/h to be able to hold 9 arguments. Why does _gnuradio_swig_py_general still report it can only take 8 arguments? What should I modify? Thanks a lot! Best, Pei ___ 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
Re: [Discuss-gnuradio] Website Announcements
Yep, it was just enabled, and I am now as well. Thanks Tom! Doug On Mon, Nov 8, 2010 at 12:18 PM, Martin Braun martin.br...@kit.edu wrote: On Mon, Nov 08, 2010 at 10:08:11AM -0500, Douglas Geiger wrote: Tom, The blog format is rather interesting. One question - would you be able to setup an RSS feed so that those of us that are into using feed readers can be easily alerted when updates/new entries happen? Doug Hi Doug, it's all there: http://gnuradio.squarespace.com/home/rss.xml Already subscribed :) 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- Doug Geiger doug.gei...@bioradiation.net ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] segmentation fault (core dump) -- help needed
Thank you all for your help. Since I am new in Linux and GNU software Radio, I wanted to start from known good configuration people use, so I wiped out FC14 and installed FC13. After the fresh installation, it started working (I was able to hear tones from my PC's speaker when I ran noise, dial_done examples under GNU radio folder). The FC14 I installed was for 32 bit architecture, and FC13 I installed today was for 64bit architecture. Initially I thought it could be one of the three reasons which caused the segmentation fault: 1) Using FC14 2) Using x86_64 instead of i386 3) Operator error on gnu radio istallation procedure (likely...since I am not really Linux guy) I still don't know exactly why it happen, but after talking to several ppl I think #3 was most likely the reason. It's too late to go back to my old config(I wish I could), but I wonder if I setup PYTHONPATH correctly or not. I searched for the python site-packages file and setup the path to the file. I realized that there were multiple site-packages files in this installation. I will try to figure out if the other site-packages file in other than .../lib/python2.x/ cause this problem when I get some time. If I did that step correctly, then I need to install FC14 i386 on my workstation and see if I can reproduce it. Again, thank you for your help. Thomas From: Tom Rondeau trondeau1...@gmail.com To: Steven Clark steven.p.cl...@gmail.com Cc: discuss-gnuradio@gnu.org Date: 11/08/2010 12:36 PM Subject:Re: [Discuss-gnuradio] segmentation fault (core dump) -- help needed Sent by:discuss-gnuradio-bounces+thomas.h.kim=aero@gnu.org On Mon, Nov 8, 2010 at 12:13 PM, Steven Clark steven.p.cl...@gmail.com wrote: On Mon, Nov 8, 2010 at 11:52 AM, Thomas H Kim thomas.h@aero.org wrote: Steven, Thank you very much for your email. I installed Fedora Core13 x86_64, instead of i386, which I installed on last Friday and it works now. But, I don't understand because i386 should work on 64bit machine (that was what I've thought so far... what do you think?) I guess the problem could be 1) Using FC14 (I don't know think so, but it is possible?) 2) Using x86_64 instead of i386 3) Operator error on gnu radio installation procedure (likely...since I am not really Linux guy) Thank you for your help! Thomas Hi Thomas- (Don't forget to send replies to the mailing list, so we all get the benefit of the troubleshooting process) Just so I understand the sequence of events: under FC14 i386, with gnuradio installed via yum, you got the segmentation faults. Then, you installed FC13 x86_64 on the same machine, without changing the gnuradio installation, and the segfaults were gone? Or did you also reinstall gnuradio? Either way, glad it is working now! -Steven Thomas, Thanks. If there is any way you know of to reproduce the problem, I'd be very interested in hearing it. If there is a problem with Fedora 14, then I'd like to know where and hopefully fix it. It shouldn't be a problem with 32 vs. 64-bit and I know people run GNU Radio on Opterons and on Fedora 13. So it sounds right now like Fedora 14 is the variable. Anyone else used Fedora 14 yet? Tom ___ 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
Re: [Discuss-gnuradio] Basic analog USRP2 transmitter
On Sun, Nov 07, 2010 at 10:06:13PM -0500, alexander levedahl wrote: I might have made an error here by assuming that since the latest version of grc doesn't come with the build for Fedora 13, it doesn't work with Fedora 13. When I have used the add/remove software tool, it tells me that 0.70-6.fc12 is the most up to date version around, and I can't find instructions on the gnuradio website for a more recent version. I can't speak about the Fedora packages, but when building from source GNU Radio builds and runs fine under Fedora 13, both 32 and 64-bit. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Basic analog USRP2 transmitter
On Mon, Nov 08, 2010 at 03:18:53PM -0500, Marcus D. Leech wrote: On 11/08/2010 03:10 PM, Eric Blossom wrote: I'm guessing that the Fedora 14 package is OK too :-) Eric I'll let you know sometime near the end of this week. My main 'pooter in the house has quit, so I'm replacing the mobo and disk drive, and I plan to upgrade to F14 at the same time. Replacing a Pentium D dual-core with a Phenom II X3. Thanks! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Basic analog USRP2 transmitter
On 11/08/2010 03:10 PM, Eric Blossom wrote: I'm guessing that the Fedora 14 package is OK too :-) Eric I'll let you know sometime near the end of this week. My main 'pooter in the house has quit, so I'm replacing the mobo and disk drive, and I plan to upgrade to F14 at the same time. Replacing a Pentium D dual-core with a Phenom II X3. -- 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] Random behavior?
Hi, We are experimenting with two USRP1's (each with RFX2400) and noticed some strange behavior. We use the /usr/local/share/gnuradio/examples/digital/benchmark_rx[tx].py. We run it once and the number of corrupted/lost packets is rather small, say 0-2%. Without modifying any default values of parameters, or touching the USRP's, we start it again and the number goes up to, say 40%. We run it again and the number of lost packets is about 90% and those that make it through are mostly corrupted. It doesn't always occur in this pattern, sometimes we get good ratio for a few runs of the benchmark and then it goes down again. Sometimes it no packets are received at all. All within the same parameters and physical positions of the radios. We tried different values of Tx amplitude and Rx gain, but radios keep behaving in this way. We attached the FFT sink on the receiver side and see that the signal is coming in, but packets are still mostly lost after a few runs, sometimes even after the first run. What could be the reason for this behavior? What is the optimal setup for two USRP's -- in terms of physical distance and values of parameters? Thanks, Jakub ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Successful compilation on MinGW/MSYS
Dear all, I've been using GR on Linux for some time, and thought I'd compare its performance on 'that other' OS. A few weeks ago I checked out the latest from the repo and managed to compile all that could be compiled on Windows (7, 64-bit) using the latest 32-bit release of MinGW/MSYS and its bundled packages. The unbuilt components are those that explicitly require a different platform/build environment (i.e. USRP2, gcell related). Qt, wx, GTK and GL GUI apps/components all work too (including GRC). The existing guide on the GR wiki (http://gnuradio.org/redmine/wiki/gnuradio/MingwInstallMain) was an excellent starting point, however additional source modification and configuration was necessary (e.g. creation of PkgConfig files). Some simple tests with a USRP I indicated everything works well and performs similarly to a Linux build - as you would expect! Linux still feels slightly snappier though (WOW64?). There is also that issue where you have to re-connect the USRP after the firmware has been programmed. I'm wondering how many people actually use GR under Windows? (I'm guessing it's a minority!) If it's helpful to anyone, I can package up my build notes, .pc files and patches, and put them online. Thanks for keeping GR (almost entirely) cross-platform! Balint ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Dial tone under GNU Radio Companion fails
48000 did the trick. The program now works. Many thanks. Al Vinegar - Original Message - From: Scott Storck ssto...@gmail.com To: Allen Vinegar tok...@myranch.com Sent: Monday, November 08, 2010 7:58 PM Subject: Re: [Discuss-gnuradio] Dial tone under GNU Radio Companion fails I ran into the same problem, but I can't remember exactly how I solved it. I think initially I was able to get it working using 48000 as the sample rate, so you might try that value. On 11/8/10, Allen Vinegar tok...@myranch.com wrote: I tried changing the sampling rate to 44100 and tried using plughw and I get the following results: The following is with plughw: audio_alsa_sink[plughw:0,0]: set_period_time_near failed: Invalid argument Traceback (most recent call last): File /home/al/gnuradio-uhd/gnuradio/gnuradio-examples/grc/audio/dial_tone.py, line 120, in module tb = dial_tone() File /home/al/gnuradio-uhd/gnuradio/gnuradio-examples/grc/audio/dial_tone.py, line 85, in __init__ self.audio_sink = audio.sink(44100, plughw:0,0, True) File /usr/local/lib/python2.6/dist-packages/gnuradio/audio_alsa.py, line 321, in sink return _audio_alsa.sink(*args, **kwargs) RuntimeError: audio_alsa_sink The following is without plugw: audio_alsa_sink[hw:0,0]: set_period_time_near failed: Invalid argument Traceback (most recent call last): File /home/al/gnuradio-uhd/gnuradio/gnuradio-examples/grc/audio/dial_tone.py, line 120, in module tb = dial_tone() File /home/al/gnuradio-uhd/gnuradio/gnuradio-examples/grc/audio/dial_tone.py, line 85, in __init__ self.audio_sink = audio.sink(44100, , True) File /usr/local/lib/python2.6/dist-packages/gnuradio/audio_alsa.py, line 321, in sink return _audio_alsa.sink(*args, **kwargs) RuntimeError: audio_alsa_sink What do I try next? Many thanks, Al Vinegar - Original Message - From: Marcus D. Leech mle...@ripnet.com To: discuss-gnuradio@gnu.org Sent: Sunday, November 07, 2010 10:15 PM Subject: Re: [Discuss-gnuradio] Dial tone under GNU Radio Companion fails On 11/07/2010 10:02 PM, Josh Blum wrote: So, from what I gather, you build and ran 3.2.2 and dial tone worked fine. However, building and running dial done on the next branch gives you the following error? audio_alsa_sink[hw:0,0]: unable to support sampling rate 32000 card requested 44100 instead. Maybe the underlying implementation of the alsa sink changed from 3.2.2 to next? Anybody aware of this? Take a look at the docs in the Audio sink block, I think there is a note to enable the resampler, or just pick a sample rate that your sound card agrees with. -josh When I use alsa audio, I generally use the plughw device, which does resampling. This didn't work for a while on some Fedora distributions a couple of releases back, but I recall that a system update corrected it. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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 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] Pipelined processing with the Thread-Per-Block scheduler?
Dear all, I conducted a simple experiment (using GRC) to test the TPB scheduler's performance, and following a search here, I cannot find any definitive information that would explain the observed behaviour. I kindly request your thoughts on the matter: Three flow graphs were created in separate GRC documents. No graph uses throttling. Tests were run on a dual-core Linux machine using a 3.3git release. 1) One graph: a high-rate signal source connected to a resampler, which is in turn connected to a null sink. 2) Two identical disconnected sub-graphs: each contains a high-rate signal source connected to a resampler, which is in turn connected to a null sink (i.e. as above, just twice). 3) One graph: one high-rate signal source whose output is connected to the input of two separate resamplers, each of which is connected to its own null sink. 'High-rate' means a few Msps, and the resamplers output data at a similar rate (e.g. 8MHz, decim/interp=4:3). Thanks to the TPB scheduler, (2) uses 100% CPU (max load on both cores) as the sub-graphs are disconnected. However when running (1) and (3), only 50% utilisation is observed. I also placed 'Copy' and 'Kludge Copy' blocks before the resampler inputs in (3), but this did not increase performance (which makes sense given the assumed flow model below). I am not aware of the intricacies of the asynchronous flow model used, or the TPB scheduler (I only skimmed the source), but I wonder why (1) and (3) do not use more than 50% CPU? Please excuse any gaps in my understanding, but my thoughts are as follows: Asynchronous producer/consumer and push/pull graphs are obviously quite complicated to get right in all circumstances (I pulled my hair out designing one), and there are a number of ways data can be passed between blocks - doubtless to say, GR generally does an excellent job of this. In the particular scenario of (1) and (3) though, is the performance bottleneck the manner in which that data is passed around, and how/when the blocks' production/consumption state, and thread state, is changed? I'm not sure if a push or pull model is used without a clock or throttle, but does the signal source block because it must wait until its own internal production buffer is consumed by the resampler? So therefore the currently running thread switches back and forth between the signal source and resampler? This (in my mind) rests on the assumption that the buffer (memory region) that is passed to the general_work of the resampler actually lives inside the signal source block, and there is no direct control over how much of that buffer is consumed in one iteration of the connected block's (in this case the resampler's) general_work, aside from indirectly via forecast in the connected block? Or is that not the case? This (empirical and thought) experiment should be framed with a view to pipelining. Ideally, as the graph is not throttled, the threads should seldom block and utilisation for (1) should be close to 100%, and (3) should be slightly less on dual-core (because in the best case only the signal source and one resampler can run at any one time). This would rely on produced data either living on-the-wire (connection) between blocks, or in the input stage of a connected block - of course this comes with restrictions and overheads (I'm not sure what the base-class block does in regards to managing the data buffers passed to/from general_work). For (3), the data (memory block) produced by the signal source would be read-only, and therefore could be simultaneously processed by the two resampler blocks on separate cores, thus achieving greater throughput. Is a major architectural change required to realise this? Or if it has already been considered, are the overheads potentially so large that it would degrade performance? Thanks for your thoughts, Balint ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
