Your assumption is correct: we are using an edited rx_samples_to_file code. I forgot to mention it.
We'll try thread-splitting and see how it goes. Thank you. Regards, Brais. 2017-07-12 18:54 GMT+02:00 Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com>: > 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. > > > > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > -- [image: logo_170x100px.png] <http://www.gradiant.org/> Brais Ares Fernández Investigador - Desarrollador | Área de Comunicaciones Avanzadas Researcher - Developer | Advanced Communications Department Ph. (+34) 986 120 430 Ext. 3019 ba...@gradiant.org | www.gradiant.org [image: Iconos Redes Sociales GRD Firma email-01] <https://www.facebook.com/GradiantNews/> [image: Iconos Redes Sociales GRD Firma email-02] <https://twitter.com/Gradiant> [image: Iconos Redes Sociales GRD Firma email-03] <https://www.linkedin.com/company-beta/769728> [image: Iconos Redes Sociales GRD Firma email-04] <https://www.youtube.com/user/ComunicacionGRD> Take care of the environment. Try not to print this email. The information contained in this email message may be confidential information, and may also be the subject of legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorized and prohibited. Please inform us immediately and destroy the email. Thank you for your cooperation.
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
