Gain Range error

hi friends,
When I tried to print the Transmitter gain range by the following
commands,
The output is as followss,

[[email protected] digital]# python benchmark_tx.py -f 2412M
–show-tx-gain-range

gr_fir_fff: using SSE
Tx Gain Range: minimum = 0, maximum = 0, step size = 1

  1. Why is the gain Minimum and Maximum showing the same 0?
  2. How to control the transmit power ? Should I use the --amplitude
    command?
  3. can some one breif me on the controlling of transmitter power issue?

Thanks,
Amarnath

On 01/16/2010 01:36 AM, amarnath alapati wrote:

hi friends,
When I tried to print the Transmitter gain range by the following commands,
The output is as followss,

[[email protected] digital]# python benchmark_tx.py -f 2412M
–show-tx-gain-range

gr_fir_fff: using SSE
Tx Gain Range: minimum = 0, maximum = 0, step size = 1

  1. Why is the gain Minimum and Maximum showing the same 0?

The daughter board which you use, has no configurable transmit gain.

  1. How to control the transmit power ? Should I use the --amplitude command?

This is the amplitude of the digital samples going into the usrp2
device. You can use higher amplitudes, but be aware that if the
amplitude is too high, the samples will clip in the fpga dsp. The
maximum is 1.0 (this will clip).

  1. can some one breif me on the controlling of transmitter power issue?

Use a mix of digital signal amplitude and programmable hardware gain to
control the transmit power within the usrp. In this case of your
daughter board, there is no configurable hardware gain

-Josh

Just out of curiosity, was there a design decision made to not use the
DAC PGAs to adjust Tx gain?

On 01/16/2010 10:46 AM, Eric S. wrote:

Just out of curiosity, was there a design decision made to not use the
DAC PGAs to adjust Tx gain?

The issue is that changing the DAC PGA not only changes the differential
amplitude (which is what you want), it also changes the DC bias point
(i.e. the common-mode voltage). If you change the DC bias point outside
of a narrow range the upconverters don’t work as well.

The only daughterboards that really make any use of the DAC PGA settings
are the BasicTX and LFTX, which don’t have this issue with common mode
voltage.

Matt

On Sat, 2010-01-16 at 10:57 -0800, Matt E. wrote:

On 01/16/2010 10:46 AM, Eric S. wrote:

Just out of curiosity, was there a design decision made to not use the
DAC PGAs to adjust Tx gain?

The issue is that changing the DAC PGA not only changes the differential
amplitude (which is what you want), it also changes the DC bias point
(i.e. the common-mode voltage). If you change the DC bias point outside
of a narrow range the upconverters don’t work as well.

That makes sense. I don’t understand why the DAC would be designed to
have have the DC offset calibration affected by the PGA gain, but there
are a lot of things I don’t understand. :slight_smile: (IIRC, the datasheet seems
to imply that the the PGAs are suitable for use as transmitter power
control)

On a related note, I have spent some time recently trying to minimize Tx
distortion using an RFX1800 for the purpose of generating test and
measurement signals. I noted that there was non-negligible LO leakage
and related IM products, which were largely mitigated by using a large
LO offset.

I did however look into IQ DC offset and imbalance issues. Searching
the list archives showed several discussions about DC offset on the Rx
side, but little regarding the Tx side.

Instead of fiddling with the AD9862 registers directly, I made a simple
flowgraph that allowed me to adjust the IQ DC and gain components from a
sinusoid source and adjusted them while noting the LO and image levels
on a spectrum analyzer. The DC offsets and imbalance seemed nearly dead
on.

Is there any reason that my (pre-distortion) approach would not work, or
would give erroneous results? Some sort of DC leveling in the Tx signal
path somewhere?

Are Tx side DAC calibration values stored in the DB EEPROM like the Rx
ones?

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