Re: [Discuss-gnuradio] USRP2 / Tunnel.py packet reflection issue

[Tuan (Johnny) Ta]

Thanks for the explanation. I managed to get the system working by introducing a delay before every packet transmission. I know it's a hack but that's the quickest method I can think of. The minimum delay that I can get it to work is 11ms. It seems quite large. Is this reasonable for the turn-around time (from TX to RX) of the XCVR2450?

Johnny

On Mon, Oct 31, 2011 at 6:51 PM, Marcus D. Leech <address@hidden> wrote:

On 10/31/2011 06:40 PM, Tuan (Johnny) Ta wrote:

Marcus,

What do you mean my zero-stuffing the TX frames? And how would it help with the turn-around time of the XCVR2450 daughterboard? Do you mean I should transmit a zero-filled packet before any real packet, so that the receiving side (A in my scenario) has time to switch back to receiving before the real packet arrives?

The transmit side assumes that the combination of RX-to-TX and TX-to-RX transition experienced by both sides is non-zero.  So, you get
 the transmit side to simply send some idle 0s, and *then* the actual start-of-frame data, etc.  What happens in these situations in my experience
 is that the start-of-frame gets missed during the switchover interval.  So if the transmit side sends zeros (or, really, anything other than
 the start-of-frame sequence) for a "little while" after commencing a transmit burst, you're less likely to run into TX-to-RX transition issues.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org