Re: [Discuss-gnuradio] Three different USRP2 nodes are transmitting with almost exactly 1 MHz frequency offset
Thanks for the reply, Jason. The uhd_usrp_probe --version command gave the following result: linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.004.000-71810ad 003.004.000-71810ad Do I have to download the latest UHD image? The image that I am using right now was downloaded by one of my colleagues and I think that he did it recently. Also, I tried running the benchmark_tx and benchmark_rx codes with a 1 MHz frequency offset input, i.e., I gave the following commands: ./benchmark_tx.py -f 2.4G -r 1M -m gmsk -a "addr = 192.168.10.2" ./benchmark_tx.py -f 2.401G -r 1M -m gmsk -a "addr = 192.168.10.2" Since the uhd_fft.py and the my lab spectrum analyzer show a 1 MHz frequency offset, I assumed that the above commands would work. Unfortunately, this did not help either! Suggestions will be very appreciated. Thanks, Nazmul On Wed, Feb 8, 2012 at 7:37 PM, Jason Abele wrote: > On Wed, Feb 08, 2012 at 06:39:24PM -0500, Nazmul Islam wrote: > > Hello, > > > > I am running the benchmark_tx.py codes and looking at the spectrum of the > > signals using uhd_fft.py. I am using the latest image of GNU radio > > (GNUradio 3.5) and I have XCVR2450 daughterboards. I ran the > > benchmark_tx.py code in three transmitter nodes and surprisingly, all of > > them are transmitting with 1 MHz frequency offset! I have attached two > > screenshots with the email (I hope that they go through). I give the > > following input parameters to run the benchmark_tx code. > > > > ./benchmark_tx.py -f 2.4G -r 1M -m gmsk -M 10 -a "addr = 192.168.10.2" > > > > Both uhd_fft.py and the spectrum analyzer of my laboratory show that the > > received signal is centered at 2.401 GHz. I varied the frequency to 2.45 > > GHz, 2.41 GHz, but this 1 MHz frequency shift persists. > > > > When I run the benchmark_rx.py code at the receiver nodes, they don't > > receive/detect any packets (due to the frequency offset, I guess). I even > > tried to run the transmitter at 2.4 GHz and the receiver at 2.401 GHz. > > However, that did not help either! > > > > I will try to modify the control loop gain parameters using Tom's blogs > > suggestions and see if that helps. However, I am really surprised to see > > how all three different transmitter nodes can transmit with almost > exactly > > 1 MHz frequency offset. Any suggestion will be appreciated. > > > > Can you tell us which version of UHD you are using? > (uhd_usrp_probe --version) > > We have heard reports of such an issue and my best guess is that it was > related to an accidental swap of I and Q in the XCVR2450 transmitter > code. This went in after the 3.3.2 release and is fixed on latest UHD > master since 837437c65ce36d418cceb3df5b093f9497b3af5f > > Jason > -- Muhammad Nazmul Islam Graduate Student Electrical & Computer Engineering Wireless Information & Networking Laboratory Rutgers, USA. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Feature #394
Thanks, I think i'll work on QA too while i'm at it then. On Wed, Feb 8, 2012 at 10:32 PM, Tom Rondeau wrote: > On Tue, Feb 7, 2012 at 9:52 PM, Andrew Davis wrote: > >> Hello all, >> >> I would like to help expand the C++ API, so I'm attempting to work on >> Feature #394 or "Re-implement hierarchical blocks currently living in >> blks2 in C++ and put into gnuradio-core/src/lib/hier." I've started on >> am_demod.py but this requires optfir, which is also in python, I think this >> should also be available to us C++ users, so i'm converting it too. I'm >> new to GnuRadio and would like to know if i'm on the right track before I >> get to far. The files so far are included. >> >> Thank you. >> > > > Hi Andrew, > It looks to me like you're on the right track! Thanks for making a go at > it. > > So you seem to have the general style correct in the files that I looked > at. Once it's coded, the ultimate test is, obviously, to make sure that the > data produced by any of these guys is the same as is produced by the Python > versions. This is a good case where the QA code would be useful, so we > would have a set of tests with known output that you could compare against > the new implementations. Unfortunately, I don't see an QA for the optfir, > but it would probably be good to have one. > > Tom > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Feature #394
On Tue, Feb 7, 2012 at 9:52 PM, Andrew Davis wrote: > Hello all, > > I would like to help expand the C++ API, so I'm attempting to work on > Feature #394 or "Re-implement hierarchical blocks currently living in > blks2 in C++ and put into gnuradio-core/src/lib/hier." I've started on > am_demod.py but this requires optfir, which is also in python, I think this > should also be available to us C++ users, so i'm converting it too. I'm > new to GnuRadio and would like to know if i'm on the right track before I > get to far. The files so far are included. > > Thank you. > Hi Andrew, It looks to me like you're on the right track! Thanks for making a go at it. So you seem to have the general style correct in the files that I looked at. Once it's coded, the ultimate test is, obviously, to make sure that the data produced by any of these guys is the same as is produced by the Python versions. This is a good case where the QA code would be useful, so we would have a set of tests with known output that you could compare against the new implementations. Unfortunately, I don't see an QA for the optfir, but it would probably be good to have one. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Strange predicament
Hey, I having been trying to debug my demodulator for a few days now and in due process i receive the following error message. ValueError: itemsize mismatch : dbpsk_demod(5):0 using 1, sub_ff(15):0 using 4. Now there are two things that i observed. 1) With the connect statement of these two at hand , sub_ff is expecting 4 float bytes which is only connected to "1 byte/sample" output by the dbpsk_demod block. 2) The output of the dbpsk_demod block (according to the line -- > io_sig_out = gr.io_signature(1,1,gr.sizeof_char) .. so its a dbpsk_demod_complex->character conversion where as the sub_ff is a "float --> float " . My question is will a custom "gr_dbpsk_demod_cf" with a cosine function(that possibly uses a certain kind of cosine table) be useful to do the following : 1) keep the constellation in check (i.e 1 bit/symbol) at 0 and 180 degrees respectively. 2) ofcourse convert a complex to float. 3) How effective would such a cpp block be as opposed to a full fledged python block ? Thanks & regards, Anay. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Three different USRP2 nodes are transmitting with almost exactly 1 MHz frequency offset
On Wed, Feb 08, 2012 at 06:39:24PM -0500, Nazmul Islam wrote: > Hello, > > I am running the benchmark_tx.py codes and looking at the spectrum of the > signals using uhd_fft.py. I am using the latest image of GNU radio > (GNUradio 3.5) and I have XCVR2450 daughterboards. I ran the > benchmark_tx.py code in three transmitter nodes and surprisingly, all of > them are transmitting with 1 MHz frequency offset! I have attached two > screenshots with the email (I hope that they go through). I give the > following input parameters to run the benchmark_tx code. > > ./benchmark_tx.py -f 2.4G -r 1M -m gmsk -M 10 -a "addr = 192.168.10.2" > > Both uhd_fft.py and the spectrum analyzer of my laboratory show that the > received signal is centered at 2.401 GHz. I varied the frequency to 2.45 > GHz, 2.41 GHz, but this 1 MHz frequency shift persists. > > When I run the benchmark_rx.py code at the receiver nodes, they don't > receive/detect any packets (due to the frequency offset, I guess). I even > tried to run the transmitter at 2.4 GHz and the receiver at 2.401 GHz. > However, that did not help either! > > I will try to modify the control loop gain parameters using Tom's blogs > suggestions and see if that helps. However, I am really surprised to see > how all three different transmitter nodes can transmit with almost exactly > 1 MHz frequency offset. Any suggestion will be appreciated. > Can you tell us which version of UHD you are using? (uhd_usrp_probe --version) We have heard reports of such an issue and my best guess is that it was related to an accidental swap of I and Q in the XCVR2450 transmitter code. This went in after the 3.3.2 release and is fixed on latest UHD master since 837437c65ce36d418cceb3df5b093f9497b3af5f Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to learn of decimation rate in general_work() ?
Just to confirm, the USRP2/N2x0 ADC samples at 100MHz. (The DAC output however runs at 400MHz, its fed samples at 100MHz and it has built in 4x interpolation which may be the source of confusion). On Feb 8, 2012, at 4:12 PM, Tom Rondeau wrote: > On Tue, Feb 7, 2012 at 5:37 PM, George Nychis wrote: > > Hey George, > > You can use the relative_rate data member of the blocks. Setting the > decimation actually sets the relative_rate to 1.0/decimation. You can get > this value with the accessor function "relative_rate()". > > > Hey Tom, > > Using this I can get the decimation rate, but is there a way to get the rate > of samples from the ADC? That way I can compute the real clock time > in-between samples. For the USRP2, despite the ADC running running at > 400Msps, it's rate through the FPGA is actually 100Msps, right? > > Actually, I think the ADC is running at 100 Msps, which I think you can get > with the "get_clock_rate(mboard)" method. The rate that they come across is > then determined by the decimation rate. You can query sample rate from the > USRP via the UHD with the "get_sampl_rate()" method. > > Tom > > ___ > 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] how to learn of decimation rate in general_work() ?
On Tue, Feb 7, 2012 at 5:37 PM, George Nychis wrote: > >> Hey George, >> >> You can use the relative_rate data member of the blocks. Setting the >> decimation actually sets the relative_rate to 1.0/decimation. You can get >> this value with the accessor function "relative_rate()". >> >> > Hey Tom, > > Using this I can get the decimation rate, but is there a way to get the > rate of samples from the ADC? That way I can compute the real clock time > in-between samples. For the USRP2, despite the ADC running running at > 400Msps, it's rate through the FPGA is actually 100Msps, right? Actually, I think the ADC is running at 100 Msps, which I think you can get with the "get_clock_rate(mboard)" method. The rate that they come across is then determined by the decimation rate. You can query sample rate from the USRP via the UHD with the "get_sampl_rate()" method. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fft monitoring of more than one channel
On Wed, Feb 8, 2012 at 8:19 AM, Sebastian Döring wrote: > Hello list, > > I modified the usrp_spectrum_sense.py to work as an energy detector based > on the Neyman-Pearson Theorem. So basically the algorithm is supposed to > tell me if a certain part of the spectrum is occupied or not. > > I simply wrote the output into a text file to see I it is working at all, > but right now I am trying to find a way to somehow monitor the it in a > large plot, that dynamically changes with the current detection results. > That means that if I am sensing the spectrum for example between 2.4 and > 2.5GHz in steps of 20MHz, I want the the whole bandwidth to be graphically > displayed in some kind of plot (x-Axis = frequency, y-Axis = "0"/"1"), > which is divided into parts of 20MHz. > The channel states are supposed to get updated every time the channel is > sensed again, just like the output is already doing. > > I first thought that gtgui_sink_x might be the right thing, but since I am > peridically changing the frequency and the sink is designed to look at a > single center frequency, I don know how to append several frequency windows > to a large one. > I dont know if what I am planning to do is even possible using gnu radio > only. > > I higly appreciate any suggestions. > Thanks in advance. > > -Sebastian > If you want to show the whole spectrum in one qtgui window, it's going to take a bit of hacking. On the other hand, you can probably just use the qtgui right now. The block just takes in the data sent to it and plots it, regardless of where it came from. The center frequency of the plot is just for reference and doesn't have any real meaning for the data planned. This will only show a section of the full bandwidth at a time, but it might be enough to get you started. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Please Help: Unable to locate functions in benchmark code
Sorry for the truncated email. Here's the problem in detail: I'm a gnuradio newbie and I'm afraid I might be asking the stupidest question ever. I was going through the narrowband benchmark codes for my understanding, but was unable to locate the uhd.usrp_sink or uhd.usrp_source modules as used in the uhd_interface.py file. Also in transmit_path.py, I find the use of digital.mod_pkts, but once again I cannot find it in the expected location /usr/local/lib/python2.7/dist-packages/gnuradio/digital. Please help! -- Forwarded message -- From: Dhrubojyoti Roy Date: Wed, Feb 8, 2012 at 3:34 PM Subject: Please Help: Unable to locate functions in benchmark code To: discuss-gnuradio@gnu.org I'm a gnuradio newbie and I'm afraid I might be asking the stupidest question ever. I was going through the narrowband benchmark codes for my understanding, but was unable to locate the uhd.usrp_sink or uhd.usrp_source modules as mentioned in the -- Dhrubojyoti Roy 1655, North 4th Street, Apt-D Columbus, OH-43201 Contact no.: +1-740-417-5890 -- Dhrubojyoti Roy 1655, North 4th Street, Apt-D Columbus, OH-43201 Contact no.: +1-740-417-5890 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Please Help: Unable to locate functions in benchmark code
You should check out the gr-uhd directory, which contains the code for the UHD components in GNU Radio. Cheers, Ben On Wed, Feb 8, 2012 at 12:34 PM, Dhrubojyoti Roy wrote: > I'm a gnuradio newbie and I'm afraid I might be asking the stupidest > question ever. I was going through the narrowband benchmark codes for my > understanding, but was unable to locate the uhd.usrp_sink or > uhd.usrp_source modules as mentioned in the > > -- > Dhrubojyoti Roy > 1655, North 4th Street, Apt-D > Columbus, OH-43201 > Contact no.: +1-740-417-5890 > > > ___ > 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] Please Help: Unable to locate functions in benchmark code
I'm a gnuradio newbie and I'm afraid I might be asking the stupidest question ever. I was going through the narrowband benchmark codes for my understanding, but was unable to locate the uhd.usrp_sink or uhd.usrp_source modules as mentioned in the -- Dhrubojyoti Roy 1655, North 4th Street, Apt-D Columbus, OH-43201 Contact no.: +1-740-417-5890 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error in function boost::math::iround(d) in N200
Hi, Recently, I transform my OFDM code from USRP1 to N200 platform. My program runs well under USRP1 platform. But when I run the sender side code under N200 platform, the program aborted after sending several packets with the following tips: terminate called after throwing an instance of 'boost::exception_detail::clone_impl >' what(): Error in function boost::math::iround(d): Value -1.1320951704841588e+52 can not be represented in the target integer type. However, the receiver side program can receive the first 6 packets. When I run the sender side code in gdb, it shows the following content: ... 1328719879.791: Send packet 135 1328719879.791: Send packet 136 1328719879.791: Send packet 137 terminate called after throwing an instance of 'boost::exception_detail::clone_impl >' 1328719879.791: Send packet 138 what(): Error in function boost::math::iround(d): Value -1.1320951704841588e+52 can not be represented in the target integer type. 1328719879.791: Send packet 139 1328719879.792: Send packet 140 1328719879.792: Send packet 141 1328719879.792: Send packet 142 1328719879.792: Send packet 143 1328719879.792: Send packet 144 1328719879.792: Send packet 145 1328719879.792: Send packet 146 Program received signal SIGABRT, Aborted. [Switching to Thread 0xad4f1b70 (LWP 11811)] 0x0012e416 in __kernel_vsyscall () (gdb) bt #0 0x0012e416 in __kernel_vsyscall () #1 0x0034e941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x00351e42 in abort () at abort.c:92 #3 0x00aa2055 in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6 #4 0x00a9ff35 in ?? () from /usr/lib/libstdc++.so.6 #5 0x00a9eceb in ?? () from /usr/lib/libstdc++.so.6 #6 0x00a9f877 in __gxx_personality_v0 () from /usr/lib/libstdc++.so.6 #7 0x00af47e2 in ?? () from /lib/libgcc_s.so.1 #8 0x00af4c53 in _Unwind_Resume () from /lib/libgcc_s.so.1 #9 0x007b7080 in gr_block_executor::~gr_block_executor() () from /opt/gnuradio/lib/libgnuradio-core-3.5.2git.so.0.0.0 #10 0x007d9b61 in gr_tpb_thread_body::gr_tpb_thread_body(boost::shared_ptr, int) () from /opt/gnuradio/lib/libgnuradio-core-3.5.2git.so.0.0.0 #11 0x007d2c5c in boost::detail::function::void_function_obj_invoker0, void>::invoke(boost::detail::function::function_buffer&) () from /opt/gnuradio/lib/libgnuradio-core-3.5.2git.so.0.0.0 #12 0x00951fb5 in boost::detail::thread_data >::run() () from /opt/gnuradio/lib/libgruel-3.5.2git.so.0.0.0 #13 0x009e90f5 in thread_proxy () from /usr/lib/libboost_thread.so.1.42.0 #14 0x00134cc9 in start_thread (arg=0xad4f1b70) at pthread_create.c:304 #15 0x003f469e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 (gdb) It would be appreciated if any suggestion to address this error could provided! Regards! Yubo ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] fft monitoring of more than one channel
Hello list, I modified the usrp_spectrum_sense.py to work as an energy detector based on the Neyman-Pearson Theorem. So basically the algorithm is supposed to tell me if a certain part of the spectrum is occupied or not. I simply wrote the output into a text file to see I it is working at all, but right now I am trying to find a way to somehow monitor the it in a large plot, that dynamically changes with the current detection results. That means that if I am sensing the spectrum for example between 2.4 and 2.5GHz in steps of 20MHz, I want the the whole bandwidth to be graphically displayed in some kind of plot (x-Axis = frequency, y-Axis = "0"/"1"), which is divided into parts of 20MHz. The channel states are supposed to get updated every time the channel is sensed again, just like the output is already doing. I first thought that gtgui_sink_x might be the right thing, but since I am peridically changing the frequency and the sink is designed to look at a single center frequency, I don know how to append several frequency windows to a large one. I dont know if what I am planning to do is even possible using gnu radio only. I higly appreciate any suggestions. Thanks in advance. -Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Google Summer of Code '12 is On
Hi everyone, On Tue, Feb 07, 2012 at 09:46:08AM -0500, Philip Balister wrote: > At the last developer call I agreed to lead the GSoC effort. That's great! As you might know, I'm always interested in getting students involved in GNU Radio, so I'd like to join the mentoring crew. Also, I'd like to keep this thread going. Here's a wiki page for GSoc, to collect ideas etc.: http://gnuradio.org/redmine/projects/gnuradio/wiki/GSoC (the wiki is being quite slow, again). > Based on my prior experience with GSoC (via the BeagleBoard project), > the single most important part of the application is the list of ideas. > We need to start thinking about ideas that are possible for > undergrad/grad type students in a three month period. I also recommend > looking at idea list published by other successful organizations. Here's what GIMP did last year (just picked a random project): http://wiki.gimp.org/index.php?title=Hacking:GSoC_2011/Ideas Not too difficult, it seems :) > The application deadline is March 9. We should aim to be done before > that due to WSR12. So you're coming? :) 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-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 pgpLUI2aa8NXk.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
