[USRP-users] Fwd: USRP X310 Ubuntu 16.04 LowLatency Timing Problems Possibly Because of UHD Drivers

Marcus D. Leech patchvonbraun at gmail.com
Fri Feb 8 09:23:39 EST 2019


On 02/08/2019 04:37 AM, akin soysal via USRP-users wrote:
> I am resending the mail to the forum so that everybody benefits.
>
> ---------- Forwarded message ---------
> From: *akin soysal* <akinsoysal at gmail.com <mailto:akinsoysal at gmail.com>>
> Date: Fri, Feb 8, 2019 at 10:29 AM
> Subject: Re: [USRP-users] USRP X310 Ubuntu 16.04 LowLatency Timing 
> Problems Possibly Because of UHD Drivers
> To: Marcus D. Leech <patchvonbraun at gmail.com 
> <mailto:patchvonbraun at gmail.com>>
>
>
> Hello Marcus,
>
> OK, I tried, it seems the HW is not supporting the desired rate. It is 
> a NI CBX120 MHz daughterboard with USRP X310. Does that make sense? I 
> thought these sample rates were specifically for this HW??
>
> ulak at 5g-NR-gNB:/usr/local/lib/uhd/examples$ sudo 
> ./tx_samples_from_file --rate 61.44e6

Include "master_clock_rate=184.32e6" in your device arguments--the 
default master clock is 200MHz, and 61.44Msps is definitely not an integer
   fraction of 200MHz...


>
> Creating the usrp device with: ...
> [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
> UHD_3.13.1.HEAD-0-gbbce3e45
> [INFO] [X300] X300 initialization sequence...
> [INFO] [X300] Maximum frame size: 8000 bytes.
> [INFO] [X300] Radio 1x clock: 200 MHz
> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID: 
> 0xF1F0D00000000000)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1302 MB/s)
> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1313 MB/s)
> [INFO] [0/Radio_0] Initializing block control (NOC ID: 0x12AD100000000001)
> [INFO] [0/Radio_1] Initializing block control (NOC ID: 0x12AD100000000001)
> [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0000000000000)
> [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0000000000000)
> [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0000000000000)
> [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0000000000000)
> Using Device: Single USRP:
> Device: X-Series Device
> Mboard 0: X310
> RX Channel: 0
> RX DSP: 0
> RX Dboard: A
> RX Subdev: CBX-120 RX
> RX Channel: 1
> RX DSP: 0
> RX Dboard: B
> RX Subdev: CBX-120 RX
> TX Channel: 0
> TX DSP: 0
> TX Dboard: A
> TX Subdev: CBX-120 TX
> TX Channel: 1
> TX DSP: 0
> TX Dboard: B
> TX Subdev: CBX-120 TX
>
> Setting TX Rate: 61.440000 Msps...
> [WARNING] [RFNOC] The requested interpolation is odd; the user should 
> expect passband CIC rolloff.
> Select an even interpolation to ensure that a halfband filter is enabled.
> interpolation = dsp_rate/samp_rate -> 3 = (200.000000 MHz)/(61.440000 MHz)
>
> [WARNING] [RFNOC] The requested interpolation is odd; the user should 
> expect passband CIC rolloff.
> Select an even interpolation to ensure that a halfband filter is enabled.
> interpolation = dsp_rate/samp_rate -> 3 = (200.000000 MHz)/(61.440000 MHz)
>
> [WARNING] [MULTI_USRP] The hardware does not support the requested TX 
> sample rate:
> Target sample rate: 61.440000 MSps
> Actual sample rate: 66.666667 MSps
>
> [WARNING] [MULTI_USRP] The hardware does not support the requested TX 
> sample rate:
> Target sample rate: 61.440000 MSps
> Actual sample rate: 66.666667 MSps
>
> Actual TX Rate: 66.666667 Msps...
>
> Please specify the center frequency with --freq
>
> On Thu, Feb 7, 2019 at 5:18 PM Marcus D. Leech via USRP-users 
> <usrp-users at lists.ettus.com <mailto:usrp-users at lists.ettus.com>> wrote:
>
>     On 02/07/2019 08:50 AM, akin soysal via USRP-users wrote:
>>
>>     Dear all,
>>
>>
>>     We are trying to make the OpenAirInterface 5G SW work on our own
>>     setup with NI USRPs. We are trying to use it with the following
>>     configuration:
>>
>>
>>     sudo ./benchmark_rate --args
>>     "type=x300,addr=10.10.1.5,master_clock_rate=184.32e6" --rx_rate
>>     61.44e6 --tx_rate 61.44e6 --channels="0"
>>
>>
>>     For different UHD versions we get different results. Firstly, we
>>     know that the OAI setup in France is using the following driver
>>     and gives the following output:
>>
>>
>>     ---
>>
>>     [0m[PHY]  Checking for USRPs :UHD 003.009.007-0-g50839059(3.9.7)
>>     [0m[PHY]  Found USRP X300
>>     [0m[PHY]  ru_thread_prach() RACH waiting for RU to be configured
>>     -- X300 initialization sequence...
>>     -- Connecting to niusrpriorpc at localhost:5444...
>>     -- Using LVBITX bitfile
>>     /usr/local/share/uhd/images/usrp_x310_fpga_HGS.lvbitx...
>>     [0m[PHY]  ru_thread_prach() RACH waiting for RU to be configured
>>     [0m[PHY]  ru_thread_prach() RACH waiting for RU to be configured
>>     [0m[PHY]  ru_thread_prach() RACH waiting for RU to be configured
>>     -- Setup basic communication...
>>     -- Loading values from EEPROM...
>>     -- Setup RF frontend clocking...
>>     -- Radio 1x clock:184.32
>>     -- Detecting internal GPSDO.... Found an internal GPSDO: LC_XO,
>>     Firmware Rev 0.929a
>>     ---
>>
>>
>>     We tried the same configuration, but we got errors:
>>
>>
>>     ---
>>
>>     ulak at 5g-NR-gNB:/usr/local/lib/uhd/examples$ sudo ./benchmark_rate
>>     --args "type=x300,addr=10.10.1.5,master_clock_rate=184.32e6"
>>     --rx_rate 61.44e6 --tx_rate 61.44e6 --channels="0"
>>     [sudo] password for ulak:
>>     linux; GNU C++ version 5.4.0 20160609;
>>     Boost_105800;UHD_003.009.007-0-g50839059
>>
>>
>>     Creating the usrp device with:
>>     type=x300,addr=10.10.1.5,master_clock_rate=184.32e6...
>>     -- X300 initialization sequence...
>>     -- Determining maximum frame size... 8000 bytes.
>>     -- Setup basic communication...
>>     -- Loading values from EEPROM...
>>     -- Setup RF frontend clocking...
>>     -- Radio 1x clock:184.32
>>     -- Detecting internal GPSDO.... No GPSDO found
>>     -- Initialize Radio0 control...
>>     -- Performing register loopback test... pass
>>
>>     UHD Error:
>>     The daughterboard manager encountered a recoverable error in init.
>>         Loading the "unknown" daughterboard implementations to continue.
>>         The daughterboard cannot operate until this error is resolved.
>>         EnvironmentError: IOError: Radio ctrl (A) packet parse error
>>     - AssertionError: packet_info.packet_count == (seq_to_ack & 0xfff)
>>           in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
>>           at
>>     /home/ulak/uhd/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:264
>>     Error: EnvironmentError: IOError: Radio ctrl (A) packet parse
>>     error - AssertionError: packet_info.packet_count == (seq_to_ack &
>>     0xfff)
>>       in uint64_t radio_ctrl_core_3000_impl::wait_for_ack(bool)
>>       at
>>     /home/ulak/uhd/uhd/host/lib/usrp/cores/radio_ctrl_core_3000.cpp:264
>>
>>     ---
>>
>>
>>     By the way, we have bought CBX 120MHz daughterboards instead of
>>     CBX 40MHz but would that actually create any problems? I thought
>>     it is just the RF difference but maybe some configuration is
>>     necessary from the drivers?
>>
>>
>>     Then we downloaded and compiled the latest UHD version:
>>
>>
>>     ---
>>
>>     [PHY]   UHD version3.13.1.HEAD-0-gbbce3e45 (3.13.1)
>>     [PHY]   Checking for USRP with args
>>     type=x300,addr=10.10.1.5,master_clock_rate=184.32e6,fpga=HG
>>     [INFO] [UHD] linux; GNU C++ version 5.4.0 20160609; Boost_105800;
>>     UHD_3.13.1.HEAD-0-gbbce3e45
>>     Found USRP x300
>>     Found USRP x300
>>     [INFO] [X300] X300 initialization sequence...
>>     [INFO] [X300] Maximum frame size: 8000 bytes.
>>     [INFO] [X300] Radio 1x clock: 184.32 MHz
>>     [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
>>     0xF1F0D00000000000)
>>     [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1301 MB/s)
>>     [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1309 MB/s)
>>     [INFO] [0/Radio_0] Initializing block control (NOC ID:
>>     0x12AD100000000001)
>>     [INFO] [0/Radio_1] Initializing block control (NOC ID:
>>     0x12AD100000000001)
>>     [INFO] [0/DDC_0] Initializing block control (NOC ID:
>>     0xDDC0000000000000)
>>     [INFO] [0/DDC_1] Initializing block control (NOC ID:
>>     0xDDC0000000000000)
>>     [INFO] [0/DUC_0] Initializing block control (NOC ID:
>>     0xD0C0000000000000)
>>     [INFO] [0/DUC_1] Initializing block control (NOC ID:
>>     0xD0C0000000000000)
>>     [PHY]   ru_thread_prach() RACH waiting for RU to be configured
>>     [PHY]   device_init() sample_rate:61440000
>>     [WARNING] [RFNOC] The requested decimation is odd; the user
>>     should expect passband CIC rolloff.
>>     Select an even decimation to ensure that a halfband filter is
>>     enabled.
>>     Decimations factorable by 4 will enable 2 halfbands, those
>>     factorable by 8 will enable 3 halfbands.
>>     decimation = dsp_rate/samp_rate -> 3 = (184.320000
>>     MHz)/(61.440000 MHz)
>>
>>     [PHY]   cal 0: freq 3500000000.000000, offset 77.000000, diff
>>     2262291232.000000
>>     [PHY]   cal 1: freq 2660000000.000000, offset 81.000000, diff
>>     1422291232.000000
>>     [PHY]   cal 2: freq 2300000000.000000, offset 81.000000, diff
>>     1062291232.000000
>>     [PHY]   cal 3: freq 1880000000.000000, offset 82.000000, diff
>>     642291232.000000
>>     [PHY]   cal 4: freq 816000000.000000, offset 85.000000, diff
>>     421708768.000000
>>     [PHY]   RX Gain 0 24.000000 (85.000000) => -61.000000 (max 37.500000)
>>     [WARNING] [RFNOC] The requested interpolation is odd; the user
>>     should expect passband CIC rolloff.
>>     Select an even interpolation to ensure that a halfband filter is
>>     enabled.
>>     interpolation = dsp_rate/samp_rate -> 3 = (184.320000
>>     MHz)/(61.440000 MHz)
>>     ---
>>
>>
>>     Configuration is successful and we can run the code with it but
>>     we get late packets in the beginning and end. Also samples are
>>     missed every 50-100 ms.
>>
>>
>>     ---
>>
>>     LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLD[PHY]   [recv]received 28728 samples out of 61440
>>     L[PHY]   rx_rf: Asked for 61440 samples, got 28728 from USRP
>>     [PHY]   problem receiving samples
>>     LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL[PHY]   [recv] received 0 samples out of 61440
>>     LLLL[PHY]   Time: 4.51512 s
>>     ERROR_CODE_OVERFLOW (Out of sequence error)
>>
>>     [PHY]   rx_rf: Asked for 61440 samples, got 0 from USRP
>>     [PHY]   rx_rf: rfdevice timing drift of -32712 samples (ts_off 212929711)
>>     [PHY]   problem receiving samples
>>     LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL[PHY]   rx_rf: rfdevice timing drift of 858716 samples (ts_off 212896999)
>>     LLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLLL
>>     ---
>>
>>
>>     Our setup should be capable of running the SW, so it has to be
>>     the UHD driver or the 10 GbE cable but we are using optical
>>     fiber, so I do not think the problem is that either.
>>
>>
>>     Then we tried another UHD version from the USRP X310 recovery page:
>>
>>
>>     ---
>>
>>     linux; GNU C++ version 5.4.0 20160609;
>>     Boost_105800;UHD_003.010.001.HEAD-0-gc705922a
>>
>>     -- X300 initialization sequence...
>>     -- Determining maximum frame size... 8000 bytes.
>>     -- Setup basic communication...
>>     =========================================================
>>     Warning:
>>     Expected FPGA compatibility number 33, but got 35:
>>     The FPGA image on your device is not compatible with this host
>>     code build.
>>     Download the appropriate FPGA images for this version of UHD.
>>     Please run:
>>
>>      "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>>
>>     Then burn a new image to the on-board flash storage of your
>>     USRP X3xx device using the image loader utility. Use this command:
>>
>>     "/usr/local/bin/uhd_image_loader" --args="type=x300,addr=10.10.1.5"
>>
>>     For more information, refer to the UHD manual:
>>
>>     http://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_flash=========================================================
>>     Error: RuntimeError: Expected firmware compatibility number 5.1,
>>     but got 6.0:
>>     The firmware build is not compatible with the host code build.
>>     Please run:
>>
>>      "/usr/local/lib/uhd/utils/uhd_images_downloader.py"
>>
>>     ---
>>
>>
>>     We get a different error after doing what is requested:
>>
>>
>>     ----
>>
>>     ulak at 5g-NR-gNB:~/uhd/uhd$ uhd_usrp_probe
>>     linux; GNU C++ version 5.4.0 20160609;
>>     Boost_105800;UHD_003.010.001.HEAD-0-gc705922a
>>
>>     -- X300 initialization sequence...
>>     -- Determining maximum frame size... 8000 bytes.
>>     -- Setup basic communication...
>>     -- Loading values from EEPROM...
>>     -- Setup RF frontend clocking...
>>     -- Radio 1x clock:200
>>     -- [DMA FIFO] Running BIST for FIFO 0... pass (Throughput:
>>     1304.1MB/s)
>>     -- [DMA FIFO] Running BIST for FIFO 1... pass (Throughput:
>>     1305.1MB/s)
>>     -- [RFNoC Radio] Performing register loopback test... pass
>>     -- [RFNoC Radio] Performing register loopback test... pass
>>     -- [RFNoC Radio] Performing register loopback test... pass
>>     -- [RFNoC Radio] Performing register loopback test... pass
>>     Error: LookupError: KeyError: Unknown settings register name:
>>     CORDIC_FREQ
>>
>>     ----
>>
>>
>>     Your help would be much appreciated.
>>
>>
>>     Regards,
>>
>>     Akın
>>
>>
>     Start by using a simpler program to diagnose the basics. .
>
>     Use something like tx_samples_from_file at your desired rates  (or
>     tx_waveforms).  Do those work? The problem with using full-up complex
>       applications for problem diagnosis is that they don't actually
>     tell you very much--it's hard to decompose.
>
>
>
>     _______________________________________________
>     USRP-users mailing list
>     USRP-users at lists.ettus.com <mailto:USRP-users at lists.ettus.com>
>     http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> _______________________________________________
> 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/20190208/2b2537da/attachment.html>


More information about the USRP-users mailing list