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 course).
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 decimation factor. Regards, Derek On Fri, Sep 29, 2017 at 7:53 AM, Vladimir via USRP-users < usrp-users@lists.ettus.com> wrote: > Hello, > > 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... > > Vladimir > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
