[USRP-users] Overflows (D) when receiving nsamps more than once
Pope, Adrian P
adrian.p.pope at lmco.com
Sat Jul 15 16:56:53 EDT 2017
I am calling recv_to_file() multiple times, which in turn calls recv() multiple times. It is only consecutive calls to recv_to_file() that I see the overflow (D). As far as I can tell, the destruction of the rx_streamer object causes a sample to be left in the buffer.
After reading though other listserv postings, it seems that it's better practice and much faster to keep the streamer object alive for multiple collections as opposed to creating and destroying it each time. Now that I am doing that instead, the overflow is no longer an issue for me.
Still, why does this error occur when using my x310s but not when I run the same code using my B-series hardware?
Date: Sat, 15 Jul 2017 15:13:14 +0200
From: Marcus M?ller <marcus.mueller at ettus.com>
To: usrp-users at lists.ettus.com
Subject: Re: [USRP-users] Overflows (D) when receiving nsamps more
Message-ID: <21d13c13-f9b3-7e5b-fd2c-1ee124d04bd8 at ettus.com>
Content-Type: text/plain; charset="windows-1252"
in your modified version, are you calling recv() repeatedly, or are you
trying to get all the samples you want at once?
On 07/09/2017 02:34 AM, Pope, Adrian P via USRP-users wrote:
> I have several x310s equipped with TwinRxs, and I?m having an issue
> with consecutive receives using STREAM_MODE_NUM_SAMPS_AND_DONE.
> To illustrate my issue, I will refer to the uhd examples provided on
> github. I have built the original ?rx_samples_to_file? example and can
> run it with no problem. However, if I modify it by simply duplicating
> the ?recv_to_file? call or put it inside of a fore loop, I get an
> overflow (D) on every consecutive. I saw a previous post,
> ?/[USRP-users] Overflows when doing repeated captures with X300
> in which the same problem was reported, but there was some ambiguity
> as to whether the poster was using continuous or num samps and done
> mode. I USE THE ?NSAMPS? ARGUMENT AND NO ?DURATION? OR ?TIME? ARGUMENT.
> After some investigating it seems like a single packet is being left
> in the buffer. Can this be fixed? Or at least in the meantime, is
> there a way to avoid the delay that is caused by the out of order
> packet D overflow?
> Thanks in advanced!
More information about the USRP-users