In a low power setup with a matched antenna using a circulator will to the job to combine RX and TX into one antenna...
Ralph. > -----Original Message----- > From: discuss-gnuradio-bounces+ralph=schmid....@gnu.org > [mailto:discuss-gnuradio-bounces+ralph=schmid....@gnu.org] On Behalf Of > Miklos Maroti > Sent: Tuesday, June 04, 2013 2:50 AM > To: discuss-gnuradio@gnu.org > Subject: Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems > > Hi Marcus, > > Thanks for the quick comments. Yes, I totally agree that using full duplex with > RX2 and TX/RX would be the ideal way to go, and as you say I can easily > ignore and synchronize with my own transmissions. The problem is that I am > required to use a single antenna, so I have to do a half duplex solution with > all its warts and synchronization problems. > > As for the switching time, I do not care if the switches (or the FPGA) > introduce deterministic delays, I can cope with that. > > You mention that the state machine is set up in the daughter card setup > driver. Is this the file in "host/lib/usrp/dboard/db_sbx_common.cpp" for the > SBX board? Is this code used for USRP2 and not only for USRP1? > > Best, > Miklos > > On Mon, Jun 3, 2013, Marcus Leech wrote: > > > > Some very quick comments. > > > > I don't think you're going to achieve nanosecond-scale TX/RX switching > > times, no matter how much you tweak the FPGA. The switches themselves > introduce, I'm estimating, a 50nsec delay all by themselves. > > > > In UHD, the ATR state machine is programmed during daughtercard setup > > by the "driver" for a given daughtercard -- this allows somewhat > > different behaviour for cards that are hardware-constrained to be > > half-duplex (like XCVR2450). In the daughtercard drivers, you'll see > > things > > like: > > > > this->get_iface()->set_atr_reg(dboard_iface::UNIT_TX, > > this->dboard_iface::ATR_REG_IDLE, band_sel | ad9515div | TX_DIS_TXIO); > > > > > > Which are setting up ATR registers. > > > > But that being said, I think you're best to run in a mode where you > > have a separate RX antenna if you require nanosecond-scale turnaround > times. You'll end up receiving your own transmissions, but that's fairly easy to > cope with, I imagine. > > > > If you setup to use (WBX example) RX2 for RX and TX/RX for TX, then > > there's no switching involved. You just have to ignore your own > transmissions. > > > >>> Hi Guys! > >>> > >>> I am trying to develop a half duplex application with N210 and SBX > >>> daughterboard with the latest (git head) gnuradio that needs precise > >>> TX/RX switching times (like in TDMA) in the order of a few samples > >>> (nanoseconds). I have played with the tx_time, tx_sob, tx_eob tags > >>> and they do not seem to solve the problem. My findings so far are: > >>> > >>> 1) tx_sob/tx_eob does not influence anything related to the TX/RX > >>> switch, it only controls the grouping of the TX data stream into UDP > >>> packets (tx_sob starts a new UDP packet, tx_eof pushes out the last > >>> UDP packet even if it is not full). The same is true for USRP1 but > >>> that uses USB packets. > >>> > >>> 2) tx_time is translated into the metadata_t struct in the host code > >>> and then it is translated into VITA packet time stamps (converts the > >>> fractional second part into sample numbers). The integer part of > >>> tx_time seems to be discarded, but I still get "L" (timestamp in the > >>> past error), so I do not understand why the FPGA will not wait a > >>> little if only the factional part is considered. > >>> > >>> 3) I have found this discussion online about TX/RX switch: > >>> > >>> http://lists.gnu.org/archive/html/discuss-gnuradio/2009-03/msg00034. > >>> html > >>> > >>> where Matt Ettus said that "The act of transmitting turns off the > >>> receiver, so no amount of software will ever change that." in > >>> discussing half duplex operation. Now it is not clear if that > >>> comment is also applicable to the N210 and SBX, and what does he > >>> mean by "the act of transmitting". Specifically, if I send a packet > >>> with tx_time in the future, does the FPGA switches to RX mode while it > is waiting? > >>> > >>> 4) We have looked up the FPGA code, and it seems that the timing is > >>> implemented in a short FIFO when handling the VITA UDP packets. I > >>> could not trace the code further, and I do not see the logic in the > >>> FPGA code that does the automatic switching between RX and TX. > Where > >>> is that implemented? > >>> > >>> 5) Is it true that to switch between RX and TX then the host has to > >>> issue a command (poke register) to update the appropriate pin on the > >>> FPGA? If so, then how can you time the update of that pin to > >>> specific sample numbers? > >>> > >>> 6) Is it true that the firmware soft core has nothing to do with the > >>> time sensitive data and control handling, so in particular the > >>> provided register access features (if I saw them correctly) are not > >>> used in timing sensitive paths? > >>> > >>> 7) It is not clear how the gnuradio UHD sink block handles the > >>> sample rate value in the presence of tx_time tags. For example, if I > >>> generate > >>> 10 small packets each of which has a tx_sob,tx_time and tx_eob and > >>> 0.1 sec delay between the times, and all of these small packets are > >>> put into the transmit fifo at once, then what happens? What is the > >>> rate that the UHD sink block will consume this data? It cannot be > >>> the sample rate, because these tags point to the future, so the > >>> consumption rate should be reduced, but is it what happens? Will the > >>> code switch the TX/RX switch to RX between the small packets if all > >>> those are already in the queue? > >>> > >>> I hope someone has answers to these questions. Searching the > >>> internet turned up next to nothing on these subjects. > >>> > >>> Miklos > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio