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