discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] Update to FPGA code in trunk - Auto T/R timing delay


From: Johnathan Corgan
Subject: [Discuss-gnuradio] Update to FPGA code in trunk - Auto T/R timing delay
Date: Mon, 16 Apr 2007 15:40:19 -0700
User-agent: Thunderbird 1.5.0.10 (X11/20070306)

As of r5022 in the trunk there is a new capability added to the standard
build of the USRP FPGA code.  This allows someone (from Python) to
manually adjust the timing offset of the auto-transmit/receive switching
to better align with the transmitted data when using an external
transmit/receive switch.

In the previous code, the auto transmit/receive function would switch
based on whether or not there was data in the transmit FIFO of the FPGA.
Unfortunately, this would not take into account the pipeline delay of
the FPGA interpolator and AD9862 DAC up converter. Depending on the
interpolation ratio used in the transmit side, this could result in the
ATR switching signal going high up to 25 us early, and going low up to
35 us before the data was completely transmitted. If someone were using
a fast external Rx/Tx switch, this could result in slicing off the end
of a transmission.

The new capability adds an independent, configurable delay to the rising
and falling edges of the ATR signal, measured in clock ticks.  To use,
once one has already configured ATR operation as needed, one needs to
call two new daughterboard functions:

subdev.atr_set_tx_delay(clock_ticks_to_delay_tx) # Rising edge
subdev.atr_set_rx_delay(clock_ticks_to_delay_rx) # Falling edge

...where 'subdev' is the object created for the daughterboard in use.

Unfortunately, the best way *right now* to figure out what values to
poke in here are to measure the offset on an oscilloscope between the
onset of the ATR signal and the power output from the daughterboard.
We're working on a way to ask the FPGA itself what values should be set
(or even set these by default), but haven't worked out yet the best way
to do this.  Different external Rx/Tx switches have different needs so
there isn't a one size fits all.

Empirically measured, though, the pipeline delay through the USRP
transmit path is about 50 ticks + 3 ticks * interpolation rate. It seems
the falling edge needs somewhat longer than this to completely drop to
zero energy, and this may be data dependent, so again, the best course
is to measure with your particular application.

This capability will not be added to the release 3.0.x tree.

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com




reply via email to

[Prev in Thread] Current Thread [Next in Thread]