Re: [Discuss-gnuradio] half duplex set_auto_tx timing problems

[Ralph A. Schmid, dk5ras]

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: address@hidden
> [mailto:address@hidden On Behalf Of
> Miklos Maroti
> Sent: Tuesday, June 04, 2013 2:50 AM
> To: address@hidden
> 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
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio