discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Re: USRP push-to-talk?


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Re: USRP push-to-talk?
Date: Tue, 14 Nov 2006 19:34:56 -0800
User-agent: Mutt/1.5.9i

On Mon, Nov 13, 2006 at 09:39:30PM -0500, address@hidden wrote:
> all,
> 
> I am interested in controlling the USRP to do a half duplex operation: (when I
> say transmit, stop receiving, and when I say receive, stop transmit).  I have
> been reading about the output enable registers, and in a previous discussion,
> you suggested doing something like:
> 
> u_rx = usrp.source_c()
> u_rx.subdev = ...
> 
> u_tx = usrp_sink_c()
> u_tx.subdev = ...
> 
> and for a transmit only you might do: u_tx._write_oe(u_tx.subdev._which, 
> 0xffff,
> 0xffff)
> and likewise for the receive only.
> 
> I am nervous about this option after reading the in the comments: "Using this
> method incorrectly will kill your USRP motherboard and / or daughterboard." 
> I'm guessing that the way in which you have suggested above is sufficient, but
> are there some caviats that I should be aware of the would make me break the
> USRP?  Also, the first arguement in the _write_oe method is the "value" and 
> the
> second is the "mask".  I'm a bit confused as to  what is meant by the two.  
> are
> there ever cases where the "value" and the "mask" are different?  From the
> comments I know that value is "value to write into register" and mask is 
> "which
> bits of value to write into reg."

The value and mask are used to atomically change only a subset of the
bits in a control word.  If reg is the current state, then this is
what happens:

  reg = (reg & ~mask) | (value & mask)


> During default operation (or in auto
> switching), I'm guessing that the mask is changed to allow for flexible 
> changes
> in the data flow in Transmit and Receive (Am I close??).  Is it dangerous to
> write to the write_oe register often?? There may be times where it would be
> helpful for it to change from TX to RX to TX in under a second...

Just to back up a minute, what are you trying to do?
Are you controlling some external T/R switch?

Independent of all of that there are two controls for each i/o pin:

The output enable (which controls whether the bit is an output from
the FPGA or an input), and the value that's written to the pins.

Within a given application, you generally call _write_oe once,
and then control the value of the bits you care about by using
with write_io

  /*!
   * \brief Write direction register (output enables) for pins that go to 
daughterboard.
   *
   * \param which_dboard        [0,1] which d'board
   * \param value               value to write into register
   * \param mask                which bits of value to write into reg
   *
   * Each d'board has 16-bits of general purpose i/o.
   * Setting the bit makes it an output from the FPGA to the d'board.
   *
   * This register is initialized based on a value stored in the
   * d'board EEPROM.  In general, you shouldn't be using this routine
   * without a very good reason.  Using this method incorrectly will
   * kill your USRP motherboard and/or daughterboard.
   */
  bool _write_oe (int which_dboard, int value, int mask);

  /*!
   * \brief Write daughterboard i/o pin value
   *
   * \param which_dboard        [0,1] which d'board
   * \param value               value to write into register
   * \param mask                which bits of value to write into reg
   */
  bool write_io (int which_dboard, int value, int mask);



> Also, in a previous e-mail you suggested using Auto T/R in a push-to-talk 
> case. 
> Would this help in the situation where I want just a half-duplex system?  My
> understanding of the Auto T/R says no, but that doesn't mean that I'm right 
> ;-)

If you stall the transmit pipeline unless the user is pressing the PTT
button, then Auto T/R is what you want.  In that case, the receiver is
always running, but the transmitter is only producing output when it's
not stalled.

If Tom's around, check with him.  He and I talked about ways to do this.

Eric




reply via email to

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