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 <mle...@ripnet.com> 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 > > >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
