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

[Miklos Maroti]

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