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 _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
