Re: [Discuss-gnuradio] wbx usrp1 sampling spectrum distortion
On 04/20/2010 08:28 PM, Kyle Zhou wrote: Matt Ettus wrote: On 04/20/2010 02:51 AM, Kyle Zhou wrote: Hi I use WBX + USRP1 to capture a DAB+ digital radio broadcast signal at frequency 204.64MHz and bandwidth 1.4MHz. Sampling rate is 2Msps (decimation=32) The spectrum shown by usrp_fft.py is normal and clean. However, after capturing the data using usrp_rx_cfile.py and loading the data to Matlab and show the spectrum, I found an unexpected portion of spectrum around the Nyquist frequency (1MHz in this case). The parameters I use for usrp_rx_cfile and usrp_fft are the same: -f 204.64M -d 32 -g 6. I uploaded a snapshot of the spectrum: http://lh4.ggpht.com/_ozkfEhDY6Mg/S81p3QihHkI/AsE/KJ8vtRo4EI4/spec_samp.jpg I can filter out the undesired part easily but that cost computational resource and I do want to find out the cause. Regards Kyle 2 MS/s complex should give a spectrum of -1 to +1 MHz. Your Matlab plot show 0 to 2 MHz, so I think you are loading the samples as reals instead of floats. Matt Thanks Matt. But I can confirm that I loaded complex data into Matlab using read_cshort_binary() provided by Gnuradio. Then I used pwelch() function to produce the power spectrum density estimate. According to the Matlab documentation, this function does accept complex data. It is because the frequencies at which the PSD is estimated is always in [0,Fsampling), the spectrum shows 0 to 2MHz, and I think 2MHz is equivalent to -1MHz, isn't it? I check the usrp_fft.py spectrum today again, using a sampling rate of 4M, now I can see there are adjacent channels at both sides. So I think the undesired spectral portion is from these neighbor channels. Regards Kyle ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio By default usrp_rx_cfile.py outputs complex floats, and read_cshort_binary() expects complex shorts. Looks to me like the -s parameter to usrp_rx_cfile.py causes it to output complex shorts, which would compatible with your matlab function, read_cshort_binary(). Marcus Leech Thanks Marcus I confirm that I did use the switch -s to usrp_rx_cfile.py. And I can be almost sure now that the undesired spectrum are caused by neighbour channels. fortunately, they are not bad enough to prevent OFDM demodulation as I am working on for the moment. Kyle ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 FPGA configuration with 16, 8, 4, 2, and 1-bit quantization options available for test
On 04/08/2010 06:11 PM, Shivaramaiah, Nagaraj wrote: 1) Has this configurable bit-width revision been merged? I could not see the rx_buffer.v modifications in 3.2.2 nor any modifications towards this feature on the host side. 2) Is there any branch doing the required modifications on the host side? I want to decide on whether to revisit my non-working host side modifications that I left several months ago Thanks in advance, Best regards, Nagaraj On Thu, Feb 05, 2009 at 04:47:08PM -0500, Paul Creekmore wrote: / For whoever is interested, I have a branched revision of the USRP1 FPGA/ / code ready that supports 16, 8, 4, 2, and 1-bit quantization. The/ / Verilog code is available for review in my developer's branch of the GNU/ / Radio SVN repository here:/ // / http://gnuradio.org/svn/gnuradio/branches/developers/pcreekmore/quantization/usrp/ This has not been merged. We are now using git. If you can get me a patch I can create a branch in the new git repo and we can look at merging it then. Thanks, Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio researchers in Poland
Hello All, Not sure whether this is the right place to ask such questions, but I am interested whether there are any GNU Radio research programs in Poland. --- Yarek ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 2channel USRP2 with Ext RF frontend
Hi all, is not clear for me if using a single USRP2 with 2 external RF downconverters is possible to obtain the IQ samples from two channels. From the FAQ seems that should be possible using the BasicRX with the 2 RF front-ends connected to the two BasicRx RF input. Can someone help me to clarify this issue ? Thanks Luca ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DPSK Modulator and Demodulator
Hi, I am having trouble the the DBPSK mod and demod blocks. My flow graph is: file source - DBPSKmod - DBPSKdemod - file sink If anyone knows why the output file of the whole graph would be 13 bytes or if I am missing something please let me know. Thanks, Dave On Wed, Apr 21, 2010 at 9:46 PM, marcin_w mwie9...@uni.sydney.edu.au wrote: My mistake, i didn't realise you were using the available DBPSK block. The Packed to Unpacked block is already part of this Modulator, so disregard my comment. Does the bpsk block you're using have some form of timing correction in it? More than likely the data is being run through some sort of filter (either explicitly or effectively) and the zeros at the beginning are a warm up from the padding. If you'd like the output to be 'nice' from a mathematical point of view you will have to deconstruct the mod/demod blocks a little bit and remove the timing correction stages and make sure that your simulated channel does not introduce any timing corrections. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Accessing Parallel Port
How can I access parallel port(read and write) in GRC? Regards, Umair Naeem MSc Communication Engineering Chalmers University ot Technology, Sweden. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Regarding...modulation used by usrp...
On Thu, Apr 22, 2010 at 7:31 AM, Muhammad Ali Khan mak...@gmail.com wrote: I don't know thats why i am asking, or may be amplitude modulation just guessing. As long as you possess the knowledge of how to transmit and receive the type of modulated signal you dream up, you can use software defined radio to help you out. That's the beauty of SDR. There are a bunch of examples that people have written and are included with GNU Radio, but the USRP itself is not limited to just those. Hope this helps answer your question. Brian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] OSX Testing Request for Branch
I'm in a place where I have no USRP with which to test some changes. The change is to move from a mix of threading via gr-omnithread and darwin pthreads (via an intermediate class I called 'mld_threads') to the gruel:: namespace threads. Here's the info: $ git checkout wip/remove-mld-threads will checkout the branch from the GNU Radio GIT repository, and switch to that branch. You can do a usual 'make' to build everything (2 Makefile.am's were changed, but those will be rebuilt during 'make'); compiling works for me, as do the changes to gr-audio-osx. So, what I'm hoping someone can do is try GNU Radio with a USRP and this branch, to verify that the darwin USRP FUSB code still works. When you're done, you can go back to GNU Radio GIT master with: $ git checkout master Thanks! - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] OSX Testing Request for Branch
On Thu, Apr 22, 2010 at 06:50, Michael Dickens m...@alum.mit.edu wrote: I'm in a place where I have no USRP with which to test some changes. The change is to move from a mix of threading via gr-omnithread and darwin pthreads (via an intermediate class I called 'mld_threads') to the gruel:: namespace threads. Here's the info: $ git checkout wip/remove-mld-threads Actually, I steered Michael wrong on this. The correct method to check out the test branch if you have a normal git clone is: $ git checkout -b wip/remove-mld-threads origin/wip/remove-mld-threads This creates a local tracking branch and switches to it. When you are done testing, you can remove your local branch: $ git checkout master $ git branch -D wip/remove-mld-threads Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] overrun problem on gr-sounder project
Hi Johnathan, I'm modifying the gr-sounder project to transmit a 113-bit legendre sequence of the bandwith 32kHz and upconvert to certain frequency in the range 1MHz to 20MHz. At receiver side, the received signal is downconverted to baseband and store the received sequence into a data file. The daughterbaord I'm using is LFTX/LFRX. I modified the FPGA configuration by using clk_divider to downconvert the mater_clock, clk64 to 32kHz, and applied the 32kHz to module adc_interface, sounder,rx_buffer, dac_interface instead of clk64. The other modules still keep the chip-rate(clk64) as the working frequency. At the receiver side, I got rid of the correlation part, made the receiver directly store the received data into rx_buffer. The result shows some USRP overrun signs (uO), and the received data is as shown below: -1 - 1i -1 + 0i 0 + 0i 0 + 0i 0 + 0i 0 - 1i -1 - 1i -1 - 1i -1 - 1i 0 + 0i 0 + 0i 0 + 0i 0 + 0i -1 - 1i -1 - 1i -1 - 1i -1 + 0i 0 + 0i 0 + 0i 0 + 0i However, the frequency of baseband data should be 32kHz, which doesn't exceed the maximum USB data rate 8MHz, why the USRP overrun? The received data should be the amplitude of the code, 4096, and the data should be real part only. What is the possible reason why the received data is as the shown. Thank you so much! Regards, Yan attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fix for usrp2 overruns when stopping and restarting rx streaming
Hi Johnathan, I have updated to 3.3git-473-g41526cd4. It seems the lastest version from the last week. However, 'S' is still shown on the console everytime after I use stop wait and start the flow graph again. And received samples is not reset which caused a obvious delay for further application. I have stuck it for quite long time. Can I reset the sample data manual in python? thank you. Andy Johnathan Corgan-2 wrote: On Wed, Apr 21, 2010 at 04:08, Martin DvH gnuradiom...@olifantasia.com wrote: This single line patch fixes this. This has been applied on the master branch. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/fix-for-usrp2-overruns-when-stopping-and-restarting-rx-streaming-tp28314794p28331249.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fix for usrp2 overruns when stopping and restarting rx streaming
Hi, Martin
Can you put your version number if you have solved it?
thank you.
Andy
Martin Dvh wrote:
Hi All,
When you use an USRP2 for capturing and you call
u2-stop_rx_streaming()
and later
u2-start_rx_streaming(0)
You always get a single overrun.
-a single 'S' is output on the console
-u2-rx_overruns() returns 1 (in stead of 0)
I am developing a usrp2 application which does not permit any overrun
conditions, so this needed fixing.
It turns out that the expected sequence number of received samples is
not reset when stopping the stream.
This single line patch fixes this.
Best Regards,
Martin
diff --git a/usrp2/host/lib/usrp2_impl.cc b/usrp2/host/lib/usrp2_impl.cc
index b19c6ec..92d52db 100644
--- a/usrp2/host/lib/usrp2_impl.cc
+++ b/usrp2/host/lib/usrp2_impl.cc
@@ -814,6 +814,7 @@ namespace usrp2 {
success = transmit_cmd_and_wait(cmd, sizeof(cmd), p,
DEF_CMD_TIMEOUT);
success = success (ntohx(reply.ok) == 1);
d_channel_rings[channel].reset();
+ d_rx_seqno=-1;
//fprintf(stderr, usrp2::stop_rx_streaming: success = %d\n,
success);
return success;
}
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--
View this message in context:
http://old.nabble.com/fix-for-usrp2-overruns-when-stopping-and-restarting-rx-streaming-tp28314794p28331267.html
Sent from the GnuRadio mailing list archive at Nabble.com.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fix for usrp2 overruns when stopping and restarting rx streaming
On Thu, Apr 22, 2010 at 09:21, Andy_Long luckshiw...@yahoo.com.cn wrote: I have updated to 3.3git-473-g41526cd4. It seems the lastest version from the last week. The latest git master is 3.3git-725-g8d3a78da; however, it is only available via using git to clone the repository. It looks like you downloaded an older test tarball from the gnuradio.org website. There is actually a newer one, -594, but that still doesn't have the fix you were looking for. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] CGRAN: new projects added updates
Hi all, For those of you unfamiliar with CGRAN, it is a host for 3rd party GNU Radio applications: https://www.cgran.org Just to settle some quick confusion, you do NOT need an account on CGRAN to checkout a project. You only need an account if you wish to make wiki or code changes. So, you are free to checkout any project anonymously :) Though, I appreciate if you register anyways, it gives me an idea of who uses CGRAN! We are ALMOST to 100 registered users, currently at 94! Its success is great, I've read a few published wireless papers this year that used code from CGRAN for their project, and in some cases even cited CGRAN ;) Thanks to all who have contributed to and used CGRAN! -- New Projects -- Smartnet Trunking Receiver (Nick Foster) - This module implements a receiver for Motorola Smartnet trunked radio systems. It replicates most of the functionality of a simple trunked scanner, and you can also use this module to receive the entire trunked network in real time and log it to disk. Typical scanners are limited to receiving one channel at a time. IT++ Wrappers (Martin Braun) - This module attempts to wrap IT++ function into GNU Radio blocks. IT++ is a C++-based library for running communication based simulations, and includes channel coding functions, mobile propagation channel models and some mathematical tool needed in communications engineering and DSP development. Split-Functionality MAC Protocols (George Nychis) - We take a split-functionality approach to implementing core MAC functions between the host processor and radio hardware to allow high-performance MAC implementations on high-latency SDRs. We provide basic building blocks to build MAC protocols on GNU Radio and the USRP, and provide implementations of a CSMA and TDMA MAC protocol from which you can build. IEEE802.11a/g/p OFDM Frame Encoder (Telecomm. Research Center Vienna (FTW)) - This encoder is able to generate and transmit standard-compliant IEEE802.11a, IEEE802.11g or IEEE802.11p (draft) frames using the GNURadio framework. The package consists of python scripts and C++ sourcecode for all required processing steps. Also included is a reference encoder script (to be used within MATLAB, in the src/matlab directory) that was written in the first phase of development of the GNURadio-based encoder. RFID Reader, Gen 2 (Michael Buettner) - This project implements a Gen 2 RFID reader capable of inter-operating with commercial tags. To meet the timing requirements of the Gen 2 standard, a number of optimizations were necessary, including modifications to GNU Radio's USB subsystem. For our application, we were able to achieve 300 us system latencies. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] 2channel USRP2 with Ext RF frontend
On 04/22/2010 03:55 AM, Luca Pascale wrote: Hi all, is not clear for me if using a single USRP2 with 2 external RF downconverters is possible to obtain the IQ samples from two channels. From the FAQ seems that should be possible using the BasicRX with the 2 RF front-ends connected to the two BasicRx RF input. Can someone help me to clarify this issue ? Thanks Luca You can use 2 downconverters if they downconvert to an IF, since there are 2 ADCs. If they downconvert to complex baseband (IQ) then you would need 4 ADCs and you don't have enough on the USRP2. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large number of overflows...
On 04/11/2010 09:22 PM, Ian Holland wrote: Hi All I am trying a modified example of the digital-bert routines, for communication between 2 USRP2s, and notice that I am getting a very large number of overflows () even with decimation rate at the receiver of 20, and 4 samples per symbol (sometimes even with 20 samples/symbol). If I don't get overflows (as has occurred when I used 20 for decimation as well as 20 for samples/symbol in one instance), I am able to capture the demodulated bits as ..., as expected for the example. However, with overruns, which seem to occur more for lower samples per symbol and/or lower decimation values, I get a large number of bit errors. My receiver flowgraph is of the form: USRP2 Source -- RRC Filter -- Costas Loop -- Mueller and Muller Synch -- Complex to Real -- Binary Slicer -- Descrambler -- File Sink. The transmitter flowgraph uses the same blocks as per digital-bert/transmit_path.py, but with a USRP2 sink. I am transmitting over-the-air, and clocks are not synchronised between Tx and Rx. I have a gigabit Ethernet link, and 2 x 2 GHz CPUs in my PC, which is running Ubuntu 9.10. Can anyone suggest why I am getting so many over-runs, and how I could get around this problem? These overflows indicate one of two things: - that your flowgraph is too slow to execute in real time on your computer - You haven't enabled realtime scheduling. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] CGRAN: new projects added updates
On 04/22/2010 10:09 AM, George Nychis wrote: Hi all, For those of you unfamiliar with CGRAN, it is a host for 3rd party GNU Radio applications: https://www.cgran.org Just to settle some quick confusion, you do NOT need an account on CGRAN to checkout a project. You only need an account if you wish to make wiki or code changes. So, you are free to checkout any project anonymously :) Though, I appreciate if you register anyways, it gives me an idea of who uses CGRAN! We are ALMOST to 100 registered users, currently at 94! Its success is great, I've read a few published wireless papers this year that used code from CGRAN for their project, and in some cases even cited CGRAN ;) Thanks to all who have contributed to and used CGRAN! George, I want to thank you, as CGRAN has become a great resource for the whole community. I know you've put in a lot of work running it, and it is very much appreciated. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] overrun problem on gr-sounder project
I'm modifying the gr-sounder project to transmit a 113-bit legendre sequence of the bandwith 32kHz and upconvert to certain frequency in the range 1MHz to 20MHz. At receiver side, the received signal is downconverted to baseband and store the received sequence into a data file. There is no way to diagnose what you are doing incorrectly, as you are writing your own modified FPGA code. However, my question to you is--why are you doing this in the FPGA at all? The gr-sounder component was designed as a way of processing a very wide bandwidth signal (up to the full baseband bandwidth of the daughterboard in use). Due to limitations in the transport speed of USB, this can *only* be done on the FPGA. You describe a baseband waveform of 32 ksps, and you are storing the received signal samples to a file. Why don't you just use the stock FPGA image and write a simple GNU Radio application? Thank you so much Johnathan. If writing a new GNU Radio application which implement the same functionality as what you did in gr-sounder, is there any existing project in GNURadio packet, which I can refer to? I'm doing the very similar thing as what you did in gr-sounder, transmitting a 113-bit sequence of the frequency 32kHz modulated as BPSK with the user provided center frequency. The received signal is down converted to baseband and directly stored in a data file. Thank you again Regards, Yan attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] DPSK Modulator and Demodulator
From: Jason Uher jasonu...@gmail.com To: discuss-gnuradio@gnu.org; david.barto...@yahoo.com Sent: Thu, April 22, 2010 7:51:41 AM Subject: Re: [Discuss-gnuradio] DPSK Modulator and Demodulator Thanks Jason. I have not delved into the code of the dbpsk demodulator GRC block yet so I am unsure. I was hoping someone with experience using this GRC block could answer quicker. I believe the block has a root raised cosine filter in it so it would make sense that it would have zeros to start but I am not sure why I get 13 bytes of output data back from 2 bytes of input data. Thanks, Dave Hi, I am having trouble the the DBPSK mod and demod blocks. My flow graph is: file source - DBPSKmod - DBPSKdemod - file sink If anyone knows why the output file of the whole graph would be 13 bytes or if I am missing something please let me know. Thanks, Dave On Wed, Apr 21, 2010 at 9:46 PM, marcin_w mwie9...@uni.sydney.edu.au wrote: My mistake, i didn't realise you were using the available DBPSK block. The Packed to Unpacked block is already part of this Modulator, so disregard my comment. Does the bpsk block you're using have some form of timing correction in it? More than likely the data is being run through some sort of filter (either explicitly or effectively) and the zeros at the beginning are a warm up from the padding. If you'd like the output to be 'nice' from a mathematical point of view you will have to deconstruct the mod/demod blocks a little bit and remove the timing correction stages and make sure that your simulated channel does not introduce any timing corrections. Jason ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fix for usrp2 overruns when stopping and restarting rx streaming
Hi, Johnathan I installed from binary package installation for Ubuntu 9.04. Last time you said that You'll need to switch from the binary install you have now to a source code install from the git tree to get the fix. But the install guide from gnuradio wiki only shows that how to transfer from already installed GNU Radio on your system via a source compile to binary packages. Actually there is any information for people go for opposite direction. Furthermore, the source code install build guide for Ubuntu shows that The rest of this page is now somewhat outdated and needs some reorganization. I have two questions. 1, Can I keep all the package for gnuradio from binary package and update to the newest version by using git? 2, When I can track the 3.3git-725-g8d3a78da version from Ubuntu Jaunty (9.04) Distribution unstable development branch . Will it be available in April or May? thank you. Andy Johnathan Corgan-2 wrote: On Thu, Apr 22, 2010 at 09:21, Andy_Long luckshiw...@yahoo.com.cn wrote: I have updated to 3.3git-473-g41526cd4. It seems the lastest version from the last week. The latest git master is 3.3git-725-g8d3a78da; however, it is only available via using git to clone the repository. It looks like you downloaded an older test tarball from the gnuradio.org website. There is actually a newer one, -594, but that still doesn't have the fix you were looking for. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio -- View this message in context: http://old.nabble.com/fix-for-usrp2-overruns-when-stopping-and-restarting-rx-streaming-tp28314794p28333835.html Sent from the GnuRadio mailing list archive at Nabble.com. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] fix for usrp2 overruns when stopping and restarting rx streaming
On Thu, Apr 22, 2010 at 12:51, Andy_Long luckshiw...@yahoo.com.cn wrote: 1, Can I keep all the package for gnuradio from binary package and update to the newest version by using git? No. You will need to uninstall the binary packages. 2, When I can track the 3.3git-725-g8d3a78da version from Ubuntu Jaunty (9.04) Distribution unstable development branch . Will it be available in It is available now; that is the latest commit to our GNU Radio development tree. Go to this wiki page, then go to Development: http://gnuradio.org/redmine/wiki/gnuradio/Download You will use the git source code repository client to create a local copy of the source code, then compile and install from there according to the Ubuntu installation for your version. The window for 3.3 development is now closing very rapidly, and I expect to have 3.3 stable released in May. We'll have new binary packages at that point. Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] overrun problem on gr-sounder project
Hi Johnathan, Thank you so much for the response on the suggestion of BPSK modulation implementation. I still have some questions on FPGA configuration and USRP baord: 1. What signal on the input of the receiver side (rx_a_a and rx_b_a) in gr-sounder application? (should the 12-bit signal be the amplitude of the received signal, which corresponds to the amplitude the usr provided?) 2. How does the tune() function work? Does that tune the signal after ADC, by creating a analog daughterboard? or it tunes the signal on the LFRX daughterboard before ADC? Thank you so much! Regards, Yan attachment: ynie3.vcf___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] overrun problem on gr-sounder project
On Thu, Apr 22, 2010 at 4:38 PM, Yan Nie yn...@uwo.ca wrote: 2. How does the tune() function work? Does that tune the signal after ADC, by creating a analog daughterboard? or it tunes the signal on the LFRX daughterboard before ADC? I looked at the source and found the following. /*! * \brief High-level tune method. Works for the single channel case. * * This method adjusts both the daughterboard LO and the DDC so that * target_freq ends up at DC in the complex baseband samples. * * \param chan which DDC channel we're controlling (almost always 0). * \param dbthe daughterboard we're controlling. * \param target_freq the RF frequency we want at DC in the complex baseband. * \param[out] result details how the hardware was configured. * * \returns true iff everything was successful. */ Thomas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UDP source block in GRC
On Fri, Apr 09, 2010 at 10:23:43PM -0400, Marcus D. Leech wrote: I'm trying to use a UDP source block from a GRC-produced flowgraph. The only thing it does is this: gr_block_executor: source gr_block udp_source (2) produced no output. We're marking it DONE. The udp source/sink needs an overhaul. This error is triggered to indicate that the block (a source) is returning zero, and thus is most likely spinning. Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] UDP source block in GRC
On 04/22/2010 06:24 PM, Eric Blossom wrote: On Fri, Apr 09, 2010 at 10:23:43PM -0400, Marcus D. Leech wrote: I'm trying to use a UDP source block from a GRC-produced flowgraph. The only thing it does is this: gr_block_executor: source gr_block udp_source (2) produced no output. We're marking it DONE. The udp source/sink needs an overhaul. This error is triggered to indicate that the block (a source) is returning zero, and thus is most likely spinning. Eric Well, I got around this problem by using a gr.file_source instead, which was actually a FIFO, and then used nc (netcat) to grab the UDP packets. -- Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Large number of overflows...
Hi Matt Myself and a colleague have created a C++ equivalent for the same flowgraph, with realtime scheduling enabled. We still have overruns for data rates above 2 Mbps, even on a Core i7 machine. We will try and make a multi-threaded version to hopefully resolve this, since our version is only single-threaded at this stage. In regards to using GRC to create the flowgraph, how can I check if realtime scheduling is enabled, and/or enable realtime scheduling? Thanks Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Matt Ettus Sent: Thursday, 22 April 2010 4:15 PM To: Ian Holland Cc: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Large number of overflows... On 04/11/2010 09:22 PM, Ian Holland wrote: Hi All I am trying a modified example of the digital-bert routines, for communication between 2 USRP2s, and notice that I am getting a very large number of overflows () even with decimation rate at the receiver of 20, and 4 samples per symbol (sometimes even with 20 samples/symbol). If I don't get overflows (as has occurred when I used 20 for decimation as well as 20 for samples/symbol in one instance), I am able to capture the demodulated bits as ..., as expected for the example. However, with overruns, which seem to occur more for lower samples per symbol and/or lower decimation values, I get a large number of bit errors. My receiver flowgraph is of the form: USRP2 Source -- RRC Filter -- Costas Loop -- Mueller and Muller Synch -- Complex to Real -- Binary Slicer -- Descrambler -- File Sink. The transmitter flowgraph uses the same blocks as per digital-bert/transmit_path.py, but with a USRP2 sink. I am transmitting over-the-air, and clocks are not synchronised between Tx and Rx. I have a gigabit Ethernet link, and 2 x 2 GHz CPUs in my PC, which is running Ubuntu 9.10. Can anyone suggest why I am getting so many over-runs, and how I could get around this problem? These overflows indicate one of two things: - that your flowgraph is too slow to execute in real time on your computer - You haven't enabled realtime scheduling. Matt ___ 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] Large number of overflows...
In regards to using GRC to create the flowgraph, how can I check if realtime scheduling is enabled, and/or enable realtime scheduling? Select realtime scheduling in the options block. If your flow graph fails to enable it at runtime, an error message is printed. -Josh ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large number of overflows...
On 04/22/2010 04:38 PM, Ian Holland wrote: Hi Matt Myself and a colleague have created a C++ equivalent for the same flowgraph, with realtime scheduling enabled. We still have overruns for data rates above 2 Mbps, even on a Core i7 machine. We will try and make a multi-threaded version to hopefully resolve this, since our version is only single-threaded at this stage. I am pretty sure that what you are seeing is that your application is not keeping up. The USRP2 keeps sending data to the computer as fast as it generates it. The ethernet card DMAs it into some buffer in memory. Your app uses it and the driver then frees the buffer. If at some point the driver receives a frame and there is no buffer free for it then the packet will be dropped, and you'll see an S. S stands for sequence number error, which is how the system can tell that there is a dropped packet. It is an overrun occurring in the computer, not in the hardware. The hardware will not overrun. The best way to test what is happening is to run usrp2_fft.py. If you can run that at the same or higher sample rates than you are using in your application, then the driver is not the issue. My guess is that your computer will run without problem at decimation of 6 at worst, and more likely all the way down to 4. Your app is running at a decimation of around 12 or 16, so it is your app that can't keep up. Think of it this way -- the fastest Core i7 machines are 3.2 GHz. For a 2 Mbps signal, you only have 1600 cycles per data bit. Assuming you are using at least 2 samples per bit, you only have 800 cycles per sample to process them. This is certainly possible, but you will need to optimize your code. How long are your filters? Are you using FFT-based filters instead of convolution based? Is too much memory getting copied around? In regards to using GRC to create the flowgraph, how can I check if realtime scheduling is enabled, and/or enable realtime scheduling? It is the last option in the Options top block. Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large number of overflows...
On 04/22/2010 07:56 PM, Matt Ettus wrote: I am pretty sure that what you are seeing is that your application is not keeping up. The USRP2 keeps sending data to the computer as fast as it generates it. The ethernet card DMAs it into some buffer in memory. Your app uses it and the driver then frees the buffer. If at some point the driver receives a frame and there is no buffer free for it then the packet will be dropped, and you'll see an S. S stands for sequence number error, which is how the system can tell that there is a dropped packet. It is an overrun occurring in the computer, not in the hardware. The hardware will not overrun. The best way to test what is happening is to run usrp2_fft.py. If you can run that at the same or higher sample rates than you are using in your application, then the driver is not the issue. My guess is that your computer will run without problem at decimation of 6 at worst, and more likely all the way down to 4. Your app is running at a decimation of around 12 or 16, so it is your app that can't keep up. Think of it this way -- the fastest Core i7 machines are 3.2 GHz. For a 2 Mbps signal, you only have 1600 cycles per data bit. Assuming you are using at least 2 samples per bit, you only have 800 cycles per sample to process them. This is certainly possible, but you will need to optimize your code. How long are your filters? Are you using FFT-based filters instead of convolution based? Is too much memory getting copied around? For some perspective, based on USRP1 data. My radio astronomy application runs fairly well at 10.6Msps, on a Core 2 Quad 9XXX (9770?) machine, with 8G of memory, and clocked at about 3.2GHz. My application does a 1Hz-resolution FFT over the data (that's a 10.6M point FFT!), computes the total power, and also does interference notch filtering, using a FFT filter, plus SETI analysis, pulsar folding, and transient detection. It can keep up, but all 4 cores are pretty busy! I think Matt's analysis is pretty close to the mark. One of the mistakes people make (that I've also made) is to specify FIR filters with very-narrow transition widths--that will cause a very long filter to be created. Relaxing the skirts on the filter can dramatically reduce CPU consumption. I typically use filter skirts that are roughly 20-25% of the total bandwidth of the filter. In many applications, very tight filtering isn't a requirement for decent performance of the downstream demodulation, particularly when link margins are reasonably good anyway. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Large number of overflows...
On Thu, Apr 22, 2010 at 21:18, Marcus D. Leech mle...@ripnet.com wrote: My application does a 1Hz-resolution FFT over the data (that's a 10.6M point FFT!) Who would have thought ten years ago we'd be doing 10 million point FFTs in real-time on computers you can buy at the local store :-) Johnathan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Hi all, how to use gnuradio to get the distance between a special gsm phone and the usrp hardware?
Hi all, i am going to support this feature above gnuradio, but i know little about gnuradio before. What is the correct way to support this feature? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
RE: [Discuss-gnuradio] Large number of overflows...
Thanks Marcus Actually, the only filtering I did in the C++ version is for the MM clock recovery, i.e. in interpolating to get the symbols based on imperfectly timed samples. In the GRC example, I also had an RRC filter, with 11*samples_per_symbol taps, but this didn't appear to be the bottleneck. In both applications, the Costas loop and the MM timing recovery tend to be the problem. I think multithreading the C++ application will benefit, but I am not sure it is splittable into multiple threads other than possibly 3, since the Costas loop and also the MM loop are recursive in nature. By the way, FFTs don't seem to be such a problem, I can even get lower decimation rates for that, but to do the Costas/MM seems to be the big killer. Cheers Ian. -Original Message- From: discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org [mailto:discuss-gnuradio-bounces+ian.holland=rlmgroup.com...@gnu.org] On Behalf Of Marcus D. Leech Sent: Friday, 23 April 2010 1:48 PM To: discuss-gnuradio@gnu.org Subject: Re: [Discuss-gnuradio] Large number of overflows... On 04/22/2010 07:56 PM, Matt Ettus wrote: I am pretty sure that what you are seeing is that your application is not keeping up. The USRP2 keeps sending data to the computer as fast as it generates it. The ethernet card DMAs it into some buffer in memory. Your app uses it and the driver then frees the buffer. If at some point the driver receives a frame and there is no buffer free for it then the packet will be dropped, and you'll see an S. S stands for sequence number error, which is how the system can tell that there is a dropped packet. It is an overrun occurring in the computer, not in the hardware. The hardware will not overrun. The best way to test what is happening is to run usrp2_fft.py. If you can run that at the same or higher sample rates than you are using in your application, then the driver is not the issue. My guess is that your computer will run without problem at decimation of 6 at worst, and more likely all the way down to 4. Your app is running at a decimation of around 12 or 16, so it is your app that can't keep up. Think of it this way -- the fastest Core i7 machines are 3.2 GHz. For a 2 Mbps signal, you only have 1600 cycles per data bit. Assuming you are using at least 2 samples per bit, you only have 800 cycles per sample to process them. This is certainly possible, but you will need to optimize your code. How long are your filters? Are you using FFT-based filters instead of convolution based? Is too much memory getting copied around? For some perspective, based on USRP1 data. My radio astronomy application runs fairly well at 10.6Msps, on a Core 2 Quad 9XXX (9770?) machine, with 8G of memory, and clocked at about 3.2GHz. My application does a 1Hz-resolution FFT over the data (that's a 10.6M point FFT!), computes the total power, and also does interference notch filtering, using a FFT filter, plus SETI analysis, pulsar folding, and transient detection. It can keep up, but all 4 cores are pretty busy! I think Matt's analysis is pretty close to the mark. One of the mistakes people make (that I've also made) is to specify FIR filters with very-narrow transition widths--that will cause a very long filter to be created. Relaxing the skirts on the filter can dramatically reduce CPU consumption. I typically use filter skirts that are roughly 20-25% of the total bandwidth of the filter. In many applications, very tight filtering isn't a requirement for decent performance of the downstream demodulation, particularly when link margins are reasonably good anyway. -- Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
