Re: [USRP-users] transmitting on two channels with replay block

2019-12-09 Thread Thomas Harder via USRP-users
Hi Sam, Thank you for your reply. This morning I set the MCR to 184.32 and I am still having continuous underruns using also replay_ctrl->get_record_fullness for both channels. But since I need the full bandwidth of 160MHz I would like implement a second replay block in my fpga image. Could a

Re: [USRP-users] Default RFNoC image for N310 does not compile

2019-12-09 Thread Nate Temple via USRP-users
Hi Robert, Thanks for the bug report. If you're just trying to use RFNoC at this point, I would recommend to stick with the latest stable release, which at this time is v3.14.1.1. Note, 3.14.x.x UHD will require Vivado 2017.4. Regards, Nate Temple On Mon, Dec 9, 2019 at 7:33 AM Robert via USR

Re: [USRP-users] Phase relation between RX/TX LO

2019-12-09 Thread Marcus D. Leech via USRP-users
On 12/08/2019 05:19 PM, Lukas Haase wrote: Hi Marcus, You'll need to look at the API here: https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a191b78b00d051d3d51c2f719361c1fb5 and here: https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a607aee766d21228a7aaa

Re: [USRP-users] Phase relation between RX/TX LO

2019-12-09 Thread Lukas Haase via USRP-users
Hi Marcus, > Von: "Marcus D. Leech" > On 12/08/2019 05:19 PM, Lukas Haase wrote: > > Hi Marcus, > > > >> You'll need to look at the API here: > >> > >> https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#a191b78b00d051d3d51c2f719361c1fb5 > >> > >> and here: > >> > >> https://files

Re: [USRP-users] Default RFNoC image for N310 does not compile

2019-12-09 Thread Nate Temple via USRP-users
Hi Robert, So this is a bug related to Vivado, you will need to install this linked below patch and it should resolve it. https://www.xilinx.com/support/answers/71898.html Regards, Nate Temple On Mon, Dec 9, 2019 at 10:38 AM Nate Temple wrote: > Hi Robert, > > Thanks for the bug report. > > I

Re: [USRP-users] Phase relation between RX/TX LO

2019-12-09 Thread Marcus D. Leech via USRP-users
On 12/09/2019 02:38 PM, Lukas Haase wrote: Precicely. What frequencies are involved here? Example: Transmit 900 Mhz (USRP Sink). Receive 1800 MHz (USRP Source). The received signal will have arbitrary phase phi1. To make sure we're on the same page, you're measuring the phase offset between

Re: [USRP-users] Phase relation between RX/TX LO

2019-12-09 Thread Lukas Haase via USRP-users
Hi Marcus, > Von: "Marcus D. Leech" > > On 12/09/2019 02:38 PM, Lukas Haase wrote: > > > > Precicely. > > > >> What frequencies are involved here? > > Example: Transmit 900 Mhz (USRP Sink). > > Receive 1800 MHz (USRP Source). > > > > The received signal will have arbitrary phase phi1. > To make s

Re: [USRP-users] Phase relation between RX/TX LO

2019-12-09 Thread Marcus D. Leech via USRP-users
On 12/09/2019 03:11 PM, Lukas Haase wrote: No, I only have one RX channel at the moment. --> One TX @ f and one RX @ 2f. The phase relation between this TX+RX should stay constant/coherent once both TX+RX tune to a different f and back. Let me know if the setup is clear, otherwise I'll try to

Re: [USRP-users] Phase relation between RX/TX LO

2019-12-09 Thread Lukas Haase via USRP-users
Hi Marcus, > Von: "Marcus D. Leech" > > On 12/09/2019 03:11 PM, Lukas Haase wrote: > > > > No, I only have one RX channel at the moment. > > --> One TX @ f and one RX @ 2f. > > The phase relation between this TX+RX should stay constant/coherent once > > both TX+RX tune to a different f and back.

Re: [USRP-users] Phase relation between RX/TX LO

2019-12-09 Thread Marcus D. Leech via USRP-users
On 12/09/2019 03:35 PM, Lukas Haase wrote: Hi Marcus, Von: "Marcus D. Leech" On 12/09/2019 03:11 PM, Lukas Haase wrote: No, I only have one RX channel at the moment. --> One TX @ f and one RX @ 2f. The phase relation between this TX+RX should stay constant/coherent once both TX+RX tune to a

Re: [USRP-users] Phase relation between RX/TX LO

2019-12-09 Thread Marcus D. Leech via USRP-users
Something that MAY help here is to use integer_n tuning: treq=uhd.tune_request(my_frequency) treq.args=uhd.device_addr("mode_n=integer") ... ...set_center_freq(treq, 0) This will force the PLL to use INTEGER_N tuning, which has more predictable phase behavior with respect to

Re: [USRP-users] GPIOs timed commands

2019-12-09 Thread Sam Reiter via USRP-users
I believe this will work. It should just be a matter of setting the command time before you send over a usrp->set_gpio_attr() Sam Reiter Ettus Research On Thu, Dec 5, 2019 at 2:34 AM Emanuel via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi everybody, > > > > could the GPIOs, e.g., on a

Re: [USRP-users] Error message: UHD: 1

2019-12-09 Thread Sam Reiter via USRP-users
Lukas, You can test your hardware and software stack by running a couple UHD shipping examples. Check out the examples here: https://kb.ettus.com/Verifying_the_Operation_of_the_USRP_Using_UHD_and_GNU_Radio You can also recompile UHD with the logging level set to trace in your CMAKE flags: https:/

Re: [USRP-users] Time Synchronized Transmit with 2 USRPs

2019-12-09 Thread Sam Reiter via USRP-users
Hasan, Are the USRPs sharing any kind of timing / clocking signals? Typically we would recommend that you share a reference clock and PPS clock across all devices, and from there you'd just need to coordinate timed commands. With timed commands in UHD, you can tell each USRP to reset its internal

Re: [USRP-users] Libuhd issues - "uhd_find_devices: error while loading shared libraries"

2019-12-09 Thread Saeid Hashemi via USRP-users
Thank you for your advice Fabian! It seems there is no package called libuhd, just the following versions: libuhd003 libuhd3.14.0 libuhd-dev So I did: $ sudo dpkg -P libuhd3.14.0 (Reading database ... 291299 files and directories currently installed.) Removing libuhd3.14.0:amd64 (3.14.0.0-0

[USRP-users] DPDK build with N310

2019-12-09 Thread Akis Kourtis via USRP-users
Hello all, I am trying to build the oai-5g-gNB. I have managed to build the DPDK with uhd successfully, however when I run the probe command I receive the following error. EAL: Starting I/O threads! [INFO] [UHD] linux; GNU C++ version 7.4.0; Boost_106501; UHD_3.14.1.HEAD-0-g0347a6d8 [INFO

[USRP-users] E312 RX_B issue

2019-12-09 Thread Beeman, Isaac L. via USRP-users
Hello group, I have run into an issue with the RX_B port (channel 1) on the E312 that I haven't been able to make any sense of. RX_A (channel 0) works great: I get clear in-phase and quadrature components that I have been able to graph. When I do the same thing with

Re: [USRP-users] transmitting on two channels with replay block

2019-12-09 Thread Rob Kossler via USRP-users
Apart from solving the underrun issue, there is also an issue with synchronization. The replay block doesn't presently support timed commands. And, as a side note, the issue with streaming from the host is not just the host. The DMA FIFO has a maximum bandwidth of something like 600 MS/s (combin

Re: [USRP-users] Phase relation between RX/TX LO

2019-12-09 Thread Lukas Haase via USRP-users
Hi Marcus, > Gesendet: Montag, 09. Dezember 2019 um 15:58 Uhr > > On 12/09/2019 03:35 PM, Lukas Haase wrote: > > Hi Marcus, > > > >> Von: "Marcus D. Leech" > >> > >> On 12/09/2019 03:11 PM, Lukas Haase wrote: > >>> No, I only have one RX channel at the moment. > >>> --> One TX @ f and one RX @ 2f

Re: [USRP-users] Phase relation between RX/TX LO

2019-12-09 Thread Marcus D. Leech via USRP-users
On 12/09/2019 11:03 PM, Lukas Haase wrote: Hi Marcus, Gesendet: Montag, 09. Dezember 2019 um 15:58 Uhr On 12/09/2019 03:35 PM, Lukas Haase wrote: Hi Marcus, Von: "Marcus D. Leech" On 12/09/2019 03:11 PM, Lukas Haase wrote: No, I only have one RX channel at the moment. --> One TX @ f and

Re: [USRP-users] Phase relation between RX/TX LO

2019-12-09 Thread Lukas Haase via USRP-users
Hi Marcus, > Von: "Marcus D. Leech" > [...] > > > You're using the MANUAL policy for BOTH DSP and RF. Let the automatic > "stuff" do its thing, with the only difference being integer-N tuning. Wow, this is all so black magic. After a long time I figured out that I also have to supply int_n_ste