To elaborate more on my issue... I see the USRP2 send mac pause frames, and then no new data is sent over the interface for 5-10 seconds.
On Thu, Sep 23, 2010 at 2:46 AM, George Nychis <[email protected]> wrote: > Just saw this thread now... I'm seeing this problem with my USRP2s and the > WBX board. However, I'm not using UHD. Do you know a fix for this outside > of UHD? > > > On Tue, Sep 14, 2010 at 5:28 PM, Josh Blum <[email protected]> wrote: > >> FYI - in the future this will go away in the future when tx flow control >> becomes host-based (and away from ethernet pause frames). -Josh >> >> >> On 09/14/2010 01:56 PM, Marc Epard wrote: >> >>> I've been attempting to do a full duplex send/recv using UHD on a USRP2 >>> with an XCVR2450. >>> >>> The major problem I had was that issue_stream_cmd nearly always resulted >>> in a runtime error of "usrp2 no control response". It worked fine if I >>> transmitted w/o receiving or received w/o transmitting. The same code also >>> worked when using a 2nd USRP2 for receiving. >>> >>> After a session with Wireshark and the UHD host source, I had my "Well, >>> duh" moment. When you call send, the data starts streaming to the USRP2 >>> right away -- even if you specify a timestamp in the future. The USRP2 >>> starts sending back PAUSE frames almost immediately, which throttles not >>> only additional send data, but also any commands to the control port. >>> >>> The solution is to call issue_stream_cmd first (and start the recv >>> thread), then start the send thread. This was simple enough in my app >>> because I was specifying start times in the future anyway. It does prevent a >>> method I was going to use on a WBX where I start the send thread once and >>> scan through several receive frequencies before stoping the send thread. >>> >>> Perhaps most of you knew about this gotcha already, but I hope this will >>> help someone else who encounters the problem. Anyway, it was fun >>> investigating and I learned a lot more about the UHD host code and protocols >>> >>> -Marc >>> >>> >>> _______________________________________________ >>> Discuss-gnuradio mailing list >>> [email protected] >>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >>> >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
