That would be the radio reporting the overflow then. So, it sounds like
your gate causes data to back up into the radio where it eventually ran out
of room. Increasing the PYLD_FIFO_SIZE makes more space for data to buffer
up, increasing the time before an overflow would occur
Wade
On Fri, Aug 18
I was reading the metadata to check for a overflow (similar to the examples).
Is there a way to check specifically what block is giving an overflow? I only
know how to check if there is an overflow.
I was able to increase the overall data rate without overflow by increasing
PYLD_FIFO_SIZE of th
What was the error message or symptom that told you that you were getting
an overflow? RFNoC has flow control throughout the datapath, so when things
can't keep up, the pipe normally backs up into the radio and that's where
the overrun occurs. In other words, when the radio receives a new sample
bu
Increasing PYLD_FIFO_SIZE does in fact allow me to increase the burst size
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
I assume it occurs between my custom block and the SFP. Is there a way to tell
exactly which block it occurs at using the software?
At a high level, my current network goes… ADC -> Radio -> CHDR_crossbar ->
Custom Block -> Rx_streamer
My custom block has its s_axis_tready signal hooked up to th
On 16/08/2023 17:26, Johnny Samuels via USRP-users wrote:
I’m trying to remove myself from this mailing list. Sending
unsubscribe to the given email does not remove me from the list. Any
suggestions?
Sent from my iPhone
You sent an "unsubscribe" to:
usrp-users-le...@lists.ettus.com
And it
I’m trying to remove myself from this mailing list. Sending unsubscribe to the given email does not remove me from the list. Any suggestions? Sent from my iPhoneOn Aug 16, 2023, at 5:17 PM, Wade Fife wrote:You are correct about
INGRESS_BUFF_SIZE. It's only used to buffer data that the stream end
You are correct about INGRESS_BUFF_SIZE. It's only used to buffer data that
the stream endpoint receives from another endpoint (e.g., data sent from
the host computer to a stream endpoint). There's no extra buffering in the
sending stream endpoint. For normal RX where we stream to a host computer,
For my application, I am not collecting samples continuously. The radio block
is commanded to stream continuously, but I have a custom block downstream which
“gates” samples in bursts that pass through. I am able to at least stream data
without any overflows as long as the number of samples the
If you are streaming data from the radio, then overflows are to be expected
since 10 GbE can't keep up with 500 Msps. But that should happen with
64-bit CHDR as well. It doesn't matter how big the buffers are.
If you are not using the radio, then overflows should not occur at all,
since there's no
Yes, the YAML file is set to 128 chdr_width. I am using v4.4.0.0
___
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
Hi Joe,
Did you change the chdr_width in the rfnoc_image_core YAML file and rerun
rfnoc_image_builder on that file?
Which version of UHD are you using to build the FPGA?
Streaming over 10 GbE to 128-bit CHDR with 500 Msps radio isn't a use case
we test, since 10 GbE can't keep up. Normally we wo
12 matches
Mail list logo
