Re: USRP push-to-talk?

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.” 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…

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 :wink:

Thanks!

David S.

On Mon, Nov 13, 2006 at 09:39:30PM -0500, [email protected] wrote:

u_tx = usrp_sink_c()
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 :wink:

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

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