Can another DUC chain be added to USRP N210?

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

On 09/28/2012 08:49 AM, Anisha G. wrote:

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

On 09/29/2012 09:45 AM, Anisha G. 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

Thank you very much for your help Josh! I’ll let you know if we end up
going this way in our design.

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?
Thanks for your time!
-Anisha

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs