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
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
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
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
>
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 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
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 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
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.
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
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
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
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
13 matches
Mail list logo
