How Can I support full-duplex using SBX board when running tunnel.py over OFDM?

GNU Radio
1

Hi,

SBX is the daughterboard which supports full-duplex, but when I run the
tunnel.py to do the Ping experiment over the OFDM communication link, I
found that the transmitter can receive a lot of packets which are
transmitted by itself. This causes failure for ARP query and the Ping
requests. I see in the forum, many friends meet the failure of
tunnel.py
because they are using the XCVR2450 which is half-duplex. But why I
still
have this tunnel.py failed even when I am using the full-duplex SBX?

Should I use different frequencies for the TX and RX in the same USRP?
Does
the SBX support the TDD based full-duplex?

–

Alex,
Dreams can come true just believe.

2

On 04/30/2012 08:09 AM, Alex Z. wrote:

Hi,

SBX is the daughterboard which supports full-duplex, but when I run the
tunnel.py to do the Ping experiment over the OFDM communication link, I
found that the transmitter can receive a lot of packets which are
transmitted by itself. This causes failure for ARP query and the Ping
requests. I see in the forum, many friends meet the failure of tunnel.py

I am a little surprised to find that there is a networking kind of
issue. I thought that any of these leakage packets would be discarded by
the network layer (because the IP source and destination would be
incorrect, etc…)

So, how do you think ARP is failing? Even if there is this “echo”
packet, a device should not be able to respond to an ARP request for an
IP address which is not its own. Are you setting different IP addresses?

because they are using the XCVR2450 which is half-duplex. But why I still
have this tunnel.py failed even when I am using the full-duplex SBX?

Should I use different frequencies for the TX and RX in the same USRP? Does
the SBX support the TDD based full-duplex?

So if the TX and RX frequency are the same, the receiver (which is
always running) will hear the transmission leakage. That makes sense.
What I think is missing from the tunnel.py example is that RX is not
muted during a TX.

Some recommendations:

  1. Use different frequencies for each communication channel.

  2. Or mute the RX stream when transmitting to avoid decoding leakage.

-Josh

3

Hi Josh,

Thanks for your attention.

I use the wireshark to monitor the ARP interaciton.

Suppos we have node 1 (192.168.200.1) and node 2 (192.168.200.2).
When Node1 initiates the ping request to node2, the ARP request is
broadcast to query who is 192.168.200.2.
At the node2, the ARP request is received by the tunnel device (gr0) and
it
does send back the ARP reply.
Unfortunately, the node1 rarely receive the ARP reply from the node2.

To avoid this ARP problem, I set the static MAC address for the tunnel
devices on both node1 and node2. Just note, the MAC address is set as a
fixed value when tunnel device is created.

Then node 2 can receive the ICMP request from node 1 and it does
response
with the ICMP reply.
However, similarly with the ARP case, the node 1 is very hard to receive
the ICMP reply from the node2.

So, I dump the received payload at the RX thread of node 1. Now I am
surprised to find that most of the payloads at node1 are actually the
content it send out to node 2. Only very small part of the replies from
node 2 can be received by node 1.

Thus, I only observe the ping can be successful very rarely.

On Mon, Apr 30, 2012 at 7:21 PM, Josh B. [email protected] wrote:

I am a little surprised to find that there is a networking kind of
issue. I thought that any of these leakage packets would be discarded by
the network layer (because the IP source and destination would be
incorrect, etc…)

So, how do you think ARP is failing? Even if there is this “echo”
packet, a device should not be able to respond to an ARP request for an
IP address which is not its own. Are you setting different IP addresses?

I did set different IP addresses for the two nodes.

So if the TX and RX frequency are the same, the receiver (which is
always running) will hear the transmission leakage. That makes sense.
What I think is missing from the tunnel.py example is that RX is not
muted during a TX.

Yes, the receiver hears itself. I don’t know why no other persons
complained for SBX when using tunnel.py. But I did find many guys
meeting
the same situation when using XCVR2450 daughter board as it is
half-duplex.
SBX is promising to be full-duplex. And I am sure I am using the SBX.

Some recommendations:

  1. Use different frequencies for each communication channel.

I will firstly try this option.

  1. 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?

-Josh

Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

–

Alex,
Dreams can come true just believe.

4
  1. 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:

  1. The access code is already configurable parameter. Simply use a
    different access code for each communication channel.

  2. It would also be possible to put some kind of other identifiable
    information into the packets. Use this information to discard unwanted
    packets.

-josh

5

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

I am in solving this problem, and will update you for anything new.

On Tue, May 1, 2012 at 11:02 AM, Josh B. [email protected] wrote:

are entering the send() function for a packet.
information into the packets. Use this information to discard unwanted
packets.

-josh

–

Alex,
Dreams can come true just believe.

6

On 05/01/2012 12:39 PM, Alex Z. 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. :slight_smile:

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

7

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 Z. [email protected]
wrote:

The first step is to use different frequencies for the TX and RX, but my

Alex,
Dreams can come true just believe.

–

Alex,
Dreams can come true just believe.