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?
Johnny On Mon, Oct 31, 2011 at 6:22 PM, Marcus D. Leech <[email protected]> wrote: > ** > On 10/31/2011 06:01 PM, Tuan (Johnny) Ta wrote: > > I have been running into problems using tunnel.py as well so instead of > creating a new post I thought I'll just continue this thread. > > My setting: > USRP2 > XCVR2450 > Ubuntu 10.04 (32bit) > > The problem I have is that after running tunnel, whenever I do ping, my > system gets stuck on the ARP exchange. Say A wants to ping B. A broadcasts > an ARP packet to find the MAC address of B's IP. B gets the ARP request, > immediately sends an ARP response back to A with its MAC. However, in my > system, A never gets the ARP reply. > > I seriously can't think of a reason for this. I can guess a possible > cause is that B sends the ARP reply too quickly that A doesn't have enough > time to go from transmit mode to receive mode (XCVR2450 is a half-duplex > daughterboard). But I don't know how to verify this hypothesis. > > Can anyone help me? > > Thank you, > Johnny > > > We used to have this problem "back in the day" with packet-radio, using > analog FM transceivers--they were often notoriously sluggish > in turning around the TX/RX logic. > > You might try zero-stuffing the TX frames--that's basically what we did > back in the day. Although the XCVR2450 short turn around fairly > quickly, it's not infinitely quick. > > > > > >> > > > > -- > Marcus Leech > Principal Investigator > Shirleys Bay Radio Astronomy Consortiumhttp://www.sbrac.org > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
