[USRP-users] Problem of SBX board to support full-duplex communications.

Alex Zhang cingular.alex at gmail.com
Thu Jun 21 11:32:27 EDT 2012


Hi Josh,

After last time of discussion, I am using different frequencies for TX/RX
and no transmitting packets are bounded back to the transmitter.
The double-way communications succeed in most the cases, except when the
reply is sent to transmitter too fast, as described in  this main chain.
I add a delay for each reply and the communications works well, although
the throughput is not as expected.

This is also the other guy who complain the tunnel.py which fails in ARP
query, and I suggest him to add the delay and it works.
http://lists.gnu.org/archive/html/discuss-gnuradio/2012-06/msg00384.html

So I need to investigate where this delay comes from. Currently, I guess it
is needed by the switching from TX->RX. If so, it really confuses me as I
am using two different frequecies with different antennas.

On Thu, Jun 21, 2012 at 2:44 AM, Josh Blum <josh at ettus.com> wrote:

>
>
> On 06/20/2012 11:30 PM, Alex Zhang wrote:
> > Hi,
> >
> > As declared by SBX applications nodes, it supports full-duplex, which
> means
> > the transceiver can perform transmission and receiving at the same time.
> > However, within my application, I found the SBX is working as
> half-duplex,
> > even I set the antenna as RX2 for receiver, and TX/RX for transmitter.
> >
> > In my case, I am setting up a point to point link and try the double-way
> > communcations, i.e, A send a request to B, and B should send a reply back
> > to B.
> > The observed behavior is: B can only send the reply by a delay to ensure
> > the A receive this reply correctly. I am suspecting this is due to the
> > half-duplex
> > switching time at A. My test result shows that the B should delay 9ms
> after
> > it gets request from A and then the reply can be delivered to A safely.
> > Otherwise,
> > A can not receive this reply or the received packet fails in CRC check.
> > In GNURadio community, many guys complains the PING test fails, due to
> the
> > ARP query failure. I add the delay to the ARP reply and this PING test
> > passed.
>
> We had a similar discussion in April. It was working, no?
> http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg36636.html
> http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg36656.html
>
> > So I believe there is some problem in duplex, either caused by incorrect
> > setting or board issue.
> >
> > Is there anything I missed, to get the SBX board supporting full-duplex?
> >
> >
>
> Well, the tunnel.py is gnuradio's most infamous example...
>
> You might consider debugging the setup at a lower level. A simple flow
> graph in gnuradio-companion perhaps? Antennas are connected, power
> levels expected, frequencies expected etc.
>
> -josh
>
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > USRP-users at lists.ettus.com
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>



-- 

Alex,
*Dreams can come true – just believe.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120621/26253347/attachment-0002.html>


More information about the USRP-users mailing list