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.
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.
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.
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?
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.
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
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.
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.