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. 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? -- Alex, *Dreams can come true – just believe.*

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@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

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@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@lists.ettus.com > > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > _______________________________________________ > USRP-users mailing list > USRP-users@lists.ettus.com > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > -- Alex, *Dreams can come true – just believe.*