The good news is that ping works much better when set the TX and RX at different frequencies.
On Tue, May 1, 2012 at 2:39 PM, Alex Zhang <[email protected]> wrote: > Hi Josh, > > Seems that you suggest to add work in network programming to avoid any > unwanted packets. > > My observations are that some the desired packets could be crashed by the > mixing of the leakage from the transmitter. So maybe I need some > fundamental solution on this problem, which means, how to remove the > leakage to achieve full-duplex. > > The first step is to use different frequencies for the TX and RX, but my > question is if it can be done by using only one antenna, connected to the > TX/RX port of SBX? > > Second option is to mute the RX when transmitting, using gr_mute block. I > am worrying if the software control command is fast enough to switch the TX > and RX for the SBX, as all the commands are exchanged with USRP by > ethernet. Is the mute/unmute command synchronized with the transmitting > process at the USRP? Hope you understand my question. :) > > I am in solving this problem, and will update you for anything new. > > On Tue, May 1, 2012 at 11:02 AM, Josh Blum <[email protected]> wrote: > >> >> > >> >> Some recommendations: >> >> >> >> 1) Use different frequencies for each communication channel. >> >> >> > >> > I will firstly try this option. >> > >> > >> >> >> >> 2) Or mute the RX stream when transmitting to avoid decoding leakage. >> >> >> > >> > Could you give some indications on how to mute the RX when it is >> > transmitting? Is it related to switching of the RX and TX of SBX? And do >> > you think it is fast enough if I do it in host based software? >> > >> > >> >> The simplest approach would be to call mute on a gr_mute block while you >> are entering the send() function for a packet. >> >> A more complicated approach would be to schedule the transmits with >> timestamps so you know exactly what recv samples to throw out. >> >> Thought of a few more: >> >> 3) The access code is already configurable parameter. Simply use a >> different access code for each communication channel. >> >> 4) It would also be possible to put some kind of other identifiable >> information into the packets. Use this information to discard unwanted >> packets. >> >> -josh >> > > > > -- > > Alex, > *Dreams can come true – just believe.* > > -- Alex, *Dreams can come true – just believe.*
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
