[USRP-users] X300 STREAM_MODE_NUM_SAMPS_AND_DONE length limitation
derek.kozel at ettus.com
Mon Oct 2 09:58:33 EDT 2017
That assertion is protecting a register in the Radio Block on the FPGA. You
could try modifying that area of the logic which is counting the outputted
samples as they are packetized. I do not believe that other areas of the
code would be impacted (other than that assertion in the host code of
While the continuous mode is less convenient when you need a very specific
number of samples it does not require very much helper code to receive any
arbitrary number of samples and flush any excess ones away. The overhead of
doing so is minimal when only done once every few seconds.
A related note to be aware of is that the num_samps value is actually at
the radio clock sample rate not the final sample rate, so if the DDC is
used to lower the sample rate then the maximum number of samples which can
be received with STREAM_MODE_NUM_SAMPS_AND_DONE is reduced by the
On Fri, Sep 29, 2017 at 7:53 AM, Vladimir via USRP-users <
usrp-users at lists.ettus.com> wrote:
> Trying to save more than 2 sec trace with X300 at Fsamp = 100MHz, I
> encounter some block length limit of 0x0fffffff = 268.4 MSamps, which means
> only 2.6 sec of time. A bit surprised to see this in 64-bit environment...
> The assertion is in module rx_vita_core_3000.cpp:
> UHD_ASSERT_THROW(stream_cmd.num_samps <= 0x0fffffff);
> Is this some physical limit, or it can be patched to a larger value? It's
> kind of inconvenient to solve this through continuous streaming when you
> need a trace of a certain length...
> USRP-users mailing list
> USRP-users at lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the USRP-users