Re: [Discuss-gnuradio] Auto T/R switching

[Eric Blossom]

On Wed, Jun 21, 2006 at 12:24:09AM -0400, David Scaperoth wrote:
> 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/address@hidden/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?

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 ;)

Good to hear from you!

> David Scaperoth

Eric