# RX-\>TX Switching delay on XCVR2400? **URL:** \ **Category:** GNU Radio\ **Created:** [February 3, 2012, 1:30pm UTC](https://www.ruby-forum.com/t/rx-tx-switching-delay-on-xcvr2400/216405 "2012-02-03T13:30:13Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\ **Post date:** [February 3, 2012, 1:30pm UTC](https://www.ruby-forum.com/t/rx-tx-switching-delay-on-xcvr2400/216405/1 "2012-02-03T13:30:13Z")
Trying out the tunnel.py example, we are transmitting a ping request between two USRP2s. The receiving USRP should respond immediately with a ping reply what the outpout is also saying. At all, this ping reply is not send. We can bypass this by deploying a time.sleep(0.05) at the RX-USRP before sending the ping reply (txpath.send\_pkt(payload)). Thus, the transmission is left behind for 50ms which is not very convenient. Is it because the hardware components have to settle and the tx/rx switching takes some time? Or might there be some configuration settings? A colleague of mine is supposing something about different transmitting mode like streaming and sending just bursts? Thanks a lot in advance, I really appreciate your help! ---
**Author:** ![Florian\_Schlembach](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/ecae2f/32.png) [@Florian\_Schlembach](https://www.ruby-forum.com/u/Florian_Schlembach)\ **Post date:** [February 3, 2012, 7:55pm UTC](https://www.ruby-forum.com/t/rx-tx-switching-delay-on-xcvr2400/216405/2 "2012-02-03T19:55:26Z")
Florian - Please don’t e-mail the same question to the list in multiple threads - it actually makes it more difficult for people to help you in a coherent manner. Switching between RX and TX on the XCVR daughterboard should have very minimal overhead - certainly not 6 ms. As soon as it sees the first TX packet, it should automatically switch. It is possible that tunnel.py is not properly closing the TX stream, and thus confusing the USRP. Your colleague might be on to something - have you looked through the tunnel.py source to see how it is handling the TX packets? Cheers, Ben On Fri, Feb 3, 2012 at 4:28 AM, Florian Schlembach \< ---
**Author:** ![Florian\_Schlembach](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/ecae2f/32.png) [@Florian\_Schlembach](https://www.ruby-forum.com/u/Florian_Schlembach)\ **Post date:** [February 3, 2012, 10:27pm UTC](https://www.ruby-forum.com/t/rx-tx-switching-delay-on-xcvr2400/216405/3 "2012-02-03T22:27:42Z")
> Please don’t e-mail the same question to the list in multiple threads - > it actually makes it more difficult for people to help you in a > coherent > manner. Sorry, I thought about to specify that a little bit more to make it findable more easily afterwards. > It is possible that tunnel.py is not properly closing the TX stream, > and > thus confusing the USRP. Your colleague might be on to something - > have > you looked through the tunnel.py source to see how it is handling the > TX > packets? Yes, we have already looked into it and were trying to point that out how to setup a “burst mode” in the source files in /gr-digital/lib/. Ultimately, we have not yet been successful. ---
**Author:** ![Florian\_Schlembach](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/f/ecae2f/32.png) [@Florian\_Schlembach](https://www.ruby-forum.com/u/Florian_Schlembach)\ **Post date:** [February 6, 2012, 1:58pm UTC](https://www.ruby-forum.com/t/rx-tx-switching-delay-on-xcvr2400/216405/4 "2012-02-06T13:58:03Z")
I found something on the mailinglist that there might also be SEND\_MODE\_ONE\_PACKET function beside the SEND\_MODE\_FULL\_BUFF but actually it affects nothing as I replace it in the gr\_uhd\_usrp\_sink.cc (after recompling etc.). In another thread it was mentioned that the transmitting buffer is not transmitted until it is full which is being done until the timeout time is elapsed. Does anybody have an idea how the waiting time could be skipped or this ONE\_PACKET mode could be set up correctly?