Hysteresis in the receive path is negligible and you won't saturate anything if the RX2 antenna is disconnected. So just leave RX2 unconnected.
This statement assumes that you don't have a 1000 dB amplifier somewhere in the system. ; ) -John On Tue, Jun 4, 2013 at 5:42 PM, Miklos Maroti <mmar...@gmail.com> wrote: > Hi John, > > On Tue, Jun 4, 2013 at 7:38 PM, John Malsbury <john.malsb...@ettus.com> > wrote: > > Miklos, > > > > I'm not sure if what you're saying is correct. Switch U3 may not switch > to > > RX2 during tx in half-duplex operation. I would double check, but I > don't > > Thanks! What I have observed, that adding an antenna to the RX2 > connector does change the received samples during transmission, i.e. > it overdrives it more.Maybe I am mistaken somewhere, but would > appreciate if you would double check. From earlier discussions it > seems that ATR state machine controls this behavior, right? > > > think it matters either way. If this is a half-duplex application, you > > don't want to receive and transmit at the same time. So you should just > > ignore samples from the uhd_source, or mute them while tx is enabled. In > > this case, it doesn't matter what the RX path sees while it is switched > to > > the RX2 path. > > That is true, that I have to discard those samples anyways. However, I > am worried that overdriving the receive path during transmission would > have adverse effect on subsequent reception (few samples right after > the TX -> RX switch). Do you think that is a real concern? > > Miklos > > > > > -John > > > > > > > > On Tue, Jun 4, 2013 at 5:23 PM, Miklos Maroti <mmar...@math.u-szeged.hu> > > wrote: > >> > >> Hi John, > >> > >> Thanks for the excellent suggestion! It seems to work reliably with > >> 5ms buffering. I did not set the time of the FPGA, nor did I > >> synchronized the FPGA with the host. I just used the received sample > >> counter for all timings on the host to determine (the 5ms buffering) > >> when to send the samples to the board. > >> > >> One question: It seems to me that when the TX -> RX switch is done, > >> then actually the N210 will use the RX2 antenna instead of > >> disconnecting the RX channel completely from the TX/RX antenna. Is it > >> possible to force half duplex operation, i.e. to completely disconnect > >> the RX channel. Of course I woulds still see leakage through the > >> board, but maybe that will not overdrive the LNA. Any ideas? > >> > >> Miklos > >> > >> On Mon, Jun 3, 2013 at 7:59 PM, John Malsbury <john.malsb...@ettus.com> > >> wrote: > >> > " It'll switch to TX when it receives samples to send." > >> > > >> > There may be some small [intentional] delays, but the FPGA will switch > >> > to Tx > >> > on the first sample to be sent. Josh can specify the timing in more > >> > detail. > >> > > >> > You see "L" because you are sending your bursts far enough advance. > In > >> > my > >> > applications, the bursts are sent to the USRP about ~5ms before the > >> > actual > >> > transmission. And as far as I know you can't just use the fractional > >> > seconds. The FPGA won't switch to TX when it hits tx_time and starts > >> > clock > >> > out the samples. > >> > > >> > -John > >> > > >> > > >> > On Mon, Jun 3, 2013 at 4:59 PM, Miklos Maroti < > mmar...@math.u-szeged.hu> > >> > wrote: > >> >> > >> >> Hi John, > >> >> > >> >> Thanks for you quick reply, but you did not answer any of my > >> >> questions. Will the FPGA switch from TX to RX when it has already > >> >> received from the host a UDP packet with a timestamp tag (tx_time) > >> >> that is in the future? Also, when exactly will the RX to TX switch > >> >> occur? > >> >> > >> >> Miklos > >> >> > >> >> On Mon, Jun 3, 2013 at 6:14 PM, John Malsbury < > john.malsb...@ettus.com> > >> >> wrote: > >> >> > If you choose TX/RX as both your transmit and receive antenna, the > >> >> > FPGA > >> >> > will > >> >> > switch between TX and RX automatically. It'll switch to TX when it > >> >> > receives > >> >> > samples to send. > >> >> > > >> >> > -John > >> >> > > >> >> > > >> >> > On Mon, Jun 3, 2013 at 3:33 PM, Miklos Maroti <mmar...@gmail.com> > >> >> > wrote: > >> >> >> > >> >> >> 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
