Re: [Discuss-gnuradio] Trouble building gnuradio/next (Linux Mint 14/64)
I'm having exactly the same problem with my Ubuntu machine.. Tommy James Tracy II Ph.D Student High Performance Low Power Lab University of Virginia Phone: 913-775-2241 On Mar 28, 2013, at 12:27 AM, "Ralph A. Schmid, dk5ras" wrote: > First attempt was just git pull / cd master / make, then I received some > error regarding access rights. Huh?! Then I tried git clean -d -x -f, it did > not remove the folder, so I sudo-deleted the folder, mkdir master, cd > master, cmake .., make. The result I mailed to the list. When I went back > two days earlier everything builds fine, after a git pull again it does not > build, so I can assume my system so far should be OK. > > The only "stranke thing" on my machine I am aware of is a minimum gnuradio > 3.4.2 installation that I need to operate OpenBTS. I need to uninstall it to > build some osmocom stuff (gr-... and other). > > Ralph. > > >> Going to need more information. What git commit are you using? Are you >> building from a clean build directory? Did you previously build next in > this >> directory and are now going back to master? >> >> Tom >> >> >> >>> On Tuesday, March 26, 2013 09:47:54 PM you wrote: >>> I just pushed what should be a fix for this. It built on my VM of Mint > 14. Tom >> -Original Message- >> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org >> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On >> Behalf Of Alexandru Csete >> Sent: Saturday, 23 March, 2013 16:23 >> To: Tom Rondeau >> Cc: GNURadio Discussion List >> Subject: Re: [Discuss-gnuradio] Trouble building gnuradio/next >> (Linux Mint >> 14/64) >> >> Hi Tom, >> >> Disabling the ATSC component did it! You are right, I don't need it. >> Enjoy your vacation! >> >> Alex >> >> ___ >> Discuss-gnuradio mailing list >> Discuss-gnuradio@gnu.org >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >>> ___ >>> Discuss-gnuradio mailing list >>> Discuss-gnuradio@gnu.org >>> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio signature.asc Description: Message signed with OpenPGP using GPGMail ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble building gnuradio/next (Linux Mint 14/64)
First attempt was just git pull / cd master / make, then I received some error regarding access rights. Huh?! Then I tried git clean -d -x -f, it did not remove the folder, so I sudo-deleted the folder, mkdir master, cd master, cmake .., make. The result I mailed to the list. When I went back two days earlier everything builds fine, after a git pull again it does not build, so I can assume my system so far should be OK. The only "stranke thing" on my machine I am aware of is a minimum gnuradio 3.4.2 installation that I need to operate OpenBTS. I need to uninstall it to build some osmocom stuff (gr-... and other). Ralph. > Going to need more information. What git commit are you using? Are you > building from a clean build directory? Did you previously build next in this > directory and are now going back to master? > > Tom > > > > > On Tuesday, March 26, 2013 09:47:54 PM you wrote: > > > >> I just pushed what should be a fix for this. It built on my VM of Mint 14. > >> > >> Tom > >> > >> >> -Original Message- > >> >> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org > >> >> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On > >> >> Behalf Of Alexandru Csete > >> >> Sent: Saturday, 23 March, 2013 16:23 > >> >> To: Tom Rondeau > >> >> Cc: GNURadio Discussion List > >> >> Subject: Re: [Discuss-gnuradio] Trouble building gnuradio/next > >> >> (Linux Mint > >> >> 14/64) > >> >> > >> >> Hi Tom, > >> >> > >> >> Disabling the ATSC component did it! You are right, I don't need it. > >> >> Enjoy your vacation! > >> >> > >> >> Alex > >> >> > >> >> ___ > >> >> Discuss-gnuradio mailing list > >> >> Discuss-gnuradio@gnu.org > >> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >> > > >> > ___ > >> > Discuss-gnuradio mailing list > >> > Discuss-gnuradio@gnu.org > >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Major update to gnuradio repository 'next' branch
Note: This email only applies to GNU Radio users who have been using the GNU Radio "3.7 experimental" next branch. The changes below do not impact the majority of users. In particular, if you have installed GNU Radio by compiling a release tarball, have used the 'build-gnuradio' script to retrieve and compile GNU Radio, have used 'git clone' to retrieve, then compile the GNU Radio master development branch, have installed GNU Radio from an operating system supplied package, or are using the Ettus Research LiveUSB or Instant SDR products, you *are not* affected. Tom Rondeau and I have completed the second phase of the transition on the 'next' branch to the 3.7 release code organization. Phase I was to move all the gnuradio blocks out from inside gnuradio-core into a new set of top-level components, and rewrite them using C++ namespaces and the virtual private implementation class pattern (details and benefits of doing this are covered in previous emails.) This happened over a long period of time and was recently completed. Phase II, which has just been merged into next, was to extract the GNU Radio runtime code into a new directory, gnuradio-runtime, and eliminate gnuradio-core altogether. The changes at this point primarily affect the build of out-of-tree C++ projects, which now need to link against libgnuradio-runtime instead of libgnuradio-core. We have supplied a new CMake module, FindGnuradioRuntime.cmake, which you can use to replace your existing FindGnuradioCore.cmake file. The pkgconfig library name is now gnuradio-runtime as well. The gr_modtool program for building out-of-tree modules on the next branch has been updated to work with the name change. The directory: gr-utils/python/modtool/gr-newmod/ ...now contains the canonical structure for out-of-tree GNU Radio C++ modules, and you can look here to see what your out-of-tree build should look like to work with the 3.7 next branch. We have now removed the gr-howto-write-a-block component to reflect this. In order to update your GNU Radio software (again, only for those tracking the next branch), it is strongly recommended that you first do a 'sudo make uninstall' from within the build directory you created when compiling GNU Radio. Then delete that build directory. This will remove all traces of the existing GNU Radio libraries before updating. To update your next branch, it is sufficient to do a 'git pull' to get the lastest changes. At that point, you can proceed to re-create the build directory and perform the steps needed to build and install GNU Radio again. Python scripts and GRC programs that were already working with the latest next branch will be unaffected by this change. Johnathan Corgan Corgan Labs ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution
I think it is the same problem I see in gr-digital/ofdm/benchmark_tx and rx. In discontinuous mode (with bpsk modulation), the first packet of every burst is always missing at the receiver. Will appreciate more details on how to fix the problem so that burst mode works fine. Should the fix be made in cc layer (like digitial_ofdm* file)? -Original Message- From: discuss-gnuradio-bounces+anirudha.sahoo=nist@gnu.org [mailto:discuss-gnuradio-bounces+anirudha.sahoo=nist@gnu.org] On Behalf Of Tom Rondeau Sent: Saturday, March 16, 2013 10:19 AM To: Alex Zhang Cc: gnuradio mailing list Subject: Re: [Discuss-gnuradio] Very low packet loss rate for the discontinuous BPSK communications- the analysis and looking for solution On Fri, Mar 15, 2013 at 11:33 PM, Alex Zhang wrote: > Hi Sreeraj and Tom, > > For the discontinuous mode, by cutting the freq_bw to below half of > the default value, I found that for differential_bpsk, the packet loss > rate can be improved(from 30% to 70%), but for non-differential bpsk, > the improvement is hard to see. Especially, for non-differential bpsk, > I found that often the whole burst (5 packets) could lost. Maybe, it > is due to the Phase rotation. I am still trying to investigate. Are you handling the phase ambiguity in the receiver somehow? The way things lock, the phases for BPSK could off by 180 degrees, so all 1's are 0's and all 0's are 1's. So when you lock with a burst, you have a 50/50 chance of locking on the wrong phase and so all of your bits are going to be wrong. You'd have to detect this and flip everything. Tom > On Thu, Mar 7, 2013 at 11:08 AM, Sreeraj Rajendran > > wrote: >> >> Alex, >> >> That one is non data aided(no preamble) frequency syncronization. As >> Tom mentioned FLL must be the slowest one in the three. >> >> Did you try adjusting loop bandwidth?. There is an example_fll >> example in gr-digial. Just try that one and check how many >> symbols/samples it takes to settle. >> >> Just go through the papers I mentioned and that idea is easy to >> implement to do coarse synchronization during fast burst transmissions. >> >> >> --- >> Regards >> Sreeraj Rajendran >> http://home.iitb.ac.in/~rsreeraj >> >> >> From: Alex Zhang >> To: Sreeraj Rajendran >> Sent: Thursday, 7 March 2013 10:24 PM >> >> Subject: Re: [Discuss-gnuradio] Very low packet loss rate for the >> discontinuous BPSK communications- the analysis and looking for >> solution >> >> Dear Sreeraj, >> >> You mentioned the openloop synch algorithms. Are they refered to the >> preamble based carrier recovery? >> >> Thanks >> >> >> On Mon, Mar 4, 2013 at 8:03 AM, Sreeraj Rajendran >> wrote: >> >> Alex, >> >> If Adeel's solution is not meeting your burst transmission specs, you >> can try implementing some fast openloop synchro algorithms given in >> [1],[2]. You could look into some data aided schemes too, though I >> haven't tried those yet. >> >> >> [1] Digital Communication Receivers, Heinrich Meyr, Section 8.2.2 [2] >> Two Frequency Estimation Schemes Operating Independently of Timing >> Information, Ferdinand Classen and Heinrich Meyr >> >> --- >> Regards >> Sreeraj Rajendran >> http://home.iitb.ac.in/~rsreeraj >> >> >> From: Adeel Anwar >> To: Alex Zhang >> Cc: discuss-gnuradio@gnu.org >> Sent: Monday, 4 March 2013 5:51 PM >> Subject: Re: [Discuss-gnuradio] Very low packet loss rate for the >> discontinuous BPSK communications- the analysis and looking for >> solution >> >> Alex, >> >> 1: U can try adjusting the synchronization loops bandwidth >> (Phase/Timing >> etc) see PFB_Timing documentation >> 2: Try reducing the receiver gain (for a constant tx-amplitude/gain) >> or reduce transmission amplitude/gain (for constant rx gain) >> >> -Adeel >> >> >> >> >> >> >> On Sat, Mar 2, 2013 at 10:21 AM, Alex Zhang >> wrote: >> >> I think you may rarely get the correct packet with pktno = 0, in >> continuous mode, as my guess. Your received correct packet starts >> from pktno = 1. >> Could you also try the discontinuous mode for the BPSK communications? >> >> My question is actually a problem that how to implement a more >> reliable BPSK mod/demod in burst mode. The current bpsk example in >> GNURadio does not work well in burst mode. >> >> >> On Fri, Mar 1, 2013 at 11:12 PM, Manu T S wrote: >> >> Alex, >> >> If it was about loosing sync, we would mostly loose the first packet >> even if we are sending in continuous mode. I personally face no such issues. >> >> >> On Sat, Mar 2, 2013 at 3:25 AM, Alex Zhang >> wrote: >> >> Seems no one can shed a light on this topic? >> >> >> On Thu, Feb 28, 2013 at 10:25 PM, Alex Zhang >> >> wrote: >> >> Hello, >> >> In the current gr-digital/narrowband, I am using the benchmark_tx.py >> and rx.py to test the bpsk communications. >> It is found that the packet loss rate is very high (70% loss) in >> discontinuous mode where every 5 packet
[Discuss-gnuradio] is this normal behavior of benchmark_rx.py
Hi, I have two USRPs (N210) connected to each other through a channel emulator (via RF cable) which is emulating a lossless channel. When I run the benchmark_rx.py I see some spurious bytes being received by the receiver even when the sender application (benchmark_tx.py) has not been started. I have enabled VERBOSE in the file "digital_ofdm_frame_sink.cc". Below is a sample output from the receiver (note the sender has not been started at all). I see that intermittently the cc layer prints out the following block which means it got some bytes (symbols). How can receiver get these bytes when there is no sender? What is more bothersome is that when I change the occupied-tones to 120 (i.e., I run it with "python benchmark_rx.py --args "addr=usrp4" -f 795.5M --occ 120 -W 4M"), (in this case "bytes from demapper = 14" printed instead of 29) then the following block is printed *continuously*. I am wondering where is the receiver getting bytes/symbols when there is no transmitter? I am running gnuradio 3.6.2. == @ enter_have_sync Header Search bitcnt=0, header=0x bytes from demapper = 29 got header: 0xb06fe351 @ enter_search $ python benchmark_rx.py --args "addr=usrp4" -f 795.5M --occ 240 -W 4M linux; GNU C++ version 4.4.6 20120305 (Red Hat 4.4.6-4); Boost_104100; UHD_003.004.003-221-g9d6f9492 -- Opening a USRP2/N-Series device... -- Current recv frame size: 1472 bytes -- Current send frame size: 1472 bytes UHD Warning: Unable to set the thread priority. Performance may be negatively affected. Please see the general application notes in the manual for instructions. EnvironmentError: OSError: error in pthread_setschedparam No gain specified. Setting gain to 19.00 (from [0.00, 38.00]) Using Volk machine: avx_64_mmx >>> gr_fir_ccf: using SSE >>> gr_fir_fff: using SSE @ enter_search Warning: failed to enable realtime scheduling @ enter_have_sync Header Search bitcnt=0, header=0x bytes from demapper = 29 got header: 0x50b5f4e3 @ enter_search @ enter_have_sync Header Search bitcnt=0, header=0x bytes from demapper = 29 got header: 0x10ffc9c1 @ enter_search TIMEOUT @ enter_have_sync Header Search bitcnt=0, header=0x bytes from demapper = 29 got header: 0xb06fe351 @ enter_search TIMEOUT thanks and regards --Anirudh Sahoo Advanced Network Technology Div. National Institute of Standards and Technology (NIST) 100 Bureau Drive, Gaithersburg, MD - 20878 Room - B230, bldg.- 222 Phone- 301-975-4439 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] tunnel.py command not working
Hi, I tried to run tunnel.py on my machine (Ubuntu 11.10) with 2 USRPs (usrp1). from one side I launched: ./tunnel.py --tx-freq 2.4G --rx-freq 2.4001G -a="name=dev1" -A TX/RX --bitrate 500k -v then : sudo ifconfig gr0 192.168.200.1 from another terminal (on the same machine): ./tunnel.py --rx-freq 2.4G --tx-freq 2.4001G -a="name=dev0" -A TX/RX --bitrate 500k -v sudo ifconfig gr1 192.168.200.2 But when I run ping from both sides I see nothing displayed! Is what I've done correct? Is it possible to use one machine? What did I miss? Can you help me plz! Best Regards, Nada This message was sent using IMP, the Internet Messaging Program. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Creating a new WX GUI Widget
I would like to use a Spin Control rather than a Slider in a project I am developing in grc. I have a couple of questions- First, has anyone developed a SpinCtrl widget and would like to share the code? Second, can anyone provide any advice on creating the widget my self? The documentation I have found is fairly sparse. It appears I would need to write /usr/local/share/gnuradio/grc/blocks/variable_spinctrl.xml And add 2 sections to /usr/local/lib/python2.6/site-packages/gnuradio/wxgui/forms/forms.py class _spinctrl_base(_form_base): class spinctrl(_spinctrl_base): Am I on the right track with this? And are there any other files that would need to be created/edited? Is there an existing widget that would serve as a good example to follow in trying to create the SpinCtrl? And I'm also having trouble finding what parameters would need to be passed to the widget. There seems to be conflicting information. Any advice on this would be appreciated. Thanks, George ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recording samples after detecting peak in the receiver
On Tue, Mar 26, 2013 at 11:38 PM, john jade wrote: > Hi, > > I am working on a project(channel response estimation),in which i have to > start recording the samples after the receiver detects the packet. > > Currently i am transmitting a packet using benchmark_tx.py example and using > benchmark_rx.py to receive the packet. > > > 1..Is correlator block implemented in FPGA or in the host software?(for > comparing access code with the received packet code). Implemented in software. The synchronization loops are all done in the receiver's host side (that is, in GNU Radio). Specifically, the access code is used on framer_sink_1 (see gr-digital/python/pkt.py). You could redo or copy the framer block into your own where it emits a "burst" tag with the value pmt::PMT_T when it sees the access code. You can then tie this directly to the the tagged_file_sink block, which looks for a tag with key "burst". When the tag's value is true (PMT_T), it will open a new file and save the samples. When it gets a tag with a value of false (PMT_F), it will close the file. So you'll have to have a way to detect the end of the packet, which could just be knowing how many bits are in a full packet. > 2. If i want to implement it on FPGA ,how to start,because i have never > done FPGA programming before. That's a steep learning curve. As long as your host machine can handle the bandwidth you need, I wouldn't go there. > If there is any workaround please let me know. > > Thanks. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Why packet decode failure happen when fft-length is set to 64?
On Wed, Mar 27, 2013 at 5:33 AM, Yingjie Chen wrote: > Hi guys, > Thanks in advance. I am using usrp2 in OFM example. When I set > fft-length to 64, subcarrier to 32,the receiver cannnot decode the > packet correctly. The whole chunk of received data are almost false. > However, when I set fft-length to 128, subcarriers to 64, nearly all > packets can be decode correctly. I feel so confused about that. Does > anyone know that? Could be related to the subcarrier spacing in the bandwidth and frequency offset. Try to hand-tune your tx and rx frequencies so they are as close as you can get (using uhd_siggen and uhd_fft) them and see if that helps. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble building gnuradio/next (Linux Mint 14/64)
On Wed, Mar 27, 2013 at 3:46 AM, Ralph A. Schmid wrote: > Now I get into trouble with Kubuntu 12.04 32bit when building it: > > 36%] Built target _gnuradio_core_filter_swig_tag > Linking CXX shared module _gnuradio_core_filter.so > [ 36%] Built target _gnuradio_core_filter > [ 36%] Built target _gnuradio_core_general_swig_tag > [ 36%] Building CXX object gnuradio- > core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6083:22: error: > redefinition of ‘struct swig::traits’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5498:22: error: > previous definition of ‘struct swig::traits’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6087:23: error: > redefinition of ‘struct swig::traits_asval’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5502:23: error: > previous definition of ‘struct swig::traits_asval’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6093:23: error: > redefinition of ‘struct swig::traits_from’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5508:23: error: > previous definition of ‘struct swig::traits_from’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6103:22: error: > redefinition of ‘struct swig::traits >’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5518:22: error: > previous definition of ‘struct swig::traits >’ > make[2]: *** [gnuradio- > core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o] > Error 1 > make[1]: *** [gnuradio- > core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/all] Error 2 > make: *** [all] Error 2 > ras@dk5ras:~/gnuradio/master$ Ralph, Going to need more information. What git commit are you using? Are you building from a clean build directory? Did you previously build next in this directory and are now going back to master? Tom > On Tuesday, March 26, 2013 09:47:54 PM you wrote: > >> I just pushed what should be a fix for this. It built on my VM of Mint 14. >> >> Tom >> >> >> -Original Message- >> >> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org >> >> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of >> >> Alexandru Csete >> >> Sent: Saturday, 23 March, 2013 16:23 >> >> To: Tom Rondeau >> >> Cc: GNURadio Discussion List >> >> Subject: Re: [Discuss-gnuradio] Trouble building gnuradio/next (Linux >> >> Mint >> >> 14/64) >> >> >> >> Hi Tom, >> >> >> >> Disabling the ATSC component did it! You are right, I don't need it. >> >> Enjoy your vacation! >> >> >> >> Alex >> >> >> >> ___ >> >> Discuss-gnuradio mailing list >> >> Discuss-gnuradio@gnu.org >> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >> > ___ >> > Discuss-gnuradio mailing list >> > Discuss-gnuradio@gnu.org >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble building gnuradio/next (Linux Mint 14/64)
On Wed, Mar 27, 2013 at 8:19 AM, Alexandru Csete wrote: > On Wed, Mar 27, 2013 at 2:47 AM, Tom Rondeau wrote: >> On Sat, Mar 23, 2013 at 2:01 PM, Ralph A. Schmid, dk5ras >> wrote: >>> I have seen the very same with Kubuntu 12.10 64 bit a few weeks ago... >>> >>> Ralph. >> >> I just pushed what should be a fix for this. It built on my VM of Mint 14. >> > > > Hi Tom, > > Thanks for the update. Is the fix for the failing ATSC build or the gcc 4.7? > > Alex Just the ATSC build. Not hugely important, but I thought we should get it right. The gcc 4.7 bug can't be fixed on our side. It's a known ICE problem, and they need to patch it. I know they have a patch available, but I'm not sure of the top of my head what version you need to get this. I just know that the version installed in Ubuntu 12.10 still has this bug. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Problems running tunnel.py
Hi, I tried to run tunnel.py on my machine (Ubuntu 11.10) with 2 USRPs (usrp1). from one side I launched: ./tunnel.py --tx-freq 2.4G --rx-freq 2.4001G -a="name=dev1" -A TX/RX --bitrate 500k -v then : sudo ifconfig gr0 192.168.200.1 from another terminal (on the same machine): ./tunnel.py --rx-freq 2.4G --tx-freq 2.4001G -a="name=dev0" -A TX/RX --bitrate 500k -v sudo ifconfig gr1 192.168.200.2 But when I run ping from both sides I see nothing displayed! Is what I've done correct? Is it possible to use one machine? What did I miss? Can you help me plz! Best Regards, Nada This message was sent using IMP, the Internet Messaging Program. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble building gnuradio/next (Linux Mint 14/64)
On Wed, Mar 27, 2013 at 1:29 PM, Ralph A. Schmid, dk5ras wrote: >> Well, it builds fine for me on Mint 13 64 bit, but note that we are > talking >> about the "next" branch - the directory in your error message suggests > it's >> the master branch. > > Aah, OK, missed this one; anyway, somehow master seems to make problems now. > I am not using next, as AFAIK the analog blocks still do not work as > expected. Or has this changed? > I don't know about any issues with the analog blocks in gnuradio/next. I only use the quadrature demodulator in c++ for FSK and that works fine. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble building gnuradio/next (Linux Mint 14/64)
On Wed, Mar 27, 2013 at 8:46 AM, Ralph A. Schmid wrote: > Now I get into trouble with Kubuntu 12.04 32bit when building it: > > 36%] Built target _gnuradio_core_filter_swig_tag > Linking CXX shared module _gnuradio_core_filter.so > [ 36%] Built target _gnuradio_core_filter > [ 36%] Built target _gnuradio_core_general_swig_tag > [ 36%] Building CXX object gnuradio- > core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6083:22: error: > redefinition of ‘struct swig::traits’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5498:22: error: > previous definition of ‘struct swig::traits’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6087:23: error: > redefinition of ‘struct swig::traits_asval’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5502:23: error: > previous definition of ‘struct swig::traits_asval’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6093:23: error: > redefinition of ‘struct swig::traits_from’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5508:23: error: > previous definition of ‘struct swig::traits_from’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6103:22: error: > redefinition of ‘struct swig::traits >’ > /home/ras/gnuradio/master/gnuradio- > core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5518:22: error: > previous definition of ‘struct swig::traits >’ > make[2]: *** [gnuradio- > core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o] > Error 1 > make[1]: *** [gnuradio- > core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/all] Error 2 > make: *** [all] Error 2 > ras@dk5ras:~/gnuradio/master$ > Well, it builds fine for me on Mint 13 64 bit, but note that we are talking about the "next" branch - the directory in your error message suggests it's the master branch. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble building gnuradio/next (Linux Mint 14/64)
On Wed, Mar 27, 2013 at 2:47 AM, Tom Rondeau wrote: > On Sat, Mar 23, 2013 at 2:01 PM, Ralph A. Schmid, dk5ras > wrote: >> I have seen the very same with Kubuntu 12.10 64 bit a few weeks ago... >> >> Ralph. > > I just pushed what should be a fix for this. It built on my VM of Mint 14. > Hi Tom, Thanks for the update. Is the fix for the failing ATSC build or the gcc 4.7? Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Is there any correlation between bandwidth and subcarriers-tounes in ofdm?
Thanks for your reply. You mean the bandwidth in receiver side(spectrum analyser) is only half of that of sender side if the active tones is half of the FFT length, is that right? Can you provide the explicit formula for helping me better understand. 2013/3/27 Martin Braun (CEL) > The fraction of the Nyquist zone occupied is equal to the number of > active tones divided by the FFT length. The actual bandwidth then > depends on your sampling rate. > > MB > > On Wed, Mar 27, 2013 at 05:54:46PM +0800, Yingjie Chen wrote: > > Hi guys, > > > > I wonder if there is any correlation between baseband bandwidth of > > receiver side and fft-subcarriers-tounes of sender sider in OFDM? When > > I set the bandwidth to 20Mhz in sender side, the spectrum analyzer of > > receiver side shows only half of bandwidth（10Mhz). Does the reason > > that I use 128fft and 64 subcarriers account for this phenomenon? > > > > Sent from my iPhone > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- > 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-43790 > Fax: +49 721 608-46071 > 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 > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Is there any correlation between bandwidth and subcarriers-tounes in ofdm?
The fraction of the Nyquist zone occupied is equal to the number of active tones divided by the FFT length. The actual bandwidth then depends on your sampling rate. MB On Wed, Mar 27, 2013 at 05:54:46PM +0800, Yingjie Chen wrote: > Hi guys, > > I wonder if there is any correlation between baseband bandwidth of > receiver side and fft-subcarriers-tounes of sender sider in OFDM? When > I set the bandwidth to 20Mhz in sender side, the spectrum analyzer of > receiver side shows only half of bandwidth（10Mhz). Does the reason > that I use 128fft and 64 subcarriers account for this phenomenon? > > Sent from my iPhone > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- 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-43790 Fax: +49 721 608-46071 www.cel.kit.edu KIT -- University of the State of Baden-Württemberg and National Laboratory of the Helmholtz Association pgpdsk6xui5YI.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Is there any correlation between bandwidth and subcarriers-tounes in ofdm?
Hi guys, I wonder if there is any correlation between baseband bandwidth of receiver side and fft-subcarriers-tounes of sender sider in OFDM? When I set the bandwidth to 20Mhz in sender side, the spectrum analyzer of receiver side shows only half of bandwidth（10Mhz). Does the reason that I use 128fft and 64 subcarriers account for this phenomenon? Sent from my iPhone ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Why packet decode failure happen when fft-length is set to 64?
Hi guys, Thanks in advance. I am using usrp2 in OFM example. When I set fft-length to 64, subcarrier to 32,the receiver cannnot decode the packet correctly. The whole chunk of received data are almost false. However, when I set fft-length to 128, subcarriers to 64, nearly all packets can be decode correctly. I feel so confused about that. Does anyone know that? Sent from my iPhone ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Trouble building gnuradio/next (Linux Mint 14/64)
Now I get into trouble with Kubuntu 12.04 32bit when building it: 36%] Built target _gnuradio_core_filter_swig_tag Linking CXX shared module _gnuradio_core_filter.so [ 36%] Built target _gnuradio_core_filter [ 36%] Built target _gnuradio_core_general_swig_tag [ 36%] Building CXX object gnuradio- core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o /home/ras/gnuradio/master/gnuradio- core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6083:22: error: redefinition of ‘struct swig::traits’ /home/ras/gnuradio/master/gnuradio- core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5498:22: error: previous definition of ‘struct swig::traits’ /home/ras/gnuradio/master/gnuradio- core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6087:23: error: redefinition of ‘struct swig::traits_asval’ /home/ras/gnuradio/master/gnuradio- core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5502:23: error: previous definition of ‘struct swig::traits_asval’ /home/ras/gnuradio/master/gnuradio- core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6093:23: error: redefinition of ‘struct swig::traits_from’ /home/ras/gnuradio/master/gnuradio- core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5508:23: error: previous definition of ‘struct swig::traits_from’ /home/ras/gnuradio/master/gnuradio- core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:6103:22: error: redefinition of ‘struct swig::traits >’ /home/ras/gnuradio/master/gnuradio- core/src/lib/swig/gnuradio_core_generalPYTHON_wrap.cxx:5518:22: error: previous definition of ‘struct swig::traits >’ make[2]: *** [gnuradio- core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/gnuradio_core_generalPYTHON_wrap.cxx.o] Error 1 make[1]: *** [gnuradio- core/src/lib/swig/CMakeFiles/_gnuradio_core_general.dir/all] Error 2 make: *** [all] Error 2 ras@dk5ras:~/gnuradio/master$ On Tuesday, March 26, 2013 09:47:54 PM you wrote: > I just pushed what should be a fix for this. It built on my VM of Mint 14. > > Tom > > >> -Original Message- > >> From: discuss-gnuradio-bounces+ralph=schmid@gnu.org > >> [mailto:discuss-gnuradio-bounces+ralph=schmid@gnu.org] On Behalf Of > >> Alexandru Csete > >> Sent: Saturday, 23 March, 2013 16:23 > >> To: Tom Rondeau > >> Cc: GNURadio Discussion List > >> Subject: Re: [Discuss-gnuradio] Trouble building gnuradio/next (Linux > >> Mint > >> 14/64) > >> > >> Hi Tom, > >> > >> Disabling the ATSC component did it! You are right, I don't need it. > >> Enjoy your vacation! > >> > >> Alex > >> > >> ___ > >> Discuss-gnuradio mailing list > >> Discuss-gnuradio@gnu.org > >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
