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

2dc1bd62e0e8db26726b5b28cdd9a2e2?d=identicon&s=25 Alex Zhang (Guest)
on 2012-04-30 17:11
(Received via mailing list)
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.*
D7c45fe2b9d1bc4156cebeb19a3a2b63?d=identicon&s=25 Josh Blum (Guest)
on 2012-05-01 02:22
(Received via mailing list)
On 04/30/2012 08:09 AM, Alex Zhang 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
2dc1bd62e0e8db26726b5b28cdd9a2e2?d=identicon&s=25 Alex Zhang (Guest)
on 2012-05-01 05:08
(Received via mailing list)
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 Blum <josh@ettus.com> 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.


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


>
> -Josh
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>



--

Alex,
*Dreams can come true  just believe.*
D7c45fe2b9d1bc4156cebeb19a3a2b63?d=identicon&s=25 Josh Blum (Guest)
on 2012-05-01 18:03
(Received via mailing list)
>> 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
2dc1bd62e0e8db26726b5b28cdd9a2e2?d=identicon&s=25 Alex Zhang (Guest)
on 2012-05-01 21:40
(Received via mailing list)
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 <josh@ettus.com> 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.*
2dc1bd62e0e8db26726b5b28cdd9a2e2?d=identicon&s=25 Alex Zhang (Guest)
on 2012-05-01 21:46
(Received via mailing list)
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 <cingular.alex@gmail.com>
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.*
D7c45fe2b9d1bc4156cebeb19a3a2b63?d=identicon&s=25 Josh Blum (Guest)
on 2012-05-04 11:24
(Received via mailing list)
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
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.