You cannot have a block with 0 inputs or 0 outputs from the HDL
perspective. You will always have at least 1 input and 1 output. You
can tie off the unused input or output though. Also, in your GRC XML,
you can choose not to declare the output or input. Check out
uhd_rfnoc_siggen.xml, which works j
I am still having trouble with my OOT block when I add a second radio in the
loop.
A reminder of what I am doing. Just to test my 2-in, 2-out RFNoC block, I am
swapping the inputs to the outputs (so input 0 goes to output 1).
When I have: Radio->DDC->MyBlockIn.0 --- MyBlockOut.1->vecToStream
Ettus Research, a National Instruments brand, is proud to announce the USRP
N300 Software Defined Radio (SDR) device. The USRP N300 is the lower cost
variant of the USRP N310. Likewise, this SDR delivers reliability and fault
tolerance for deployment and gives you the unique capability to remotely
Hey everybody,
I'll somehow repeat a question I asked here a couple of months ago, to see
again if I can get some guiding. Hope you understand:
The CHDR packet length field in the CHDR header is 16 bits (i.e. 65536
bytes theoretical max length), but by doing Wireshark captures and playing
with th
I recently upgraded to the newest versions of the development tools (fresh
pybombs installs of recipes rfnoc-e3xx for cross-compiling, and rfnoc for
local test and development). Since that time, all of my previously
functioning custom RFNOC blocks now hang in simulation on Vivado (they hang
at the
That's the MTU of your network interface limiting the CHDR packet size.
Can't break up CHDR packets over multiple network packets.
Nick
On Wed, Aug 1, 2018 at 11:25 AM Leandro Echevarría via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hey everybody,
>
> I'll somehow repeat a question I ask
On Wed, Aug 1, 2018 at 3:10 PM Andrew Danowitz via USRP-users <
usrp-users@lists.ettus.com> wrote:
> I recently upgraded to the newest versions of the development tools (fresh
> pybombs installs of recipes rfnoc-e3xx for cross-compiling, and rfnoc for
> local test and development). Since that time
On Wed, Aug 1, 2018 at 3:59 PM Nick Foster via USRP-users <
usrp-users@lists.ettus.com> wrote:
> That's the MTU of your network interface limiting the CHDR packet size.
> Can't break up CHDR packets over multiple network packets.
>
Is the last statement that CHDR can't break over multiple network
I am using the latest master UHD and the latest N310 SD card image and I am
getting the following error when I run uhd_image_loader. Despite the error
message, the operation seems to succeed with loading the new image. This
same error occurred on 3 systems (each with host PC & N310).
Rob
$ uhd_i
Hello Nick,
That's the spirit of my question: why couldn't you break up a CHDR packet
over multiple Ethernet frames? I understand it is common for Ethernet to
break up an IP packet (which would also have a 16-bits field for packet
size in its header) into fragments, but limiting the size of the CH
On 08/01/2018 02:24 PM, Leandro Echevarría via USRP-users wrote:
Hey everybody,
I'll somehow repeat a question I asked here a couple of months ago, to
see again if I can get some guiding. Hope you understand:
The CHDR packet length field in the CHDR header is 16 bits (i.e. 65536
bytes theore
Ian,
Thank you so much for taking the time to write such a detailed answer. And
thanks everyone who pitched in too. It's clear now.
Best regards,
Leo.
On Wed, Aug 1, 2018 at 8:22 PM Ian Buckley wrote:
> Leo,
> Ethernet does not fragment IP packets. There is a 1:1 relationship between
> ethern
12 matches
Mail list logo
