Re: [Discuss-gnuradio] How Can I support full-duplex using SBX board when running tunnel.py over OFDM?

[Josh Blum]

On 05/01/2012 12:39 PM, Alex Zhang wrote:
> Hi Josh,
> 
> Seems that you suggest to add work in network programming to avoid any
> unwanted packets.
> 

I was thinking before the network level. I guess the idea would be to
protect the network layer from getting "echo" packets. To reiterate:

access code - this is a parameter for the framer/deframer in gnuradio.
If you use a unique access code per channel, receiver cannot correlate
its own packets.

packet info - add info the existing packet header produced by the
framer. You can use a unique identifier (per channel) to identify and
reject echo 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?
> 

yes

> 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. :)
> 

So this mute (without careful timing) is a race condition, but: if you
are keeping up with the data rate (nothing is backing up into buffers).
Then it is hopeful that the mute window will overlap nicely with the
receiver's view of the echo'd packet.

Here is the list again:
0) frequency - lowest layer/separate bands
1) mute - lower layer/modulated samples
2) access code - medium layer/demodulated data
3) packet id - higher layer/deframed packets

-josh