Thanks for reporting back, Jim! I'm glad redoing the 1G networking resolved
the issue & got you to the expected max sample rate for the E320 in network
mode. Since I almost never use the 1G SFP+ mode, I'm not worried about my
1G networking & will just stick with the 10G SFP+ mode which works nicely
Hi Dylan,
Can you try adding "rx_usrp->set_time_now(uhd::time_spec_t(0.0));" after
line 526 in txrx_loopback_to_file.cpp, re-build, and see if that fixes your
issue?
Jonathon
On Wed, Dec 9, 2020 at 9:37 AM Dylan Baros via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Good morning,
>
> I am
I'd like to pass metadata over the dataplane using the available space in the
CHDR header. However, I cannot find an easy way to do this using UHD3.15.
I've identified two possible approaches but I'm not sure either will work:
(1) Set AXI_Wrapper (Simple_Mode =0) to require user provided CHDR h
I meant rfnoc_create_verilog.py
https://github.com/EttusResearch/uhd/blob/master/host/utils/rfnoc_blocktool/rfnoc_create_verilog.py
jeff
From: Hodges, Jeff
Sent: Friday, December 11, 2020 3:44:41 PM
To: usrp-users@lists.ettus.com
Subject: RFNoC passing metadata
That did the trick Jonathon. Thank you!
From: Jonathon Pendlum
Sent: Friday, December 11, 2020 1:48 PM
To: Dylan Baros
Cc: usrp-users@lists.ettus.com
Subject: [EXTERNAL] Re: [USRP-users] Receiver error ERROR_CODE_LATE_COMMAND
with txrx_loopback_to_file example.
Hi Jeff,
RFNoC3 / UHD 3.15 does not support metadata. That is a new feature in
RFNoC4 / UHD 4.0, so option 2 is not possible.
If you want to send out metadata in RFNoC3, I would suggest prepending it
to packets you send to AXI wrapper. You can still use SIMPLE_MODE as long
as you are producing a
On 12/6/20 10:03 AM, Ron Economos via USRP-users wrote:
> Unfortunately, that FFTW bug has been around for a while. Issue 213 is a
> duplicate of issue 182 from a year+ ago.
>
> https://github.com/FFTW/fftw3/issues/182
>
> On Ubuntu 20.04 armhf, they're just compiling the FFTW package without
> N
Hi Rob,
The SEPs do have the ability to swap I and Q. This is because on the host
computer, I is usually in the lower bits and Q is in the upper bits of each
32-bit word, but in RFNoC, for historical reasons, I goes in the upper bits
and Q in the lower bits. The software programs the IQ swapping w
Hi Wade,
Thanks for the info. I still do not know what's going on, but here are a
few updates:
- I built a new N310 image with 4 switchboards (1x1) and 1
splitstream (1x2) blocks in addition to the default blocks. All of the
additional blocks are connected to SEPs for dynamic linking.
Hi Wade,
After thinking about it a bit, I would ignore the "negation" issue for now.
This may be a byproduct of I/Q swapping related to my custom block.
Rob
On Fri, Dec 11, 2020 at 6:34 PM Rob Kossler wrote:
> Hi Wade,
> Thanks for the info. I still do not know what's going on, but here are a
>
AHA! I duplicated the issue with the Switchboard image. The way to
duplicate the issue is the run the following series of graphs:
host_tx => Switchboard#0 => Switchboard#1 => host_rx // SUCCESS
host_tx => Switchboard#2 => Switchboard#3 => host_rx // SUCCESS
host_tx => Switchboard#0 => Swi
Wade,
The following also fails using just 2 blocks and 2 attempts:
host_tx => Switchboard#0 => Switchboard#1 => host_rx // SUCCESS
host_tx => Switchboard#1 => Switchboard#0 => host_rx // FAILURE (RX
samples equal swapped I/Q of TX samples)
In addition to wanting to get this issue fixed, I al
I think we may have found a batch of e310s a few years ago (circa summer
2017 iirc?) that had bad oscillators and were traced back to the TCXO
manufacturer.
I don't remember the exact symptoms off the top of my head but those
discrete frequency jumps look a little familiar
EJ
On Tue, Nov 24, 20
13 matches
Mail list logo
