Auto T/R switching

so, I left out an important part of my e-mail…dang it…ignore the
previous e-mail ; )

I was looking through the gmsk2 code and I stumbled across this line
of code in the transmit_path.py file:

self.set_auto_tr(True) #enable Auto T/R switching

I wasn’t sure I understood what exactly that was doing, so I looked
for some archives:

http://www.archivum.info/[email protected]/2005-11/index.html

in this e-mail you said:

“It’s an optional feature that we plan to use with
a bunch of the daughterboards. Depending on whether there’s data in
the FPGA transmit fifo or not, specified daughterboard pins
automatically change state.”

So, are you saying that if the transmitter isn’t doing anything make
certain pins on the daughterboards will be switched to receive (to
allow more data to flow to the USB?), and if the transmitter is doing
something then the pins are switched back to transmit??? Is this
only for the RFX boards?

let me know if I’m on the right track. it sounds like its some
underlying function that doesn’t effect my work at the moment, but
its always good to have some idea of how the code you’re using works ; )

David S.

On Wed, Jun 21, 2006 at 12:24:09AM -0400, David S. wrote:

certain pins on the daughterboards will be switched to receive (to
allow more data to flow to the USB?), and if the transmitter is doing
something then the pins are switched back to transmit??? Is this
only for the RFX boards?

The feature is independent of the daughterboards.
The daughterboards that care (right now only the RFX boards), set it
up to enable or disable part of the Tx and RX RF paths depending on
whether or not there’s data to be transmitted in the FPGA fifo.
[Certain i/o pins on the RFX boards enable various pieces of h/w on
the d’boards]

Here’s the documentation of the feature (fgpa_regs_common.h):

//

// Automatic Transmit/Receive switching
//
// If automatic transmit/receive (ATR) switching is enabled in the
// FR_ATR_CTL register, the presence or absence of data in the FPGA
// transmit fifo selects between two sets of values for each of the 4
// banks of daughterboard i/o pins.
//
// Each daughterboard slot has 3 16-bit registers associated with it:
// FR_ATR_MASK_, FR_ATR_TXVAL_ and FR_ATR_RXVAL_*
//
// FR_ATR_MASK_{0,1,2,3}:
//
// These registers determine which of the daugherboard i/o pins are
// affected by ATR switching. If a bit in the mask is set, the
// corresponding i/o bit is controlled by ATR, else it’s output
// value comes from the normal i/o pin output register:
// FR_IO_{0,1,2,3}.
//
// FR_ATR_TXVAL_{0,1,2,3}:
// FR_ATR_RXVAL_{0,1,2,3}:
//
// If the Tx fifo contains data, then the bits from TXVAL that are
// selected by MASK are output. Otherwise, the bits from RXVAL that
// are selected by MASK are output.

#define FR_ATR_MASK_0 20 // slot 0
#define FR_ATR_TXVAL_0 21
#define FR_ATR_RXVAL_0 22

#define FR_ATR_MASK_1 23 // slot 1
#define FR_ATR_TXVAL_1 24
#define FR_ATR_RXVAL_1 25

#define FR_ATR_MASK_2 26 // slot 2
#define FR_ATR_TXVAL_2 27
#define FR_ATR_RXVAL_2 28

#define FR_ATR_MASK_3 29 // slot 3
#define FR_ATR_TXVAL_3 30
#define FR_ATR_RXVAL_3 31

For an example of setting it up, see gr-usrp/src/db_flexrf.py

db_base.py (same directory) provides these methods to set the
registers. db_base is the base class of all daughterboards.
Instances of it, or subclasses, are what’s contained in u.db[]

def set_atr_mask(self, v):
    """
    Set Auto T/R mask.
    """
    return self._u._write_fpga_reg(FR_ATR_MASK_0 + 3 * self._slot, 

v)

def set_atr_txval(self, v):
    """
    Set Auto T/R register value to be used when transmitting.
    """
    return self._u._write_fpga_reg(FR_ATR_TXVAL_0 + 3 * self._slot, 

v)

def set_atr_rxval(self, v):
    """
    Set Auto T/R register value to be used when receiving.
    """
    return self._u._write_fpga_reg(FR_ATR_RXVAL_0 + 3 * self._slot, 

v)

let me know if I’m on the right track. it sounds like its some
underlying function that doesn’t effect my work at the moment, but
its always good to have some idea of how the code you’re using works ; )

You’re on the right track :wink:

Good to hear from you!

David S.

Eric

On Fri, Jun 30, 2006 at 12:11:38PM -0400, Lee P. wrote:

fifo? Does it look for all zeros in the fifo, or does it have to do
with the a transmitter block returning -1?

None of the above. The FPGA fifo can tell you how full it is.

I’m trying to transmit from Tx/Rx and receive on Rx2. This is going
okay except the transmit data is being repeated over and over, even
after I return -1 from my transmitter block.

Eric

On Tue, 2006-06-20 at 22:51 -0700, Eric B. wrote:

[set_auto_tr()] is independent of the daughterboards.
The daughterboards that care (right now only the RFX boards), set it
up to enable or disable part of the Tx and RX RF paths depending on
whether or not there’s data to be transmitted in the FPGA fifo.
[Certain i/o pins on the RFX boards enable various pieces of h/w on
the d’boards]

How does it determine if there’s data to be transmitted in the FPGA
fifo? Does it look for all zeros in the fifo, or does it have to do
with the a transmitter block returning -1?

I’m trying to transmit from Tx/Rx and receive on Rx2. This is going
okay except the transmit data is being repeated over and over, even
after I return -1 from my transmitter block.

  • Lee

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs