[USRP-users] x300 Timeout errors on receiving continuous stream (w/ Redhawk SDR)

Brian Padalino bpadalino at gmail.com
Thu Jul 2 15:10:15 EDT 2020

On Thu, Jul 2, 2020 at 3:02 PM Lawrence L Elentukh via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Hello,
> I am experiencing issues where the uhd::recv() function returns a series
> of unrecoverable timeout errors, I have seen similar questions on the
> mailing list but none that have been resolved or whose resolution helped
> me. The front end interfacing with the USRP connects to the device and runs
> using STREAM_MODE_START_CONTINUOUS, continually receiving samples. Then our
> codebase connects to it via redhawk's waveform connections and the redhawk
> usrp_uhd front-end pushes the samples received downstream to our receiver.
> The issue is that after a few runs of our code (which doesn't start or stop
> the stream from the redhawk frontend), I end up getting time-out errors
> from the uhd::recv() return code, and all subsequent attempts to receive
> samples see this error. Information about the system is as follows:
> USRP: x310
> Interface: 10GigE, with appropriate MTU and network memory configurations
> Sampling Rate: 200e6/6 (33.33MHz)
> Single channel Rx
> UHD Version: 3.15.LTS
> I am using the Redhawk SDR as a platform, with our own code base as a
> receiver, and am attempting to make changes to both my local copy of the
> redhawk-usrp_uhd front-end tuner component and our own code to resolve this
> issue, however all interactions with UHD are through the redhawk component
> (which can be found here:
> https://github.com/RedhawkSDR/USRP_UHD/blob/master/cpp/USRP_UHD.cpp#L1582)
> Things I have tried:
> * Starting/Stopping stream between receiver runs
> * Increasing receive timeout (up to 1 sec)
> * Resetting metadata between receives
> * Clearing buffers (dropping samples) when not running receiver
> Note: I am able to run the receiver without issue on the first few runs
> (for durations up to 20 minutes), however after 3-5 runs, all further runs
> end up reporting timeout errors.

This seemed to happen to me if I don't explicitly shut down the stream and
keep reading until I get timeouts or no samples received for all streams.

Does your application stop the reception of samples explicitly?  If so, do
you keep reading the samples until they timeout and return 0 samples?

Give that a shot and see if it helps.

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

More information about the USRP-users mailing list