usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsX300 with TwinRX and LFRX
I have an application where I would like to use a TwinRX and LFRX simultaneously in a single X300 chassis. In this application, I would want to synchronously sample the TwinRX channels along with a single DC-coupled baseband input from the LFRX (i.e. I would want to stream time-aligned samples from these three inputs). Is this a supported configuration? I think I’ve seen some mailing list traffic before that indicated problems with mixing different types of daughterboards in a single enclosure like this.
Also, there seems to be some disagreement on the bandwidth of the LFRX input. Most places on the Ettus site currently specify a bandwidth from DC to 30 MHz. However, I remember in the past that it used to be quoted as up to 50 MHz. Likewise, the silkscreen on the PCB in the photos on ettus.com http://ettus.com/ show “0-50 MHz” as well. Was there a design change at some point? Is there any measured data on the board’s frequency response?
Thanks for your help.
Jason
On 02/09/2017 08:38 PM, Jason Roehm via USRP-users wrote:
I have an application where I would like to use a TwinRX and LFRX
simultaneously in a single X300 chassis. In this application, I would
want to synchronously sample the TwinRX channels along with a single
DC-coupled baseband input from the LFRX (i.e. I would want to stream
time-aligned samples from these three inputs). Is this a supported
configuration? I think I’ve seen some mailing list traffic before that
indicated problems with mixing different types of daughterboards in a
single enclosure like this.
I've lost track of which UHD versions in recent history have sufficient
DDC resources to handle both the dual channels of the TwinRX AND
another channel from another single-channel card. Perhaps Jonathan
Pendlum can comment?
Also, there seems to be some disagreement on the bandwidth of the LFRX
input. Most places on the Ettus site currently specify a bandwidth
from DC to 30 MHz. However, I remember in the past that it used to be
quoted as up to 50 MHz. Likewise, the silkscreen on the PCB in the
photos on ettus.com http://ettus.com show “0-50 MHz” as well. Was
there a design change at some point? Is there any measured data on the
board’s frequency response?
The frequency response starts to fall off above 30MHz, but it's rather
"lazy". I wouldn't expect you to have much trouble getting 50Mhz
signals sampled by the LFRX card.
Thanks for your help.
Jason
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
On 02/09/2017 10:09 PM, Marcus D. Leech via USRP-users wrote:
On 02/09/2017 08:38 PM, Jason Roehm via USRP-users wrote:
I have an application where I would like to use a TwinRX and LFRX
simultaneously in a single X300 chassis. In this application, I would
want to synchronously sample the TwinRX channels along with a single
DC-coupled baseband input from the LFRX (i.e. I would want to stream
time-aligned samples from these three inputs). Is this a supported
configuration? I think I’ve seen some mailing list traffic before
that indicated problems with mixing different types of daughterboards
in a single enclosure like this.
I've lost track of which UHD versions in recent history have
sufficient DDC resources to handle both the dual channels of the
TwinRX AND another channel from another single-channel card. Perhaps
Jonathan Pendlum can comment?
Doesn't the most recent UHD version allow you to use an X300 with dual
TwinRXs in it, hence requiring 4 DDCs? It seems like this configuration
would require the same amount of FPGA resources as what I proposed, and
since it's one of the advertised use cases for the TwinRX, I'm assuming
it is supported. I might be missing something though.
Jason
Yes, it's just that it's a use-case that I'm not sure anyone has tested.
On 2017-02-10 11:03, Jason Roehm via USRP-users wrote:
On 02/09/2017 10:09 PM, Marcus D. Leech via USRP-users wrote: On 02/09/2017 08:38 PM, Jason Roehm via USRP-users wrote: I have an application where I would like to use a TwinRX and LFRX simultaneously in a single X300 chassis. In this application, I would want to synchronously sample the TwinRX channels along with a single DC-coupled baseband input from the LFRX (i.e. I would want to stream time-aligned samples from these three inputs). Is this a supported configuration? I think I've seen some mailing list traffic before that indicated problems with mixing different types of daughterboards in a single enclosure like this. I've lost track of which UHD versions in recent history have sufficient DDC resources to handle both the dual channels of the TwinRX AND another channel from another single-channel card. Perhaps Jonathan Pendlum can comment?
Doesn't the most recent UHD version allow you to use an X300 with dual
TwinRXs in it, hence requiring 4 DDCs? It seems like this configuration
would require the same amount of FPGA resources as what I proposed, and
since it's one of the advertised use cases for the TwinRX, I'm assuming
it is supported. I might be missing something though.
Jason
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
On Feb 9, 2017, at 10:09 PM, Marcus D. Leech via USRP-users usrp-users@lists.ettus.com wrote:
On 02/09/2017 08:38 PM, Jason Roehm via USRP-users wrote:
I have an application where I would like to use a TwinRX and LFRX simultaneously in a single X300 chassis. In this application, I would want to synchronously sample the TwinRX channels along with a single DC-coupled baseband input from the LFRX (i.e. I would want to stream time-aligned samples from these three inputs). Is this a supported configuration? I think I’ve seen some mailing list traffic before that indicated problems with mixing different types of daughterboards in a single enclosure like this.
I've lost track of which UHD versions in recent history have sufficient DDC resources to handle both the dual channels of the TwinRX AND another channel from another single-channel card. Perhaps Jonathan Pendlum can comment?
I tried the proposed configuration on an X300 that I had on hand. I don't have an LFRX, but I substituted a BasicRX instead, which I assume should behave the same for this test.
I first tried with the sub device specification "A:0 B:A". I wanted to get the first channel from the TwinRX and the real-mode input from the first input to the BasicRX. When I did so, UHD threw an exception indicating that it couldn't find a front end called "A." However, this front end is shown when I run uhd_usrp_probe.
A side question: I assume in real mode the data bypasses the X300's DDC, correct? I guess I wouldn't mind decimation, but I definitely don't want any tuning. I just want baseband samples as directly from the ADC as possible on the BasicRX input.
I then tried to specify a complex input from the BasicRX via the sub device specification "A:0 B:AB". This caused UHD to throw an exception complaining about conflicting tick rates (I've tried both 25 and 50 MSPS settings). It indicated one block was requesting 200 MHz and a neighboring block 100 MHz.
Any suggestions for coaxing the hardware to do what I need?
Jason
In real mode, the DDC is active, and converts to a complex baseband
signal. Assuming that you want to "see" DC-Fs/2 (or thereabouts), then
you can specify an Fc of Fs/2.
The UHD errors, I'll let someone in R&D comment about what the expected
behavior should be. Perhaps Derek Kozel, who does TwinRX dev.
On 2017-02-13 13:34, Jason Roehm via USRP-users wrote:
On Feb 9, 2017, at 10:09 PM, Marcus D. Leech via USRP-users usrp-users@lists.ettus.com wrote:
On 02/09/2017 08:38 PM, Jason Roehm via USRP-users wrote:
I have an application where I would like to use a TwinRX and LFRX simultaneously in a single X300 chassis. In this application, I would want to synchronously sample the TwinRX channels along with a single DC-coupled baseband input from the LFRX (i.e. I would want to stream time-aligned samples from these three inputs). Is this a supported configuration? I think I've seen some mailing list traffic before that indicated problems with mixing different types of daughterboards in a single enclosure like this. I've lost track of which UHD versions in recent history have sufficient DDC resources to handle both the dual channels of the TwinRX AND another channel from another single-channel card. Perhaps Jonathan Pendlum can comment?
I tried the proposed configuration on an X300 that I had on hand. I
don't have an LFRX, but I substituted a BasicRX instead, which I assume
should behave the same for this test.
I first tried with the sub device specification "A:0 B:A". I wanted to
get the first channel from the TwinRX and the real-mode input from the
first input to the BasicRX. When I did so, UHD threw an exception
indicating that it couldn't find a front end called "A." However, this
front end is shown when I run uhd_usrp_probe.
A side question: I assume in real mode the data bypasses the X300's DDC,
correct? I guess I wouldn't mind decimation, but I definitely don't want
any tuning. I just want baseband samples as directly from the ADC as
possible on the BasicRX input.
I then tried to specify a complex input from the BasicRX via the sub
device specification "A:0 B:AB". This caused UHD to throw an exception
complaining about conflicting tick rates (I've tried both 25 and 50 MSPS
settings). It indicated one block was requesting 200 MHz and a
neighboring block 100 MHz.
Any suggestions for coaxing the hardware to do what I need?
Jason
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
On Feb 13, 2017, at 1:52 PM, mleech@ripnet.com wrote:
In real mode, the DDC is active, and converts to a complex baseband signal. Assuming that you want to "see" DC-Fs/2 (or thereabouts), then you can specify an Fc of Fs/2.
I assume you mean I would want to set a center frequency of fs/4 if I wanted DC to fs/2 visible. However, the DC-coupled nature of the LFRX is important for my application, so I would need to tune somewhat lower than that to ensure that DC isn't in the stopband of the DDC's lowpass filter. Is this frequency response actually published anywhere? I understand that I could examine the implementation and calculate it myself, but this would seem to be a key performance characteristic of the USRP that should be specified.
Thanks for your help. Hopefully I can get some clarity on the UHD errors that I'm getting.
Jason
On 02/13/2017 06:32 PM, Jason Roehm wrote:
On Feb 13, 2017, at 1:52 PM, mleech@ripnet.com
mailto:mleech@ripnet.com wrote:
In real mode, the DDC is active, and converts to a complex baseband
signal. Assuming that you want to "see" DC-Fs/2 (or thereabouts),
then you can specify an Fc of Fs/2.
I assume you mean I would want to set a center frequency of fs/4 if I
wanted DC to fs/2 visible. However, the DC-coupled nature of the LFRX
is important for my application, so I would need to tune somewhat
lower than that to ensure that DC isn't in the stopband of the DDC's
lowpass filter. Is this frequency response actually published
anywhere? I understand that I could examine the implementation and
calculate it myself, but this would seem to be a key performance
characteristic of the USRP that should be specified.
Yes, I meant Fs/4. Sorry.
The DDC frequency response depends somewhat on the requested to-the-host
sample rate. There's a CIC decimator, and one or two
half-band filters, depending on desired sample rate. The
implementation changes from time to time so I don't think that
nailed-to-the-wall
filter responses can be counted on.
Thanks for your help. Hopefully I can get some clarity on the UHD
errors that I'm getting.
Jason
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.
Regards,
Derek
On Mon, Feb 13, 2017 at 5:19 PM, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
On 02/13/2017 06:32 PM, Jason Roehm wrote:
On Feb 13, 2017, at 1:52 PM, mleech@ripnet.com wrote:
In real mode, the DDC is active, and converts to a complex baseband
signal. Assuming that you want to "see" DC-Fs/2 (or thereabouts), then you
can specify an Fc of Fs/2.
I assume you mean I would want to set a center frequency of fs/4 if I
wanted DC to fs/2 visible. However, the DC-coupled nature of the LFRX is
important for my application, so I would need to tune somewhat lower than
that to ensure that DC isn't in the stopband of the DDC's lowpass filter.
Is this frequency response actually published anywhere? I understand that I
could examine the implementation and calculate it myself, but this would
seem to be a key performance characteristic of the USRP that should be
specified.
Yes, I meant Fs/4. Sorry.
The DDC frequency response depends somewhat on the requested to-the-host
sample rate. There's a CIC decimator, and one or two
half-band filters, depending on desired sample rate. The
implementation changes from time to time so I don't think that
nailed-to-the-wall
filter responses can be counted on.
Thanks for your help. Hopefully I can get some clarity on the UHD errors
that I'm getting.
Jason
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
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