[Discuss-gnuradio] Can not remove the receiving spike (DC component) by advanced tune request at USRP N210.
Hi, I always get a strong spike in the attachment, when using uhd_fft to measure the noise. Please note there is no any signal on the air, only noise, but I got this spike. I guess this is the so called DC component. Thus I tried to remove this spike, as stated in http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes, using the advanced tuning request. My sample rate is 2Ms, so as my understanding, I need to set the lo_offset as >= 4MHz, to get the spike out my band, like this: tune_req = uhd.tune_request(options.freq, 5e6) # with lo_offset = 5MHz usrp.set_center_freq(tune_req, 0) Then I get the tune result as: Tune Result: Target RF Freq: 2405.00 (MHz) Actual RF Freq: 2405.00 (MHz) Target DSP Freq: 5.00 (MHz) Actual DSP Freq: 5.00 (MHz) However, the spike is still there, almost the same, and the center frequency is even still the same (this could be due to the some GUI usage)! I really don't know if the advanced tuning works or not. It seems that the incoming streaming still contains the DC component. Spike of the received noise. [image: Inline image 1] <>___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems building GNURadio on Ubuntu 12.04LTS
On Mon, 2012-10-01 at 10:36 +0930, Berndt Josef Wulf wrote:
> On Sun, 2012-09-30 at 17:43 -0700, Josh Blum wrote:
> >
> >
> > I wonder how gnuradio got configured with uhd support? Thats actually
> > the one file the FindUHD.cmake looks for to confirm the header location:
> >
> > FIND_PATH(
> > UHD_INCLUDE_DIRS
> > NAMES uhd/config.hpp
> > HINTS $ENV{UHD_DIR}/include
> > ${PC_UHD_INCLUDEDIR}
> > PATHS /usr/local/include
> > /usr/include
> > )
> >
> > Thats just the first header it encounters. Theres probably some
> > installation issue. Can you post the ls /include/uhd/*
>
> I didn't have uhd installed and hence /usr/{local,}/include/uhd don't
> exist.
>
> Having said this, I had an older version installed, 3.5.2 if my memory
> serves me correctly, which was de-installed prior to updating and
> building the current source tree.
I've installed UHD and gnuradio builds fine.
Many thanks for your help and pointing me into the right direction.
73, Berndt
VK5ABN
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems building GNURadio on Ubuntu 12.04LTS
On Sun, 2012-09-30 at 17:43 -0700, Josh Blum wrote:
>
> On 09/30/2012 05:39 PM, Berndt Josef Wulf wrote:
> > G'day,
> >
> > I've downloaded today's sources and tried to build GNURadio on Ubuntu
> > 12.04LTS when I hit the following problem:
> >
> > [ 85%] Built target pygen_gr_trellis_src_examples_python_cef97
> > [ 85%] Building CXX object
> > gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o
> > In file included
> > from
> > /home/berndt/gnuradio/gnuradio/gr-uhd/include/gr_uhd_usrp_source.h:25:0,
> >
> > from /home/berndt/gnuradio/gnuradio/gr-uhd/lib/gr_uhd_usrp_source.cc:22:
> > /home/berndt/gnuradio/gnuradio/gr-uhd/include/gr_uhd_api.h:25:26: fatal
> > error: uhd/config.hpp: No such file or directory
> > compilation terminated.
> >
> > Searching the source tree, there indeed is no config.hpp. Is this file
> > generated during the configuration process?
> >
>
> I wonder how gnuradio got configured with uhd support? Thats actually
> the one file the FindUHD.cmake looks for to confirm the header location:
>
> FIND_PATH(
> UHD_INCLUDE_DIRS
> NAMES uhd/config.hpp
> HINTS $ENV{UHD_DIR}/include
> ${PC_UHD_INCLUDEDIR}
> PATHS /usr/local/include
> /usr/include
> )
>
> Thats just the first header it encounters. Theres probably some
> installation issue. Can you post the ls /include/uhd/*
I didn't have uhd installed and hence /usr/{local,}/include/uhd don't
exist.
Having said this, I had an older version installed, 3.5.2 if my memory
serves me correctly, which was de-installed prior to updating and
building the current source tree.
73, Berndt
VK5ABN
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems building GNURadio on Ubuntu 12.04LTS
On 09/30/2012 05:39 PM, Berndt Josef Wulf wrote:
> G'day,
>
> I've downloaded today's sources and tried to build GNURadio on Ubuntu
> 12.04LTS when I hit the following problem:
>
> [ 85%] Built target pygen_gr_trellis_src_examples_python_cef97
> [ 85%] Building CXX object
> gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o
> In file included
> from /home/berndt/gnuradio/gnuradio/gr-uhd/include/gr_uhd_usrp_source.h:25:0,
>
> from /home/berndt/gnuradio/gnuradio/gr-uhd/lib/gr_uhd_usrp_source.cc:22:
> /home/berndt/gnuradio/gnuradio/gr-uhd/include/gr_uhd_api.h:25:26: fatal
> error: uhd/config.hpp: No such file or directory
> compilation terminated.
>
> Searching the source tree, there indeed is no config.hpp. Is this file
> generated during the configuration process?
>
I wonder how gnuradio got configured with uhd support? Thats actually
the one file the FindUHD.cmake looks for to confirm the header location:
FIND_PATH(
UHD_INCLUDE_DIRS
NAMES uhd/config.hpp
HINTS $ENV{UHD_DIR}/include
${PC_UHD_INCLUDEDIR}
PATHS /usr/local/include
/usr/include
)
Thats just the first header it encounters. Theres probably some
installation issue. Can you post the ls /include/uhd/*
-josh
> 73, Berndt
> VK5ABN
>
>
> ___
> 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] Problems building GNURadio on Ubuntu 12.04LTS
G'day, I've downloaded today's sources and tried to build GNURadio on Ubuntu 12.04LTS when I hit the following problem: [ 85%] Built target pygen_gr_trellis_src_examples_python_cef97 [ 85%] Building CXX object gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o In file included from /home/berndt/gnuradio/gnuradio/gr-uhd/include/gr_uhd_usrp_source.h:25:0, from /home/berndt/gnuradio/gnuradio/gr-uhd/lib/gr_uhd_usrp_source.cc:22: /home/berndt/gnuradio/gnuradio/gr-uhd/include/gr_uhd_api.h:25:26: fatal error: uhd/config.hpp: No such file or directory compilation terminated. Searching the source tree, there indeed is no config.hpp. Is this file generated during the configuration process? 73, Berndt VK5ABN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Can another DUC chain be added to USRP N210?
On 09/29/2012 09:45 AM, Anisha Gorur wrote: > Thanks Josh, > What I am looking for on the TX side of things is basically the same thing > I have on the RX side. If I set the subdev spec on the basic RX to "A:A > A:B" and then use usrp->set_rx_freq(uhd::tune_request_t(freq)) for each > channel, I get two separate rx channels, both with their own IQ pairs. On > the TX side I only manage to have one IQ pair, as in I through TX_A and Q > through TX_B. We were trying for a 4 channel transmit on 2 USRPs, so that > they could all be connected by s MIMO cable. One more question, when you > say "too complicated to be worth it", generally, what kind of modification > would be necessary? The reason for the complication is there is this whole flow control implementation for the TX. Here is my suggestion: On the host, interleave your MIMO channels. So send 1 TX channel where the samples are ch0IQ0, ch1IQ0, ch0IQ1 In the FPGA, a good way is to modify the top level to have two DUC chains. See right here: http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/usrp2/top/N2x0/u2plus_core.v#L716 Instantiate two DUC chains. Most of the wires can stay the same. Since this is MIMO, you want both DUC chains to have the same settings anyways. What you want to do here is to play with the strobe_tx signal such that every even strobe is off for DUC0 and every off strobe is off for DUC1... thats effectively the deinterleave. Also notice how the tx_fe outputs are connected. reg even; always @(posedge dsp_clk) if (~run_tx) even <= 0; else if (strobe_tx) even <= ~even; duc_chain #(.BASE(SR_TX_DSP), .DSPNO(0)) duc_chain0 (.clk(dsp_clk),.rst(dsp_rst), .clr(clear_tx), .set_stb(set_stb_dsp),.set_addr(set_addr_dsp),.set_data(set_data_dsp), .set_stb_user(set_stb_user), .set_addr_user(set_addr_user), .set_data_user(set_data_user), .tx_fe_i(tx_fe_i),.tx_fe_q(), .sample(sample_tx), .run(run_tx), .strobe(strobe_tx & even), .debug() ); duc_chain #(.BASE(SR_TX_DSP), .DSPNO(0)) duc_chain1 (.clk(dsp_clk),.rst(dsp_rst), .clr(clear_tx), .set_stb(set_stb_dsp),.set_addr(set_addr_dsp),.set_data(set_data_dsp), .set_stb_user(set_stb_user), .set_addr_user(set_addr_user), .set_data_user(set_data_user), .tx_fe_i(tx_fe_q),.tx_fe_q(), .sample(sample_tx), .run(run_tx), .strobe(strobe_tx & ~even), .debug() ); -Josh > Thanks for your time! > -Anisha > > On Fri, Sep 28, 2012 at 6:36 PM, Josh Blum wrote: > >> >> >> On 09/28/2012 08:49 AM, Anisha Gorur wrote: >>> Hello All, >>> >>> I am using a USRP N210. When i set the subdev spec for my basic RX >>> daughterboard as "A:A A:B" I can receive two channels. However, if I try >> to >>> do something similar for the basic TX I get an error like "The user >>> specified 2 channels, but there are only 1 tx dsps on mboard 0." I assume >>> this is because there is only one DUC chain in the N210. Is there a way >> to >>> modify this so that I can have two DUC chains in the same way that I have >>> two DDC chains? >>> Thanks, >>> Anisha >> >> I think adding two complete DUC chains into N210 would be too >> complicated to be worth it. >> >> Is there something specific that you cant do with the single DUC chain? >> As long as the cordic is set to zero, I and Q will remain completely >> separate from host samples, all the way to the SMA connectors A and B. >> >> Otherwise, perhaps you need a different rotation for I vs Q? I think >> that would be better accomplished by two different cordics. Then perhaps >> a custom DSP in the FPGA is for you: >> >> http://code.ettus.com/redmine/ettus/projects/uhd/repository/revisions/master/entry/fpga/README.txt#L29 >> >> I hope that helps. >> >> -josh >> >>> >>> >>> >>> ___ >>> 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] 8-channel receiver
On 09/29/2012 09:46 AM, Anisha Gorur wrote: > Thanks Josh, that helps quite a bit! Our sampling frequency is not > particularly fast, it will only be around 5 MS/S. Right now the send and > receive frame size are still the defaults, 1472 for receive and 1444 for > send. In the notes, it says "to improve receive latency, configure the > transport for a smaller frame size", will this work for send latency as > well? Also is there an equation I can use to determine what the best frame > sizes would be, or should I just go with trial and error and use > latency_test.cpp to determine if it has shifted? If you change the frame > size, how much improvement in latency do you usually see? > Again, thank you so much. > -Anisha > The reason that shrinking the receive frame size reduces latency is that the RX DSP chain produces samples at a fixed rate. Therefore, the device cannot release a packet until samples_per_packet / sample_rate. The first sample is a packet is delayed by the time it takes to produce the last sample. However, in the case of transmission/send there is no such issue. Essentially your application is the pacer and producer of samples. So you have total control. -Josh > On Fri, Sep 28, 2012 at 6:57 PM, Josh Blum wrote: > >> >> >> On 09/28/2012 02:46 PM, Anisha Gorur wrote: >>> Thanks Matt! >>> Do you have any idea for what kind of latency we would expect? Also would >> >> The dominating factor in latency here is the gigabit ethernet, this >> tends to be around 100us. Here are a few notes about that: >> >> >> http://files.ettus.com/uhd_docs/manual/html/transport.html#latency-optimization >> >>> the data be routed through the host? My Radio, We only have a couple >> months >> >> Normally the samples would all go to the host computer that configured >> the USRP. It is possible to configure the USRP with one machine but send >> the samples to an arbitrary network location: >> >> >> http://files.ettus.com/uhd_docs/manual/html/usrp2.html#alternative-stream-destination >> >> For that matter, there is nothing wrong with splitting up the USRP >> configuration among several computers. It all depends how you plan on >> using the data. >> >>> to do this, but we have tried to synchronize USRPs before, so we are >> aware >>> of some of the problems. >> >> Anything in particular that I could help to clarify? >> >> -josh >> >>> Thanks, >>> Anisha >>> >>> On Wed, Sep 26, 2012 at 3:51 PM, My Radio >> wrote: >>> One should remember the extremes involved in syncing all USRP'S which >> will lead to developing a new driver for USRP2. What about the your APP development time?. Are you interested in developing new driver or app ? On Thu, Sep 27, 2012 at 12:04 AM, Matt Ettus wrote: > You can use a gigabit ethernet switch and put all the USRPs on there. > You should be able to make USRPs send data to each other. You will of > course need to do work to get your algorithms into the FPGA. > > Matt > > On Wed, Sep 26, 2012 at 12:38 PM, Anisha Gorur > wrote: >> I have a quick theoretical question. Is there any way to construct an >> 8-channel receiver using 4 USRPS without data going through the host >> computer? Basically some kind of way to daisy chain mimo cables >> (though > I >> know this is not possible), or at least get the same benefits you >> would >> receive from daisy chaining mimo cables, without using a switch or > network >> connections. >> >> Thank you, >> Anisha >> >> >> ___ >> 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 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] GR Conference Recording?
On Sun, Sep 30, 2012 at 01:14:38PM +0800, sreeraj r wrote: > > Eagerly waiting for the videos. +1 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 pgphqqDkaKVqI.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
