How to configure SBX with two channels, one for communications, one for sensing?

Hi,

What I want to do is try to use the two antennas of SBX simultaneously.

The TX/RX is used for duplex communications and the RX2 is for sensing.
The
two antennas are working different frequencies.
But this solution seems to be unfeasible, as someone said the receiver
chain of SBX is the same. The TX/RX and RX2 can not work simultaneously.
As suggested in the community, I am trying to using 3 frequecies on one
antenna (TX/RX): f1, f2, f3.

f1(tx) and f2(rx) are used for FDD duplex communications,and f3 is for
sensing path. And f2 and f3 are within the 40MHz difference.

My problem is how to set it in USRP source block for this kind of
configuration? Does anybody has such example? And I met the error like
below:

Runtime error:vector::_M_range_check

which seems to be caused by incorrect setting of subdev. However, I
don’t
know what the valid value fo subdev in such kind configuration.

Alex,
Dreams can come true just believe.

On 05/21/2012 03:09 PM, Alex Z. wrote:

know what the valid value fo subdev in such kind configuration.

Correct, you can only receive from one antenna at a time. If your RX
frequencies of interest are reasonably near in frequency, lets say 40
MHz, you can use multiple DSPs in the FPGA as a kind of 2 channel
filterbank.

You can set the subdev/frontend spec to “A:0 A:0”, this will map the
frontend A:0 to both DSP0 and DSP1. If you setup the USRP source for 2
channels, DSP0 will be output 0 and DSP1 will be output 1.

Be careful with the tune_request so that you are setting the rf
frequency to the same setting, but with different target frequencies to
get the DSPs to shift appropriately. There should be some mention of
tune request in the docs inside the USRP source block properties dialog
in GRC.

-josh

Thanks!

I am trying to set up two channels on RX2 as Nick said. And the subdev
is
set as “A:0 A:0”. Please see the attachement for the GRC flow graph.

But my problem is that it seems that both the channels can not receive
the
expected signal(I am using an OFDM transmitter for test).
The single channel with frequency of 908M or 928M works well as I can
see
the OFDM spectrum from the observing FFT plot window.

On Mon, May 21, 2012 at 5:37 PM, Josh B. [email protected] wrote:

But this solution seems to be unfeasible, as someone said the receiver

filterbank.

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Alex,
Dreams can come true just believe.

A little confused.

I am using the gnuradio-companion to configure the uhd.usrp_resource.
What is the difference between the rf_freq and the center_freq? How the
tune_request (is it a UHD method?) can be reflected in the
gnuradio-companion setting?

On Mon, May 21, 2012 at 6:29 PM, Josh B. [email protected] wrote:

expected signal(I am using an OFDM transmitter for test).
uhd.tune_request(928e6, rf_freq=918e6,

simultaneously.

Runtime error:vector::_M_range_check
filterbank.

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Alex,
Dreams can come true just believe.

On 05/21/2012 06:57 PM, Alex Z. wrote:

A little confused.

I am using the gnuradio-companion to configure the uhd.usrp_resource.
What is the difference between the rf_freq and the center_freq? How the

Basically, you have two down conversion chains that share a common RF
frontend, but independent DSP chains in the FPGA.

See:
http://files.ettus.com/uhd_docs/manual/html/general.html#tuning-notes

Also see:
http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html

tune_request (is it a UHD method?) can be reflected in the
gnuradio-companion setting?

Just copy and paste the code I sent you into the center frequency
parameter.

-josh

On 05/21/2012 04:12 PM, Alex Z. wrote:

What did you enter for ch0 and ch1 center frequency? I recommend this:

uhd.tune_request(908e6, rf_freq=918e6,
rf_freq_policy=uhd.tune_request.POLICY_MANUAL)

uhd.tune_request(928e6, rf_freq=918e6,
rf_freq_policy=uhd.tune_request.POLICY_MANUAL)

Its important the RF frequency be the same for each channel, otherwise,
the second tune for channel1 will override the tuning for channel0.

-josh

But my code is still different with one of your post here
[Discuss-gnuradio] tune_request feature for UHD's USRP blocks in GRC.
I think the dsp_freq is used for other purpose, right?

Correct, the goal in that email was to bypass any frequency shifting
done by the DSP in the FPGA.

-josh

It seems working now. Two channels can receive the signal sent on the
their
own target frequencies.

Below is my code.

self.uhd_usrp_source_0 = uhd.usrp_source(
device_addr=“”,
stream_args=uhd.stream_args(
cpu_format=“fc32”,
channels=range(2),
),
)
#self.uhd_usrp_source_0.set_clock_rate(918000000,
uhd.ALL_MBOARDS)

  •    tr1 = uhd.tune_request(908e6, rf_freq=918e6,
    

rf_freq_policy=uhd.tune_request.POLICY_MANUAL);
tr2 = uhd.tune_request(928e6, rf_freq=918e6,
rf_freq_policy=uhd.tune_request.POLICY_MANUAL);*
self.uhd_usrp_source_0.set_subdev_spec(“A:0 A:0”, 0)
self.uhd_usrp_source_0.set_samp_rate(1024000)
#self.uhd_usrp_source_0.set_center_freq(908000000, 0)
self.uhd_usrp_source_0.set_center_freq(tr1, 0)
self.uhd_usrp_source_0.set_gain(0, 0)
self.uhd_usrp_source_0.set_antenna(“RX2”, 0)
#self.uhd_usrp_source_0.set_center_freq(928000000, 1)
self.uhd_usrp_source_0.set_center_freq(tr2, 1)
self.uhd_usrp_source_0.set_gain(0, 1)
self.uhd_usrp_source_0.set_antenna(“RX2”, 1)

But my code is still different with one of your post here
[Discuss-gnuradio] tune_request feature for UHD's USRP blocks in GRC.
I think the dsp_freq is used for other purpose, right?

On Mon, May 21, 2012 at 9:27 PM, Josh B. [email protected] wrote:

Just copy and paste the code I sent you into the center frequency

Its important the RF frequency be the same for each channel, otherwise,

simultaneously.
like

Correct, you can only receive from one antenna at a time. If your RX
to

Discuss-gnuradio mailing list

Alex,
Dreams can come true just believe.

The other question is that for it seems that we cannot set different
sample
rate for the two channels, right?
For example, I want the channel 0 to work for communications, with
higher
sample rate. But for channel 1 for sensing with lower sample rate.
To save the computing resource, I don’t want that channel 1 to have
redundant samples sent from USRP to host computer, even I re-sample the
channel 1 data.

On Tue, May 22, 2012 at 11:26 AM, Josh B. [email protected] wrote:

Alex,
Dreams can come true just believe.

On 05/22/2012 09:57 AM, Alex Z. wrote:

The other question is that for it seems that we cannot set different sample
rate for the two channels, right?

So thats not currently possible with the current USRP source/sink
blocks. This would be an interesting development:

Basically, each streamer (with its own rate, and data type, possibly
other settings) would get its own block and work function. The top level
USRP source/sink block would then actually be a hierarchical block with
these blocks inside.

See, its important that each streamer has its own dedicated output ports
and thread/aka work function. Thats the only way to deal with multiple
sources w/ heterogeneous rates.

At least thats how I would fit such a thing into the gnuradio framework
:slight_smile:

-josh

Current in my test, the leak is observed.
For example, if I set two channels are receivers (RX2);
channel 0: target freq = 908M, channel 1: target freq = 928M.
And I transmitting an OFDM signal with center frequency as 908M which is
supposed to be received by channel 0.
However, I see that the channel 1 can also receive the same signal,
although with much lower amplitude.
The result is that channel 0 has -56db received signal, while channel 1
has
-91db, as shown in the attached picture.

On Mon, May 21, 2012 at 9:27 PM, Josh B. [email protected] wrote:

Just copy and paste the code I sent you into the center frequency

Its important the RF frequency be the same for each channel, otherwise,

simultaneously.
like

Correct, you can only receive from one antenna at a time. If your RX
to

Discuss-gnuradio mailing list

Alex,
Dreams can come true just believe.

I am thinking that the sample rates are determined in FPGA, specified by
gnuradio with python or C++…So I may only make sense that the hardware
can support two different sample rates for two channels, to reduce the
redundant data transfer between the USRP and the host computer.
Otherwise,
if the traffic is not decreased, it is meaningless to support the
different
rates only by the software, because it does not reduce the processing
and
communications burden on the host computer.

I am not sure if my understanding is on the right way.

On Tue, May 22, 2012 at 1:17 PM, Josh B. [email protected] wrote:

Basically, each streamer (with its own rate, and data type, possibly
-josh

Alex,
Dreams can come true just believe.