> Date: Tue, 7 Jul 2020 17:00:08 +0000 > From: Lawrence L Elentukh > To: "[email protected]" <[email protected]> > 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. > _______________________________________________ USRP-users mailing list [email protected] http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
