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

Andy Walls andy at silverblocksystems.net
Wed Jul 8 12:43:50 EDT 2020


> Date: Tue, 7 Jul 2020 17:00:08 +0000
> From: Lawrence L Elentukh 
> To: "usrp-users at lists.ettus.com" <usrp-users at lists.ettus.com>
> Subject: Re: [USRP-users] x300 Timeout errors on receiving continuous
> 	stream (w/ Redhawk SDR)
> 
> Hello,
> 
> Thank you for getting back to me. I implemented your suggestion;
> after stopping the stream I added a recv() to the service function
> that continues to receive while the usrp is stopped until it sees a
> timeout error. I can see that it stops, then tries to receive from
> the usrp and sees a single timeout error, as expected. Afterwards,
> issuing a start command works for a few runs, but again I encounter a
> series of timeout errors after a number of runs.
> 
> The stop command is issued as follows:
> > uhd::stream_cmd_t
> > stream_cmd_stop(uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS);
> > stream_cmd_stop.stream_now = false;
> > usrp_device_ptr->issue_stream_cmd(stream_cmd_stop,
> > frontend_tuner_status[tuner_id].tuner_number);
> 
> (The tuner id of all the start and stop commands, as well all timeout
> errors, is ?0?).
> 
> Is there anything else I can try?

When I had timeout problems with an X310, it was the Ethernet SFP
adapter that was the cause of the problem.  Low quality SFP adapters
can garble critical control packets.

Try using a Direct Attached Copper (DAC) cable, which eliminates the
SFPs as a potential problem, and see if the problem persists.

If the SFPs are indeed the problem, you should junk the ones you have
and buy better quality ones.

-Andy 


> Thanks,
> Lawrence
> 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.
> 





More information about the USRP-users mailing list