The delay is from the time it takes to drain the DMA FIFO. The DMA FIFO
default size is 32 MB. It can be controlled through the property tree or,
if using RFNoC, through the DMA FIFO block control. The time to drain is a
simple function of size and sample rate.
We have been making improvements
Marcus,
Thanks for the info. Waiting is what we do now, but it's not ideal.
The "skip_dram=1"argument fixes the issue for low sample rates, but causes
underflows for higher sample rates, as expected.
Thanks,
Daniel
On Tue, Oct 30, 2018 at 10:25 AM Marcus D. Leech via USRP-users <
On Tue, Oct 30, 2018 at 11:25 AM Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:
> On 10/30/2018 10:42 AM, Daniel May via USRP-users wrote:
>
> Is there a way to query the amount of data in the FIFO so that I can wait
> until it clears?
>
> I don't believe so.
>
There's a
Is there a way to query the amount of data in the FIFO so that I can wait
until it clears?
On Tue, Oct 30, 2018 at 9:37 AM Rob Kossler wrote:
> The DRAM is 2GB, I think.
>
> On Tue, Oct 30, 2018 at 10:34 AM Daniel May wrote:
>
>> Thanks, I'll give that a try. I thought it might be the FIFO
The DRAM is 2GB, I think.
On Tue, Oct 30, 2018 at 10:34 AM Daniel May wrote:
> Thanks, I'll give that a try. I thought it might be the FIFO clearing, but
> it takes longer than I would expect. There's only 512kB of FIFO, correct?
> It takes up to several seconds to finish at a 1 Msps rate.
>
>
Thanks, I'll give that a try. I thought it might be the FIFO clearing, but
it takes longer than I would expect. There's only 512kB of FIFO, correct?
It takes up to several seconds to finish at a 1 Msps rate.
Restarting the radio before Tx completes causes the radio to enter an
unrecoverable error
It sounds like the DMA FIFO is just emptying out. For fast sample rates,
the FIFO empties quickly, but for slow sample rates, it empties slowly.
Perhaps you could supply the arg "skip_dram=1" so that the streaming goes
directly to the DUC rather than through the FIFO. This will probably work
All,
Can anyone else reproduce this issue and/or suggest a solution?
This is happening over the Ethernet interface as well. Application exits,
Tx light stays on, relaunching application causes X310 to enter an
unrecoverable state and requires power cycling. It looks like an issue with
All,
I am using an Ettus x310 over PCIe and am noticing that there is a delay
from when my program finished sending to the radio and when the radio tells
me that transmission as ended ( the red Tx light turning off).
As I bump up the sample rate I notice this delay decreases until it is
