[USRP-users] Error when receiving for a long period of time

Marcus D. Leech mleech at ripnet.com
Wed Jul 12 12:54:00 EDT 2017


On 07/12/2017 07:00 AM, Brais Ares via USRP-users wrote:
> Hello everyone,
>
> [USRP E310]
>
> We need to capture some 300 Hz signal for a long period of time (up to 
> 15'), as long as a GPIO is '1'. Minimum configurable bandwith is 286 
> KHz, what makes us sample the data at 286 KSPS. At this sampling rate, 
> every 15' of capture results in a file of 2.2 GB.
>
> The following error appears randomly, sometimes in the first capture, 
> some times after several sequencial captures, and the resulting 
> capture is flawed:
> /
> "Got an overflow indication. Please consider the following: Your write 
> medium must sustain a rate of *2.28 MB/s*. Dropped samples will not be 
> written to the file. Please modify this example for your purpose. This 
> message will not appear again."/
>
> Our "write medium" is a USB 2.0, that should support data rates well 
> above that one.
>
> I found the recommendation in this thread 
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2017-March/024178.html> 
> of configuring "NUM_SAMPS_AND_DONE" but in our case we don't know how 
> many samples have to be captured beforehand.
>
> Any recommendation?
>
> Regards,
> Brais.
>
>
I assume that you're using the rx_samples_to_file  example code? Or is 
this something you wrote yourself?

The rx_samples_to_file example code writes synchronously to the file 
system, so any brief pause while writing output data can cause overruns.
   This gets worse when writing to, for example, USB flash-memory 
sticks.   Also, the Linux kernel typically has a large write-behind 
buffer, and
   when it decides to commit this buffer to physical storage, your 
process can end up paused briefly while it does so.

Some of this can be compensated for by splitting your application into 
two threads--one that "harvests" data from the USRP, and the other that
   writes data to the file, with a managed buffer between the two 
threads.   This won't compensate for long-term disk throughput issues, 
but can
   be used to "soak up" brief pauses in writing files.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20170712/f25b1359/attachment-0002.html>


More information about the USRP-users mailing list