discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] How Can I support full-duplex using SBX board whe


From: Alex Zhang
Subject: Re: [Discuss-gnuradio] How Can I support full-duplex using SBX board when running tunnel.py over OFDM?
Date: Tue, 1 May 2012 14:39:16 -0500

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 <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]