half duplex set_auto_tx timing problems

Hi Ian,

Wow, thanks for the technical explanation! That makes a whole lot of
sense (see below for further questions).

On Mon, Jun 3, 2013 at 8:19 PM, Ian Buckley <address@hidden> wrote:
> Miklos,
> Here's a little bit more information about how the half-duplex operation 
> works from the H/W side.
> The verilog module "gpio_atr" contains 5 32bit configuration registers that 
> are programmed by the driver.
> This block connects to the radio daughter cards via the "io_rx" and "io_tx" 
> buses (which together have 32signals), and each daughter board uses theses 
> signals in a different way depending on the specific radio design.

Yes, I got this far in understanding the verilog code.

> One of the registers programs each of the 32signals to determine if they are 
> inputs or outputs from the FPGA.
> The remaining 4 registers contain the state that is driven out onto signals 
> (configured as outputs) in each of four states:
> IDLE, RX only, TX only, TX and RX. The current state is detemined from 
> inspection of the "run_rx" and "run_tx" signals that you will find in 
> u2plus_core.v.
> The state of these signals in turn is driven from UHD commands that are sent 
> from the host. When they are asserted then the respective DSP is enabled and 
> samples are delivered to/from the host.
> No switching of TX and RX data streams is done on the host to implement 
> half-duplex operation, the only switch is analog and very close to the TX/RX 
> antenna connection, and this switch is controlled by some of the GPIO bits I 
> have referred to.

Excellent! I will look into this.

> Internal to the FPGA "vita_time" which is a 64bit count of samples (100MHz on 
> N210) is used to schedule all DSP operation. When you send a TX stream 
> command with a time in the future, data is buffered in the FPGA ready to 
> start transmission, and when "vita_time" matches the time supplied with the 
> TX stream command, the "run_tx" signal is asserted causing both the DSP to 
> become enabled (and buffered data to be drawn into it), and also the 
> "gpio_atr" state machine to change state causing the analog RX/TX switch to 
> toggle. There is a delay of some 10's of clock cycles for data to pass 
> through the FPGA TX DSP logic and out to the DAC.
>
> Hope this is enough information to help you understand the code further.

Yup, this is what I needed. One more thing: is it true, that once we
make the switch I can still download packets from the FPGA to the HOST
in the RX channel continuously and undisturbed? If I do not use
tx_time at all, but listen while I transmit, then I will get back the
leaked transmission, so I know exactly how many samples off are the RX
channel with respect to the TX channel. Will the same happen with the
RX/TX switch scheduled with tx_time?

Best,
Miklos

> -Ian
>
>
>
>
>
>
> On Jun 3, 2013, at 5:50 PM, Miklos Maroti <address@hidden> wrote:
>
>> 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