Derek, Thanks for the reply!
When you say "try modifying that area of the logic", you refer to FPGA code (which I assume is related with rebuilding the firmware image)? Or to host side code where I can simply increase that assertion limit to some more bits (say to 0x7fff ffff) and see if it produces problems receiving samples? > 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. When (under what condition) should I notice the effect of this factor? Because now I use 200 MHz master clock and sample at 100 MSps rate, and I'm able to receive all 0x0fffffff samples which is the assertion limit. > 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. I understand that, still additional efforts are needed here. Eg, are there any example code on how to do this flushing correctly? Because rx_samples_to_file stops streaming just by Ctrl-C handler, without any additional actions. After I issued stop streaming cmd, how should I do such a flush operation? I mean I want to avoid waiting for any timeouts which will prolongate the overall input duration. If it's not possible without waiting for time out, then of which order this time out should be, to make it minimal? Vladimir >Понедельник, 2 октября 2017, 16:59 +03:00 от Derek Kozel ><derek.ko...@ettus.com>: > >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
