DK
Derek Kozel
Tue, Feb 14, 2017 8:21 PM
Hello Jason,
I believe you will need two multi_usrp objects, one with TwinRXs and the
other with the LFRX. Importantly both must be initialized with the exact
same device arguments string. UHD will create a single control connection
to the USRP in this case, avoiding sharing conflicts.
No USRP can be controlled by two separate processes. The X3x0 is able to
use its two Ethernet ports as a pair to sustain the 2x200 MS/s maximum
receive rate. In your setup this will be 2x100 MS/s from the TwinRXs and
1x200 MS/s from the LFRX. To make this connection the device argument would
be similar to "addr=192.168.30.2,second_addr=192.168.40.2" [1,2]
Bypassing the DDC using this convenience flag will result in both the
TwinRX and LFRX producing full rate streams of complex samples and sending
them to the host. The LFRX's stream will have the I and Q channels
independently representing the A and B antenna ports.
It is possible to use the DDC for the TwinRX and bypass it for the LFRX if
you move to an RFNoC based workflow for the FPGA and host code, but that
does add some complexity.
Regards,
Derek
[1]
http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_setup_network_host_interface
[2] https://kb.ettus.com/X300/X310#10_Gigabit_Ethernet
On Tue, Feb 14, 2017 at 5:17 AM, Jason Roehm jasonr@3db-labs.com wrote:
On 02/13/2017 09:23 PM, Derek Kozel wrote:
Hello Jason,
There are a few things going on in this setup which make things
complicated. I'm testing some of the details, but I wanted to prevent you
from unnecessary debugging.
The TwinRX produces complex samples at 100 MS/s out of the FPGA Radio
block, the BasicRX/LFRX produce them at 200 MS/s. Our architecture
currently has no way to reconcile this difference and create a time aligned
stream. This is the conflicting tick rate (sample rate) exception you are
seeing. So right your configuration will not work as currently desired.
We're aware of the issue and do want to resolve it, but the changes
required are not completely straightforward.
Attached is a GNU Radio Python example of simultaneously using a TwinRX
and BasicRX in an X310 using two rx_streamers. These streams will not be
time aligned by UHD, but there will be time tags on each stream (returned
by each recv call if you are using the UHD API directly) that would allow
your application to align the streams. The example uses the BasicRX in
quadrature sampling mode. This produces an interleaved stream of data from
the A antenna input and the B antenna input. After interleaving the stream
you would have the two real valued ADC streams.
It is possible to bypass the DDC entirely if your system and transport
are able to handle the full 200 MS/s from each daughterboard. Supply
"SKIP_DDC=1" as part of the device arguments.
Please let me know what additional questions you have.
Thanks for the details. I can try to use the multiple-streamer approach,
then time-aligning the samples based upon the timestamps returned alongside
the data. It's not quite as clean as being able to use a single streamer
object, but I can appreciate that it may not be trivial to fix.
I am using UHD directly from C++. Do you mean that I can just call the
multi_usrp::get_rx_stream() function twice to retrieve two separate
streamer objects, one for the TwinRX and another for the BasicRX/LFRX? I
think I was getting the error about conflicting clock rates when applying
the subdevice specification, so maybe that tells me I need two separate
multi_usrp objects (which would align with your GNU Radio example, but I
don't have much experience using it). When creating this, do I therefore
need to ensure that I connect separately to the two IP addresses of the
X300? It was my understanding that USRPs don't support multiple concurrent
connections (except in the case of the X300 since it has multiple network
interfaces).
Bypassing the DDC would be desirable for this application; 200 MSPS won't
be an issue as long as the USRP itself can sustain it over its 10-GbE link.
I can filter and decimate the resulting stream as needed on the host. Along
with specifying skip_ddc=1 when connecting to the device, do I need to
specify anything special with the stream arguments? According to the
documentation for stream_args_t::cpu_format, only complex-valued sample
formats are implemented. If I bypass the DDC and get samples directly from
the ADC, what format should I expect to get when I call recv()?
I appreciate your help.
Jason
Hello Jason,
I believe you will need two multi_usrp objects, one with TwinRXs and the
other with the LFRX. Importantly both must be initialized with the exact
same device arguments string. UHD will create a single control connection
to the USRP in this case, avoiding sharing conflicts.
No USRP can be controlled by two separate processes. The X3x0 is able to
use its two Ethernet ports as a pair to sustain the 2x200 MS/s maximum
receive rate. In your setup this will be 2x100 MS/s from the TwinRXs and
1x200 MS/s from the LFRX. To make this connection the device argument would
be similar to "addr=192.168.30.2,second_addr=192.168.40.2" [1,2]
Bypassing the DDC using this convenience flag will result in both the
TwinRX and LFRX producing full rate streams of complex samples and sending
them to the host. The LFRX's stream will have the I and Q channels
independently representing the A and B antenna ports.
It is possible to use the DDC for the TwinRX and bypass it for the LFRX if
you move to an RFNoC based workflow for the FPGA and host code, but that
does add some complexity.
Regards,
Derek
[1]
http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_setup_network_host_interface
[2] https://kb.ettus.com/X300/X310#10_Gigabit_Ethernet
On Tue, Feb 14, 2017 at 5:17 AM, Jason Roehm <jasonr@3db-labs.com> wrote:
>
> On 02/13/2017 09:23 PM, Derek Kozel wrote:
>
>> Hello Jason,
>>
>> There are a few things going on in this setup which make things
>> complicated. I'm testing some of the details, but I wanted to prevent you
>> from unnecessary debugging.
>>
>> The TwinRX produces complex samples at 100 MS/s out of the FPGA Radio
>> block, the BasicRX/LFRX produce them at 200 MS/s. Our architecture
>> currently has no way to reconcile this difference and create a time aligned
>> stream. This is the conflicting tick rate (sample rate) exception you are
>> seeing. So right your configuration will not work as currently desired.
>> We're aware of the issue and do want to resolve it, but the changes
>> required are not completely straightforward.
>>
>> Attached is a GNU Radio Python example of simultaneously using a TwinRX
>> and BasicRX in an X310 using two rx_streamers. These streams will not be
>> time aligned by UHD, but there will be time tags on each stream (returned
>> by each recv call if you are using the UHD API directly) that would allow
>> your application to align the streams. The example uses the BasicRX in
>> quadrature sampling mode. This produces an interleaved stream of data from
>> the A antenna input and the B antenna input. After interleaving the stream
>> you would have the two real valued ADC streams.
>>
>> It is possible to bypass the DDC entirely if your system and transport
>> are able to handle the full 200 MS/s from each daughterboard. Supply
>> "SKIP_DDC=1" as part of the device arguments.
>>
>> Please let me know what additional questions you have.
>>
>
> Thanks for the details. I can try to use the multiple-streamer approach,
> then time-aligning the samples based upon the timestamps returned alongside
> the data. It's not quite as clean as being able to use a single streamer
> object, but I can appreciate that it may not be trivial to fix.
>
> I am using UHD directly from C++. Do you mean that I can just call the
> multi_usrp::get_rx_stream() function twice to retrieve two separate
> streamer objects, one for the TwinRX and another for the BasicRX/LFRX? I
> think I was getting the error about conflicting clock rates when applying
> the subdevice specification, so maybe that tells me I need two separate
> multi_usrp objects (which would align with your GNU Radio example, but I
> don't have much experience using it). When creating this, do I therefore
> need to ensure that I connect separately to the two IP addresses of the
> X300? It was my understanding that USRPs don't support multiple concurrent
> connections (except in the case of the X300 since it has multiple network
> interfaces).
>
> Bypassing the DDC would be desirable for this application; 200 MSPS won't
> be an issue as long as the USRP itself can sustain it over its 10-GbE link.
> I can filter and decimate the resulting stream as needed on the host. Along
> with specifying skip_ddc=1 when connecting to the device, do I need to
> specify anything special with the stream arguments? According to the
> documentation for stream_args_t::cpu_format, only complex-valued sample
> formats are implemented. If I bypass the DDC and get samples directly from
> the ADC, what format should I expect to get when I call recv()?
>
> I appreciate your help.
>
> Jason
>
JR
Jason Roehm
Tue, Feb 14, 2017 8:43 PM
On 02/14/2017 03:21 PM, Derek Kozel wrote:
Hello Jason,
I believe you will need two multi_usrp objects, one with TwinRXs and
the other with the LFRX. Importantly both must be initialized with the
exact same device arguments string. UHD will create a single control
connection to the USRP in this case, avoiding sharing conflicts.
No USRP can be controlled by two separate processes. The X3x0 is able
to use its two Ethernet ports as a pair to sustain the 2x200 MS/s
maximum receive rate. In your setup this will be 2x100 MS/s from the
TwinRXs and 1x200 MS/s from the LFRX. To make this connection the
device argument would be similar to
"addr=192.168.30.2,second_addr=192.168.40.2" [1,2]
Bypassing the DDC using this convenience flag will result in both the
TwinRX and LFRX producing full rate streams of complex samples and
sending them to the host. The LFRX's stream will have the I and Q
channels independently representing the A and B antenna ports.
It is possible to use the DDC for the TwinRX and bypass it for the
LFRX if you move to an RFNoC based workflow for the FPGA and host
code, but that does add some complexity.
I think I'm approaching convergence in understanding what is possible.
Just a couple more clarification questions. It looks like there are two
configurations in which this can work:
-
2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the
DDC enabled. In this case, I would need to set the center frequency for
the LFRX stream to approximately fs/4, minus some margin to allow for
the rolloff of the DDC's lowpass filter. In this case, I would get 100
MS/sec complex from each TwinRX channel that is enabled (I might only be
interested in 1 at a time, but up to 2), and I would get 200 MS/sec
complex from the LFRX channels (with the input to the DDC taken from the
I and Q channels in quadrature).
-
2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the
DDC bypassed. In this case, what sample rate would I get from the TwinRX
channels that are enabled (i.e. what is "full rate" in your above
description)? Is it complex-valued even if the DDC is bypassed (i.e. is
the ADC taking real-valued samples, or does it use quadrature sampling
even before it hits the DDC?)? What IF frequency would I expect the
TwinRX signal to be centered at in this case (with no DDC to tune it to
baseband)? The LFRX stream would require less massaging in this case, as
it would be a baseband signal with no tuning applied.
I'm just trying to figure out the easiest way to get the behavior I
want, namely 1 to 2 channels of TwinRX (ideally with the DDC enabled, so
I can dial down the sample rate if desired) and 1 real-valued baseband
channel from the LFRX, with appropriate metadata that allows me to align
the streams. I can downsample the LFRX input to match the TwinRX input
if the hardware can't do it for me. It sounds like the available
approaches all require me ingesting a lot of data that I will end up
just discarding. I'd like to avoid that if possible.
Thank you for your responsiveness.
Jason
On 02/14/2017 03:21 PM, Derek Kozel wrote:
> Hello Jason,
>
> I believe you will need two multi_usrp objects, one with TwinRXs and
> the other with the LFRX. Importantly both must be initialized with the
> exact same device arguments string. UHD will create a single control
> connection to the USRP in this case, avoiding sharing conflicts.
>
> No USRP can be controlled by two separate processes. The X3x0 is able
> to use its two Ethernet ports as a pair to sustain the 2x200 MS/s
> maximum receive rate. In your setup this will be 2x100 MS/s from the
> TwinRXs and 1x200 MS/s from the LFRX. To make this connection the
> device argument would be similar to
> "addr=192.168.30.2,second_addr=192.168.40.2" [1,2]
>
> Bypassing the DDC using this convenience flag will result in both the
> TwinRX and LFRX producing full rate streams of complex samples and
> sending them to the host. The LFRX's stream will have the I and Q
> channels independently representing the A and B antenna ports.
>
> It is possible to use the DDC for the TwinRX and bypass it for the
> LFRX if you move to an RFNoC based workflow for the FPGA and host
> code, but that does add some complexity.
I think I'm approaching convergence in understanding what is possible.
Just a couple more clarification questions. It looks like there are two
configurations in which this can work:
1. 2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the
DDC enabled. In this case, I would need to set the center frequency for
the LFRX stream to approximately fs/4, minus some margin to allow for
the rolloff of the DDC's lowpass filter. In this case, I would get 100
MS/sec complex from each TwinRX channel that is enabled (I might only be
interested in 1 at a time, but up to 2), and I would get 200 MS/sec
complex from the LFRX channels (with the input to the DDC taken from the
I and Q channels in quadrature).
2. 2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the
DDC bypassed. In this case, what sample rate would I get from the TwinRX
channels that are enabled (i.e. what is "full rate" in your above
description)? Is it complex-valued even if the DDC is bypassed (i.e. is
the ADC taking real-valued samples, or does it use quadrature sampling
even before it hits the DDC?)? What IF frequency would I expect the
TwinRX signal to be centered at in this case (with no DDC to tune it to
baseband)? The LFRX stream would require less massaging in this case, as
it would be a baseband signal with no tuning applied.
I'm just trying to figure out the easiest way to get the behavior I
want, namely 1 to 2 channels of TwinRX (ideally with the DDC enabled, so
I can dial down the sample rate if desired) and 1 real-valued baseband
channel from the LFRX, with appropriate metadata that allows me to align
the streams. I can downsample the LFRX input to match the TwinRX input
if the hardware can't do it for me. It sounds like the available
approaches all require me ingesting a lot of data that I will end up
just discarding. I'd like to avoid that if possible.
Thank you for your responsiveness.
Jason
JR
Jason Roehm
Fri, Feb 17, 2017 2:49 PM
Thought I would try sending this again in case it was missed. Looking for a couple clarifications on how the X300 would behave under the configurations that Derek suggested.
Thanks.
Jason
On 02/14/2017 03:21 PM, Derek Kozel wrote:
Hello Jason,
I believe you will need two multi_usrp objects, one with TwinRXs and the other with the LFRX. Importantly both must be initialized with the exact same device arguments string. UHD will create a single control connection to the USRP in this case, avoiding sharing conflicts.
No USRP can be controlled by two separate processes. The X3x0 is able to use its two Ethernet ports as a pair to sustain the 2x200 MS/s maximum receive rate. In your setup this will be 2x100 MS/s from the TwinRXs and 1x200 MS/s from the LFRX. To make this connection the device argument would be similar to "addr=192.168.30.2,second_addr=192.168.40.2" [1,2]
Bypassing the DDC using this convenience flag will result in both the TwinRX and LFRX producing full rate streams of complex samples and sending them to the host. The LFRX's stream will have the I and Q channels independently representing the A and B antenna ports.
It is possible to use the DDC for the TwinRX and bypass it for the LFRX if you move to an RFNoC based workflow for the FPGA and host code, but that does add some complexity.
I think I'm approaching convergence in understanding what is possible. Just a couple more clarification questions. It looks like there are two configurations in which this can work:
-
2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the DDC enabled. In this case, I would need to set the center frequency for the LFRX stream to approximately fs/4, minus some margin to allow for the rolloff of the DDC's lowpass filter. In this case, I would get 100 MS/sec complex from each TwinRX channel that is enabled (I might only be interested in 1 at a time, but up to 2), and I would get 200 MS/sec complex from the LFRX channels (with the input to the DDC taken from the I and Q channels in quadrature).
-
2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the DDC bypassed. In this case, what sample rate would I get from the TwinRX channels that are enabled (i.e. what is "full rate" in your above description)? Is it complex-valued even if the DDC is bypassed (i.e. is the ADC taking real-valued samples, or does it use quadrature sampling even before it hits the DDC?)? What IF frequency would I expect the TwinRX signal to be centered at in this case (with no DDC to tune it to baseband)? The LFRX stream would require less massaging in this case, as it would be a baseband signal with no tuning applied.
I'm just trying to figure out the easiest way to get the behavior I want, namely 1 to 2 channels of TwinRX (ideally with the DDC enabled, so I can dial down the sample rate if desired) and 1 real-valued baseband channel from the LFRX, with appropriate metadata that allows me to align the streams. I can downsample the LFRX input to match the TwinRX input if the hardware can't do it for me. It sounds like the available approaches all require me ingesting a lot of data that I will end up just discarding. I'd like to avoid that if possible.
Thank you for your responsiveness.
Jason
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Thought I would try sending this again in case it was missed. Looking for a couple clarifications on how the X300 would behave under the configurations that Derek suggested.
Thanks.
Jason
> On Feb 14, 2017, at 3:43 PM, Jason Roehm via USRP-users <usrp-users@lists.ettus.com> wrote:
>
>
>
>> On 02/14/2017 03:21 PM, Derek Kozel wrote:
>> Hello Jason,
>>
>> I believe you will need two multi_usrp objects, one with TwinRXs and the other with the LFRX. Importantly both must be initialized with the exact same device arguments string. UHD will create a single control connection to the USRP in this case, avoiding sharing conflicts.
>>
>> No USRP can be controlled by two separate processes. The X3x0 is able to use its two Ethernet ports as a pair to sustain the 2x200 MS/s maximum receive rate. In your setup this will be 2x100 MS/s from the TwinRXs and 1x200 MS/s from the LFRX. To make this connection the device argument would be similar to "addr=192.168.30.2,second_addr=192.168.40.2" [1,2]
>>
>> Bypassing the DDC using this convenience flag will result in both the TwinRX and LFRX producing full rate streams of complex samples and sending them to the host. The LFRX's stream will have the I and Q channels independently representing the A and B antenna ports.
>>
>> It is possible to use the DDC for the TwinRX and bypass it for the LFRX if you move to an RFNoC based workflow for the FPGA and host code, but that does add some complexity.
>
> I think I'm approaching convergence in understanding what is possible. Just a couple more clarification questions. It looks like there are two configurations in which this can work:
>
> 1. 2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the DDC enabled. In this case, I would need to set the center frequency for the LFRX stream to approximately fs/4, minus some margin to allow for the rolloff of the DDC's lowpass filter. In this case, I would get 100 MS/sec complex from each TwinRX channel that is enabled (I might only be interested in 1 at a time, but up to 2), and I would get 200 MS/sec complex from the LFRX channels (with the input to the DDC taken from the I and Q channels in quadrature).
>
> 2. 2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the DDC bypassed. In this case, what sample rate would I get from the TwinRX channels that are enabled (i.e. what is "full rate" in your above description)? Is it complex-valued even if the DDC is bypassed (i.e. is the ADC taking real-valued samples, or does it use quadrature sampling even before it hits the DDC?)? What IF frequency would I expect the TwinRX signal to be centered at in this case (with no DDC to tune it to baseband)? The LFRX stream would require less massaging in this case, as it would be a baseband signal with no tuning applied.
>
> I'm just trying to figure out the easiest way to get the behavior I want, namely 1 to 2 channels of TwinRX (ideally with the DDC enabled, so I can dial down the sample rate if desired) and 1 real-valued baseband channel from the LFRX, with appropriate metadata that allows me to align the streams. I can downsample the LFRX input to match the TwinRX input if the hardware can't do it for me. It sounds like the available approaches all require me ingesting a lot of data that I will end up just discarding. I'd like to avoid that if possible.
>
> Thank you for your responsiveness.
>
> Jason
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
DK
Derek Kozel
Sat, Feb 18, 2017 2:06 AM
Hi Jason,
You will not be able to perfectly get the behavior you want directly from
the usual UHD API, but fairly close.
Use two multi_usrp objects initialized with identical arguments, the full
subdev specifications ("A:0 A:1 B:AB" for TwinRX in slot A, LFRX in slot
B), and obtain one rx_streamer from each using the channels argument to
separate the TwinRX channels from the LFRX [6]. You can have as many LFRXs
and and TwinRXs spread across multiple X3x0s with very minimal code changes
with this pattern. Each rx_streamer will internally time align it's streams.
Leave the DDC inline, use it for decimation on either set of streams. The
TwinRX streams will exit the Radio Block as two separate complex streams at
100 MS/s. The Radio Block internally handles the conversion to baseband and
from real to complex (see below for verbose explanation). This means that
it is safe to perform frequency shifts on the TwinRX channels since it is
meaningfully a complex stream. The LFRX streams will exit as a pair of real
valued streams packed into a single complex sample stream at 200 MS/s.
Decimation is safe since the filters will not move energy from I to Q or
vice versa. Frequency translation is not as the CORDIC multiplication will
treat the pair of real valued streams as complex and incorrectly move
energy between them.
To obtain a single real valued stream from the LFRX you must then
de-interleave the IQIQ samples and discard the unused ADC channel. All
three of these streams can be carried over a single 10 GigE (or even 1
GigE) connection if the bandwidth does not exceed the transport capacity.
To carry both the TwinRX streams at full rate will saturate a single 10
GigE link.
The recv calls will populate a metadata_t struct with timestamp and
flowcontrol information [7]. The standard operations of using a PPS edge to
align the Radio Block timestamps is necessary during setup to be able to
align the streams using these timestamps. The X3x0 will generate an
internal PPS if you do not supply an external one.
I hope that provides the clarifications you were looking for. I agree that
this is not a simple as would be ideal.
Regards,
Derek
[1] http://files.ettus.com/manual/page_general.html#general_tuning_process
[2] http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
[3] http://files.ettus.com/schematics/ubx/ubx.pdf
[4]
http://www.analog.com/media/en/technical-documentation/data-sheets/ADL5380.pdf
[5]
http://files.ettus.com/schematics/twinrx/TwinRX%20RF%20Board%20Rev%20D.pdf
[6] https://files.ettus.com/manual/structuhd_1_1stream__args__t.html
[7]
https://files.ettus.com/manual/classuhd_1_1rx__streamer.html#af4e581b97d92553c6091108393a7da1b
/* Start of verbose response
The X300's ADC is always sampling at 200 MS/s. The Radio block in the FPGA
receives time aligned samples from two ADC channels. This ADC pair of
channels is usually used for IQ information. For instance the UBX
daughterboard uses an ADL5380 quadrature demodulator for it's final
downconversion to baseband so the ADCs are doing true quadrature sampling
[3,4]. The TwinRX and BasicRXs are exceptions to this pattern.
The BasicRX directly routes each of it's antenna ports to a single channel
of the ADC, so what is sampled is time aligned real samples from both
ports. The Radio block is capable of interpreting this pair as IQ or QI and
outputs and produces a single stream of samples which are nominally
interpreted as complex sample pairs. However as no DSP operations have been
performed which move energy from I to Q or vise versa the data is still
isolated and can be reinterpreted as two separate real valued streams. If
you skip the DDC these samples will be streamed at 200 MS/s to the host
computer without further intervention.
The TwinRX performs lots of filtering, amplification, and up and/or
downconversion on the two analog RF channels before sending each channel to
a single ADC channel. This produces to real valued streams at 200 MS/s.
This provides a Nyquist bandwidth of 100 MHz. The TwinRX also uses a final
IF frequency of 50 or 150 MHz. Knowing this the Radio block performs a
frequency shift operation followed by a decimate by 2 operation. This
results in a baseband 100 MS/s complex stream with both I and Q carrying
meaningful signal. The analog bandwidth of the IF signal is 80 MHz so it
fits comfortably at this sample rate. Two of these complex streams are
produced, one for each channel. This was a major change from the UHD 3.9.x
FPGA DSP chain to the 3.10.x chain.
The DDC blocks each provide two separate DDC chains (CORDIC -> CIC ->
Halfband -> Halfband -> Halfband) which operate on complex sample streams.
These DDC chains can actually be configured to interpret an incoming real
valued stream as having only I or Q being a meaningful, real-valued signal.
However this functionality is not exposed or used by the standard UHD
distribution. It can be accessed from a program using the RFNoC based work
flow.
The LFRX currently sends it's pseudo complex stream to a single DDC chain.
You can safely decimate this stream by any supported integer amount without
transferring energy between the I and Q signals. Performing a frequency
shift will operate on the complex stream and shift energy between the I and
Q components.
The TwinRX sends each of it's 100 MS/s complex streams to a DDC chain. This
allows for different decimation rates and frequency shifts per
channel/stream. The output is a complex, potentially decimated and
potentially shifted, signal for each channel. If timed commands are used
for tuning then the phases of the CORDIC frequency shifter will be aligned
between channels.
*/
On Fri, Feb 17, 2017 at 6:49 AM, Jason Roehm jasonr@3db-labs.com wrote:
Thought I would try sending this again in case it was missed. Looking for
a couple clarifications on how the X300 would behave under the
configurations that Derek suggested.
Thanks.
Jason
On Feb 14, 2017, at 3:43 PM, Jason Roehm via USRP-users <
On 02/14/2017 03:21 PM, Derek Kozel wrote:
Hello Jason,
I believe you will need two multi_usrp objects, one with TwinRXs and
the other with the LFRX. Importantly both must be initialized with the
exact same device arguments string. UHD will create a single control
connection to the USRP in this case, avoiding sharing conflicts.
No USRP can be controlled by two separate processes. The X3x0 is able
to use its two Ethernet ports as a pair to sustain the 2x200 MS/s maximum
receive rate. In your setup this will be 2x100 MS/s from the TwinRXs and
1x200 MS/s from the LFRX. To make this connection the device argument would
be similar to "addr=192.168.30.2,second_addr=192.168.40.2" [1,2]
Bypassing the DDC using this convenience flag will result in both the
TwinRX and LFRX producing full rate streams of complex samples and sending
them to the host. The LFRX's stream will have the I and Q channels
independently representing the A and B antenna ports.
It is possible to use the DDC for the TwinRX and bypass it for the LFRX
if you move to an RFNoC based workflow for the FPGA and host code, but that
does add some complexity.
I think I'm approaching convergence in understanding what is possible.
Just a couple more clarification questions. It looks like there are two
configurations in which this can work:
- 2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the
DDC enabled. In this case, I would need to set the center frequency for the
LFRX stream to approximately fs/4, minus some margin to allow for the
rolloff of the DDC's lowpass filter. In this case, I would get 100 MS/sec
complex from each TwinRX channel that is enabled (I might only be
interested in 1 at a time, but up to 2), and I would get 200 MS/sec complex
from the LFRX channels (with the input to the DDC taken from the I and Q
channels in quadrature).
- 2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the
DDC bypassed. In this case, what sample rate would I get from the TwinRX
channels that are enabled (i.e. what is "full rate" in your above
description)? Is it complex-valued even if the DDC is bypassed (i.e. is the
ADC taking real-valued samples, or does it use quadrature sampling even
before it hits the DDC?)? What IF frequency would I expect the TwinRX
signal to be centered at in this case (with no DDC to tune it to baseband)?
The LFRX stream would require less massaging in this case, as it would be a
baseband signal with no tuning applied.
I'm just trying to figure out the easiest way to get the behavior I
want, namely 1 to 2 channels of TwinRX (ideally with the DDC enabled, so I
can dial down the sample rate if desired) and 1 real-valued baseband
channel from the LFRX, with appropriate metadata that allows me to align
the streams. I can downsample the LFRX input to match the TwinRX input if
the hardware can't do it for me. It sounds like the available approaches
all require me ingesting a lot of data that I will end up just discarding.
I'd like to avoid that if possible.
Hi Jason,
You will not be able to perfectly get the behavior you want directly from
the usual UHD API, but fairly close.
Use two multi_usrp objects initialized with identical arguments, the full
subdev specifications ("A:0 A:1 B:AB" for TwinRX in slot A, LFRX in slot
B), and obtain one rx_streamer from each using the channels argument to
separate the TwinRX channels from the LFRX [6]. You can have as many LFRXs
and and TwinRXs spread across multiple X3x0s with very minimal code changes
with this pattern. Each rx_streamer will internally time align it's streams.
Leave the DDC inline, use it for decimation on either set of streams. The
TwinRX streams will exit the Radio Block as two separate complex streams at
100 MS/s. The Radio Block internally handles the conversion to baseband and
from real to complex (see below for verbose explanation). This means that
it is safe to perform frequency shifts on the TwinRX channels since it is
meaningfully a complex stream. The LFRX streams will exit as a pair of real
valued streams packed into a *single* complex sample stream at 200 MS/s.
Decimation is safe since the filters will not move energy from I to Q or
vice versa. Frequency translation is not as the CORDIC multiplication will
treat the pair of real valued streams as complex and incorrectly move
energy between them.
To obtain a single real valued stream from the LFRX you must then
de-interleave the IQIQ samples and discard the unused ADC channel. All
three of these streams can be carried over a single 10 GigE (or even 1
GigE) connection if the bandwidth does not exceed the transport capacity.
To carry both the TwinRX streams at full rate will saturate a single 10
GigE link.
The recv calls will populate a metadata_t struct with timestamp and
flowcontrol information [7]. The standard operations of using a PPS edge to
align the Radio Block timestamps is necessary during setup to be able to
align the streams using these timestamps. The X3x0 will generate an
internal PPS if you do not supply an external one.
I hope that provides the clarifications you were looking for. I agree that
this is not a simple as would be ideal.
Regards,
Derek
[1] http://files.ettus.com/manual/page_general.html#general_tuning_process
[2] http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
[3] http://files.ettus.com/schematics/ubx/ubx.pdf
[4]
http://www.analog.com/media/en/technical-documentation/data-sheets/ADL5380.pdf
[5]
http://files.ettus.com/schematics/twinrx/TwinRX%20RF%20Board%20Rev%20D.pdf
[6] https://files.ettus.com/manual/structuhd_1_1stream__args__t.html
[7]
https://files.ettus.com/manual/classuhd_1_1rx__streamer.html#af4e581b97d92553c6091108393a7da1b
/* Start of verbose response
The X300's ADC is always sampling at 200 MS/s. The Radio block in the FPGA
receives time aligned samples from two ADC channels. This ADC pair of
channels is usually used for IQ information. For instance the UBX
daughterboard uses an ADL5380 quadrature demodulator for it's final
downconversion to baseband so the ADCs are doing true quadrature sampling
[3,4]. The TwinRX and BasicRXs are exceptions to this pattern.
The BasicRX directly routes each of it's antenna ports to a single channel
of the ADC, so what is sampled is time aligned real samples from both
ports. The Radio block is capable of interpreting this pair as IQ or QI and
outputs and produces a single stream of samples which are nominally
interpreted as complex sample pairs. However as no DSP operations have been
performed which move energy from I to Q or vise versa the data is still
isolated and can be reinterpreted as two separate real valued streams. If
you skip the DDC these samples will be streamed at 200 MS/s to the host
computer without further intervention.
The TwinRX performs lots of filtering, amplification, and up and/or
downconversion on the two analog RF channels before sending each channel to
a single ADC channel. This produces to real valued streams at 200 MS/s.
This provides a Nyquist bandwidth of 100 MHz. The TwinRX also uses a final
IF frequency of 50 or 150 MHz. Knowing this the Radio block performs a
frequency shift operation followed by a decimate by 2 operation. This
results in a baseband 100 MS/s complex stream with both I and Q carrying
meaningful signal. The analog bandwidth of the IF signal is 80 MHz so it
fits comfortably at this sample rate. Two of these complex streams are
produced, one for each channel. This was a major change from the UHD 3.9.x
FPGA DSP chain to the 3.10.x chain.
The DDC blocks each provide two separate DDC chains (CORDIC -> CIC ->
Halfband -> Halfband -> Halfband) which operate on complex sample streams.
These DDC chains can actually be configured to interpret an incoming real
valued stream as having only I or Q being a meaningful, real-valued signal.
However this functionality is not exposed or used by the standard UHD
distribution. It can be accessed from a program using the RFNoC based work
flow.
The LFRX currently sends it's pseudo complex stream to a single DDC chain.
You can safely decimate this stream by any supported integer amount without
transferring energy between the I and Q signals. Performing a frequency
shift will operate on the complex stream and shift energy between the I and
Q components.
The TwinRX sends each of it's 100 MS/s complex streams to a DDC chain. This
allows for different decimation rates and frequency shifts per
channel/stream. The output is a complex, potentially decimated and
potentially shifted, signal for each channel. If timed commands are used
for tuning then the phases of the CORDIC frequency shifter will be aligned
between channels.
*/
On Fri, Feb 17, 2017 at 6:49 AM, Jason Roehm <jasonr@3db-labs.com> wrote:
> Thought I would try sending this again in case it was missed. Looking for
> a couple clarifications on how the X300 would behave under the
> configurations that Derek suggested.
>
> Thanks.
>
> Jason
>
> > On Feb 14, 2017, at 3:43 PM, Jason Roehm via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> >
> >
> >
> >> On 02/14/2017 03:21 PM, Derek Kozel wrote:
> >> Hello Jason,
> >>
> >> I believe you will need two multi_usrp objects, one with TwinRXs and
> the other with the LFRX. Importantly both must be initialized with the
> exact same device arguments string. UHD will create a single control
> connection to the USRP in this case, avoiding sharing conflicts.
> >>
> >> No USRP can be controlled by two separate processes. The X3x0 is able
> to use its two Ethernet ports as a pair to sustain the 2x200 MS/s maximum
> receive rate. In your setup this will be 2x100 MS/s from the TwinRXs and
> 1x200 MS/s from the LFRX. To make this connection the device argument would
> be similar to "addr=192.168.30.2,second_addr=192.168.40.2" [1,2]
> >>
> >> Bypassing the DDC using this convenience flag will result in both the
> TwinRX and LFRX producing full rate streams of complex samples and sending
> them to the host. The LFRX's stream will have the I and Q channels
> independently representing the A and B antenna ports.
> >>
> >> It is possible to use the DDC for the TwinRX and bypass it for the LFRX
> if you move to an RFNoC based workflow for the FPGA and host code, but that
> does add some complexity.
> >
> > I think I'm approaching convergence in understanding what is possible.
> Just a couple more clarification questions. It looks like there are two
> configurations in which this can work:
> >
> > 1. 2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the
> DDC enabled. In this case, I would need to set the center frequency for the
> LFRX stream to approximately fs/4, minus some margin to allow for the
> rolloff of the DDC's lowpass filter. In this case, I would get 100 MS/sec
> complex from each TwinRX channel that is enabled (I might only be
> interested in 1 at a time, but up to 2), and I would get 200 MS/sec complex
> from the LFRX channels (with the input to the DDC taken from the I and Q
> channels in quadrature).
> >
> > 2. 2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the
> DDC bypassed. In this case, what sample rate would I get from the TwinRX
> channels that are enabled (i.e. what is "full rate" in your above
> description)? Is it complex-valued even if the DDC is bypassed (i.e. is the
> ADC taking real-valued samples, or does it use quadrature sampling even
> before it hits the DDC?)? What IF frequency would I expect the TwinRX
> signal to be centered at in this case (with no DDC to tune it to baseband)?
> The LFRX stream would require less massaging in this case, as it would be a
> baseband signal with no tuning applied.
> >
> > I'm just trying to figure out the easiest way to get the behavior I
> want, namely 1 to 2 channels of TwinRX (ideally with the DDC enabled, so I
> can dial down the sample rate if desired) and 1 real-valued baseband
> channel from the LFRX, with appropriate metadata that allows me to align
> the streams. I can downsample the LFRX input to match the TwinRX input if
> the hardware can't do it for me. It sounds like the available approaches
> all require me ingesting a lot of data that I will end up just discarding.
> I'd like to avoid that if possible.
> >
> > Thank you for your responsiveness.
> >
> > Jason
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users@lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
JR
Jason Roehm
Sat, Feb 18, 2017 5:13 AM
Thanks for the very detailed response!
That sounds like it would be pretty much what I want. Discarding the unused Q channel from the LFRX isn't a big deal, especially if I can still utilize the DDC to lower the sample rate from the 200 MS/sec initial rate.
You say that I can safely route the LFRX data through the DDC, as long as I don't enable any frequency shifting. To ensure that there isn't any frequency shift done by the DDC, would I just set the LFRX channel to a center frequency of zero, then, or is there something else I should do?
Thank you very much for the help.
Jason
On Feb 17, 2017, at 9:06 PM, Derek Kozel derek.kozel@ettus.com wrote:
Hi Jason,
You will not be able to perfectly get the behavior you want directly from the usual UHD API, but fairly close.
Use two multi_usrp objects initialized with identical arguments, the full subdev specifications ("A:0 A:1 B:AB" for TwinRX in slot A, LFRX in slot B), and obtain one rx_streamer from each using the channels argument to separate the TwinRX channels from the LFRX [6]. You can have as many LFRXs and and TwinRXs spread across multiple X3x0s with very minimal code changes with this pattern. Each rx_streamer will internally time align it's streams.
Leave the DDC inline, use it for decimation on either set of streams. The TwinRX streams will exit the Radio Block as two separate complex streams at 100 MS/s. The Radio Block internally handles the conversion to baseband and from real to complex (see below for verbose explanation). This means that it is safe to perform frequency shifts on the TwinRX channels since it is meaningfully a complex stream. The LFRX streams will exit as a pair of real valued streams packed into a single complex sample stream at 200 MS/s. Decimation is safe since the filters will not move energy from I to Q or vice versa. Frequency translation is not as the CORDIC multiplication will treat the pair of real valued streams as complex and incorrectly move energy between them.
To obtain a single real valued stream from the LFRX you must then de-interleave the IQIQ samples and discard the unused ADC channel. All three of these streams can be carried over a single 10 GigE (or even 1 GigE) connection if the bandwidth does not exceed the transport capacity. To carry both the TwinRX streams at full rate will saturate a single 10 GigE link.
The recv calls will populate a metadata_t struct with timestamp and flowcontrol information [7]. The standard operations of using a PPS edge to align the Radio Block timestamps is necessary during setup to be able to align the streams using these timestamps. The X3x0 will generate an internal PPS if you do not supply an external one.
I hope that provides the clarifications you were looking for. I agree that this is not a simple as would be ideal.
Regards,
Derek
[1] http://files.ettus.com/manual/page_general.html#general_tuning_process
[2] http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
[3] http://files.ettus.com/schematics/ubx/ubx.pdf
[4] http://www.analog.com/media/en/technical-documentation/data-sheets/ADL5380.pdf
[5] http://files.ettus.com/schematics/twinrx/TwinRX%20RF%20Board%20Rev%20D.pdf
[6] https://files.ettus.com/manual/structuhd_1_1stream__args__t.html
[7] https://files.ettus.com/manual/classuhd_1_1rx__streamer.html#af4e581b97d92553c6091108393a7da1b
/* Start of verbose response
The X300's ADC is always sampling at 200 MS/s. The Radio block in the FPGA receives time aligned samples from two ADC channels. This ADC pair of channels is usually used for IQ information. For instance the UBX daughterboard uses an ADL5380 quadrature demodulator for it's final downconversion to baseband so the ADCs are doing true quadrature sampling [3,4]. The TwinRX and BasicRXs are exceptions to this pattern.
The BasicRX directly routes each of it's antenna ports to a single channel of the ADC, so what is sampled is time aligned real samples from both ports. The Radio block is capable of interpreting this pair as IQ or QI and outputs and produces a single stream of samples which are nominally interpreted as complex sample pairs. However as no DSP operations have been performed which move energy from I to Q or vise versa the data is still isolated and can be reinterpreted as two separate real valued streams. If you skip the DDC these samples will be streamed at 200 MS/s to the host computer without further intervention.
The TwinRX performs lots of filtering, amplification, and up and/or downconversion on the two analog RF channels before sending each channel to a single ADC channel. This produces to real valued streams at 200 MS/s. This provides a Nyquist bandwidth of 100 MHz. The TwinRX also uses a final IF frequency of 50 or 150 MHz. Knowing this the Radio block performs a frequency shift operation followed by a decimate by 2 operation. This results in a baseband 100 MS/s complex stream with both I and Q carrying meaningful signal. The analog bandwidth of the IF signal is 80 MHz so it fits comfortably at this sample rate. Two of these complex streams are produced, one for each channel. This was a major change from the UHD 3.9.x FPGA DSP chain to the 3.10.x chain.
The DDC blocks each provide two separate DDC chains (CORDIC -> CIC -> Halfband -> Halfband -> Halfband) which operate on complex sample streams. These DDC chains can actually be configured to interpret an incoming real valued stream as having only I or Q being a meaningful, real-valued signal. However this functionality is not exposed or used by the standard UHD distribution. It can be accessed from a program using the RFNoC based work flow.
The LFRX currently sends it's pseudo complex stream to a single DDC chain. You can safely decimate this stream by any supported integer amount without transferring energy between the I and Q signals. Performing a frequency shift will operate on the complex stream and shift energy between the I and Q components.
The TwinRX sends each of it's 100 MS/s complex streams to a DDC chain. This allows for different decimation rates and frequency shifts per channel/stream. The output is a complex, potentially decimated and potentially shifted, signal for each channel. If timed commands are used for tuning then the phases of the CORDIC frequency shifter will be aligned between channels.
*/
On Fri, Feb 17, 2017 at 6:49 AM, Jason Roehm jasonr@3db-labs.com wrote:
Thought I would try sending this again in case it was missed. Looking for a couple clarifications on how the X300 would behave under the configurations that Derek suggested.
Thanks.
Jason
On 02/14/2017 03:21 PM, Derek Kozel wrote:
Hello Jason,
I believe you will need two multi_usrp objects, one with TwinRXs and the other with the LFRX. Importantly both must be initialized with the exact same device arguments string. UHD will create a single control connection to the USRP in this case, avoiding sharing conflicts.
No USRP can be controlled by two separate processes. The X3x0 is able to use its two Ethernet ports as a pair to sustain the 2x200 MS/s maximum receive rate. In your setup this will be 2x100 MS/s from the TwinRXs and 1x200 MS/s from the LFRX. To make this connection the device argument would be similar to "addr=192.168.30.2,second_addr=192.168.40.2" [1,2]
Bypassing the DDC using this convenience flag will result in both the TwinRX and LFRX producing full rate streams of complex samples and sending them to the host. The LFRX's stream will have the I and Q channels independently representing the A and B antenna ports.
It is possible to use the DDC for the TwinRX and bypass it for the LFRX if you move to an RFNoC based workflow for the FPGA and host code, but that does add some complexity.
I think I'm approaching convergence in understanding what is possible. Just a couple more clarification questions. It looks like there are two configurations in which this can work:
-
2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the DDC enabled. In this case, I would need to set the center frequency for the LFRX stream to approximately fs/4, minus some margin to allow for the rolloff of the DDC's lowpass filter. In this case, I would get 100 MS/sec complex from each TwinRX channel that is enabled (I might only be interested in 1 at a time, but up to 2), and I would get 200 MS/sec complex from the LFRX channels (with the input to the DDC taken from the I and Q channels in quadrature).
-
2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the DDC bypassed. In this case, what sample rate would I get from the TwinRX channels that are enabled (i.e. what is "full rate" in your above description)? Is it complex-valued even if the DDC is bypassed (i.e. is the ADC taking real-valued samples, or does it use quadrature sampling even before it hits the DDC?)? What IF frequency would I expect the TwinRX signal to be centered at in this case (with no DDC to tune it to baseband)? The LFRX stream would require less massaging in this case, as it would be a baseband signal with no tuning applied.
I'm just trying to figure out the easiest way to get the behavior I want, namely 1 to 2 channels of TwinRX (ideally with the DDC enabled, so I can dial down the sample rate if desired) and 1 real-valued baseband channel from the LFRX, with appropriate metadata that allows me to align the streams. I can downsample the LFRX input to match the TwinRX input if the hardware can't do it for me. It sounds like the available approaches all require me ingesting a lot of data that I will end up just discarding. I'd like to avoid that if possible.
Thank you for your responsiveness.
Jason
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Thanks for the very detailed response!
That sounds like it would be pretty much what I want. Discarding the unused Q channel from the LFRX isn't a big deal, especially if I can still utilize the DDC to lower the sample rate from the 200 MS/sec initial rate.
You say that I can safely route the LFRX data through the DDC, as long as I don't enable any frequency shifting. To ensure that there isn't any frequency shift done by the DDC, would I just set the LFRX channel to a center frequency of zero, then, or is there something else I should do?
Thank you very much for the help.
Jason
> On Feb 17, 2017, at 9:06 PM, Derek Kozel <derek.kozel@ettus.com> wrote:
>
> Hi Jason,
>
> You will not be able to perfectly get the behavior you want directly from the usual UHD API, but fairly close.
>
> Use two multi_usrp objects initialized with identical arguments, the full subdev specifications ("A:0 A:1 B:AB" for TwinRX in slot A, LFRX in slot B), and obtain one rx_streamer from each using the channels argument to separate the TwinRX channels from the LFRX [6]. You can have as many LFRXs and and TwinRXs spread across multiple X3x0s with very minimal code changes with this pattern. Each rx_streamer will internally time align it's streams.
>
> Leave the DDC inline, use it for decimation on either set of streams. The TwinRX streams will exit the Radio Block as two separate complex streams at 100 MS/s. The Radio Block internally handles the conversion to baseband and from real to complex (see below for verbose explanation). This means that it is safe to perform frequency shifts on the TwinRX channels since it is meaningfully a complex stream. The LFRX streams will exit as a pair of real valued streams packed into a *single* complex sample stream at 200 MS/s. Decimation is safe since the filters will not move energy from I to Q or vice versa. Frequency translation is not as the CORDIC multiplication will treat the pair of real valued streams as complex and incorrectly move energy between them.
>
> To obtain a single real valued stream from the LFRX you must then de-interleave the IQIQ samples and discard the unused ADC channel. All three of these streams can be carried over a single 10 GigE (or even 1 GigE) connection if the bandwidth does not exceed the transport capacity. To carry both the TwinRX streams at full rate will saturate a single 10 GigE link.
>
> The recv calls will populate a metadata_t struct with timestamp and flowcontrol information [7]. The standard operations of using a PPS edge to align the Radio Block timestamps is necessary during setup to be able to align the streams using these timestamps. The X3x0 will generate an internal PPS if you do not supply an external one.
>
> I hope that provides the clarifications you were looking for. I agree that this is not a simple as would be ideal.
>
> Regards,
> Derek
>
> [1] http://files.ettus.com/manual/page_general.html#general_tuning_process
> [2] http://files.ettus.com/manual/structuhd_1_1tune__request__t.html
> [3] http://files.ettus.com/schematics/ubx/ubx.pdf
> [4] http://www.analog.com/media/en/technical-documentation/data-sheets/ADL5380.pdf
> [5] http://files.ettus.com/schematics/twinrx/TwinRX%20RF%20Board%20Rev%20D.pdf
> [6] https://files.ettus.com/manual/structuhd_1_1stream__args__t.html
> [7] https://files.ettus.com/manual/classuhd_1_1rx__streamer.html#af4e581b97d92553c6091108393a7da1b
>
> /* Start of verbose response
>
> The X300's ADC is always sampling at 200 MS/s. The Radio block in the FPGA receives time aligned samples from two ADC channels. This ADC pair of channels is usually used for IQ information. For instance the UBX daughterboard uses an ADL5380 quadrature demodulator for it's final downconversion to baseband so the ADCs are doing true quadrature sampling [3,4]. The TwinRX and BasicRXs are exceptions to this pattern.
>
> The BasicRX directly routes each of it's antenna ports to a single channel of the ADC, so what is sampled is time aligned real samples from both ports. The Radio block is capable of interpreting this pair as IQ or QI and outputs and produces a single stream of samples which are nominally interpreted as complex sample pairs. However as no DSP operations have been performed which move energy from I to Q or vise versa the data is still isolated and can be reinterpreted as two separate real valued streams. If you skip the DDC these samples will be streamed at 200 MS/s to the host computer without further intervention.
>
> The TwinRX performs lots of filtering, amplification, and up and/or downconversion on the two analog RF channels before sending each channel to a single ADC channel. This produces to real valued streams at 200 MS/s. This provides a Nyquist bandwidth of 100 MHz. The TwinRX also uses a final IF frequency of 50 or 150 MHz. Knowing this the Radio block performs a frequency shift operation followed by a decimate by 2 operation. This results in a baseband 100 MS/s complex stream with both I and Q carrying meaningful signal. The analog bandwidth of the IF signal is 80 MHz so it fits comfortably at this sample rate. Two of these complex streams are produced, one for each channel. This was a major change from the UHD 3.9.x FPGA DSP chain to the 3.10.x chain.
>
> The DDC blocks each provide two separate DDC chains (CORDIC -> CIC -> Halfband -> Halfband -> Halfband) which operate on complex sample streams. These DDC chains can actually be configured to interpret an incoming real valued stream as having only I or Q being a meaningful, real-valued signal. However this functionality is not exposed or used by the standard UHD distribution. It can be accessed from a program using the RFNoC based work flow.
>
> The LFRX currently sends it's pseudo complex stream to a single DDC chain. You can safely decimate this stream by any supported integer amount without transferring energy between the I and Q signals. Performing a frequency shift will operate on the complex stream and shift energy between the I and Q components.
>
> The TwinRX sends each of it's 100 MS/s complex streams to a DDC chain. This allows for different decimation rates and frequency shifts per channel/stream. The output is a complex, potentially decimated and potentially shifted, signal for each channel. If timed commands are used for tuning then the phases of the CORDIC frequency shifter will be aligned between channels.
>
> */
>
>> On Fri, Feb 17, 2017 at 6:49 AM, Jason Roehm <jasonr@3db-labs.com> wrote:
>> Thought I would try sending this again in case it was missed. Looking for a couple clarifications on how the X300 would behave under the configurations that Derek suggested.
>>
>> Thanks.
>>
>> Jason
>>
>> > On Feb 14, 2017, at 3:43 PM, Jason Roehm via USRP-users <usrp-users@lists.ettus.com> wrote:
>> >
>> >
>> >
>> >> On 02/14/2017 03:21 PM, Derek Kozel wrote:
>> >> Hello Jason,
>> >>
>> >> I believe you will need two multi_usrp objects, one with TwinRXs and the other with the LFRX. Importantly both must be initialized with the exact same device arguments string. UHD will create a single control connection to the USRP in this case, avoiding sharing conflicts.
>> >>
>> >> No USRP can be controlled by two separate processes. The X3x0 is able to use its two Ethernet ports as a pair to sustain the 2x200 MS/s maximum receive rate. In your setup this will be 2x100 MS/s from the TwinRXs and 1x200 MS/s from the LFRX. To make this connection the device argument would be similar to "addr=192.168.30.2,second_addr=192.168.40.2" [1,2]
>> >>
>> >> Bypassing the DDC using this convenience flag will result in both the TwinRX and LFRX producing full rate streams of complex samples and sending them to the host. The LFRX's stream will have the I and Q channels independently representing the A and B antenna ports.
>> >>
>> >> It is possible to use the DDC for the TwinRX and bypass it for the LFRX if you move to an RFNoC based workflow for the FPGA and host code, but that does add some complexity.
>> >
>> > I think I'm approaching convergence in understanding what is possible. Just a couple more clarification questions. It looks like there are two configurations in which this can work:
>> >
>> > 1. 2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the DDC enabled. In this case, I would need to set the center frequency for the LFRX stream to approximately fs/4, minus some margin to allow for the rolloff of the DDC's lowpass filter. In this case, I would get 100 MS/sec complex from each TwinRX channel that is enabled (I might only be interested in 1 at a time, but up to 2), and I would get 200 MS/sec complex from the LFRX channels (with the input to the DDC taken from the I and Q channels in quadrature).
>> >
>> > 2. 2 multi_usrp objects, streaming over 2 10-GbE interfaces, with the DDC bypassed. In this case, what sample rate would I get from the TwinRX channels that are enabled (i.e. what is "full rate" in your above description)? Is it complex-valued even if the DDC is bypassed (i.e. is the ADC taking real-valued samples, or does it use quadrature sampling even before it hits the DDC?)? What IF frequency would I expect the TwinRX signal to be centered at in this case (with no DDC to tune it to baseband)? The LFRX stream would require less massaging in this case, as it would be a baseband signal with no tuning applied.
>> >
>> > I'm just trying to figure out the easiest way to get the behavior I want, namely 1 to 2 channels of TwinRX (ideally with the DDC enabled, so I can dial down the sample rate if desired) and 1 real-valued baseband channel from the LFRX, with appropriate metadata that allows me to align the streams. I can downsample the LFRX input to match the TwinRX input if the hardware can't do it for me. It sounds like the available approaches all require me ingesting a lot of data that I will end up just discarding. I'd like to avoid that if possible.
>> >
>> > Thank you for your responsiveness.
>> >
>> > Jason
>> >
>> > _______________________________________________
>> > USRP-users mailing list
>> > USRP-users@lists.ettus.com
>> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>