[USRP-users] Four channel tx/rx loopback failure

Michael West michael.west at ettus.com
Thu Apr 30 19:14:34 EDT 2015

Hi Rob,

First of all, the DAC is only used on TX so it is not surprising that RX
succeeds when TX fails.

This is a known issue and we have traced it down to missing constraints in
the FPGA image.  We have added the necessary constraints in our Vivado
migration, which will be available on the master branch of UHD soon.

For the short term, the check can be made non-fatal by applying the
attached patch (the warning message will still display).  Be aware that the
samples from the affected X310 may be offset by up to 5 ns (in 1.25 ns
increments).  The amount of the offset should be consistent, so it can be
calibrated out if necessary.


On Thu, Apr 30, 2015 at 3:35 PM, Rob Kossler via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Update.  This is not a gnuradio issue.  It seems to be device related and
> I can duplicate the problem with "benchmark_rate". While I previously
> thought it was as four channel vs two channel issue, I now know that I can
> demonstrate the issue with just two channels (on the "bad" X310).
> Here is the command that demonstrates the issue...
>    benchmark_rate --channels="0,1" --tx_rate=5e6 --duration=5
> Here is the error message...
> UHD Warning:
>     x300_dac_ctrl: front-end sync failed. unexpected FIFO depth [0x7]
> Error: RuntimeError: x300_dac_ctrl: front-end sync failed. unexpected FIFO
> depth [0x7]
> Comments:
> - If I run the exact same command with this same device but with
> '--channels="0"' or '--channels="1"', it runs fine. It even runs fine if I
> change the sample rate to 50e6 with only one channel.  So, individually,
> each channel runs fine.  It is only when running both simultaneously that
> the error occurs.
> - If I run the exact same command with this same device but with
> '--rx_rate=5e6' instead of '--tx_rate=5e6', it runs fine.  So, it can
> handle 2 channel receive streaming just fine.
> - If I run the exact same command with a different X310 device, it runs
> fine.  Note that I reprogrammed the FPGA on both X310 devices using
> "usrp_x3xx_fpga_burner" prior to running the test.  So, both devices should
> have the same FPGA.  I also used the same 10G NIC & cable. It is
> interesting that the device that is failing is brand new - just received it
> in the last couple of days.
> Any ideas?
> Rob Kossler
> PS. as mentioned yesterday, I am using 3.8.3 (UHD_003.008.003-0-g87dfdc3c)
> On Wed, Apr 29, 2015 at 6:38 PM, Rob Kossler <rkossler at nd.edu> wrote:
>> Hi,
>> I am having a failure with the attached GRC flowgraph. It is a four
>> channel Tx/Rx loopback using 2 Ettus X310 USRPs.  The flowgraph is simple
>> in that the Tx is simply a constant (center freq tone) and the Rx is
>> displayed on a QT freq sink.  Externally, the RF signals are looped back
>> from TX to RX with attenuation.
>> There are actually two flowgraphs in this attachment, but one of them is
>> disabled.  The one disabled is the two channel version which works fine.
>> By "fine", I mean that there is no UHD Warning message reported in the
>> reports window, the TX LEDs both come on, and the QT freq sink shows a tone
>> on the center of the four RX channels, as expected.
>> When I run the four channel version (presently enabled in the flowgraph),
>> I get a UHD warning (see below and/or in the attached file "tr_test.out"),
>> the TX LEDs do not come on, and the displayed spectrum has no tone at the
>> center.
>> There is hardly a difference between the four channel flowgraph and the
>> two channel flowgraph.  The four channel version has motherboard and
>> channel counts of 2 and 4 while the two channel version has corresponding
>> counts of 1 and 2.  Additionally, the device address field has 2 addresses
>> rather than 1 in the four channel version.
>> This failure does not seem to be intermittent.  Every time I have run the
>> two channel version, it has been successful and every time I have run the
>> four channel version it has been unsuccessful.  Also, this was executed
>> after having just re-built both UHD and gnuradio via "./pybombs update".
>> Here is the pertinent info from the reports window when I run the four
>> channel version.  Note that the full output is available in the attachment
>> "tr_test.out".
>> <<< Welcome to GNU Radio Companion 3.7.8git-111-g1425e482 >>>
>> ...
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.003-0-g87dfdc3c
>> ...
>> Using Volk machine: avx_64_mmx_orc
>> UHD Warning:
>>     x300_dac_ctrl: front-end sync failed. unexpected FIFO depth [0x7]
>> thread[thread-per-block[1]: <block gr uhd usrp sink (2)>]: RuntimeError:
>> x300_dac_ctrl: front-end sync failed. unexpected FIFO depth [0x7]
>> >>> Done
>> Finally, on a perhaps related note, it is really not clear to me which
>> USRP configuration parameters should be repeated between the UHD source and
>> sink.  I am familiar with operating directly with the UHD driver from C++
>> where you create a single USRP with various config information such as
>> device address, clock ref, timing ref and then create separate RX and TX
>> streamers.  When operating from GNU radio with both a UHD source and sink,
>> it is not clear if all of that config info should be repeated in both
>> source and sink (which is what I did in the attached flowgraph) or if some
>> of it does not need to be repeated.  For example, I have both source and
>> sink with "sync" option of "unknown_pps".  Perhaps this is only needed in
>> one or the other??  Perhaps the clock and timing ref parameters are only
>> needed in one or the other??
>> Thanks.
>> Rob Kossler
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150430/7a1fa778/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uhd_3_8_3_X310_DAC_synch.patch
Type: text/x-patch
Size: 419 bytes
Desc: not available
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20150430/7a1fa778/attachment.patch>

More information about the USRP-users mailing list