Auxiliary ADC

GNU Radio
1

Hi,

is there a possibility to read the data coming from the auxiliary ADC
(AD7922)
at the moment? I couldn’t find any hint in the code or on the mailing
list
that could point me to a good direction to start.

Just out of interest: What should the auxiliary DAC (AD5623) be used
for?

Thanks a lot,

Cheers,

Christoph

2

On 01/19/2010 09:47 AM, Christoph T. wrote:

Hi,

is there a possibility to read the data coming from the auxiliary ADC (AD7922)
at the moment? I couldn’t find any hint in the code or on the mailing list
that could point me to a good direction to start.

Just out of interest: What should the auxiliary DAC (AD5623) be used for?

The aux ADCs can be read, and they are used with some of the
daughterboards to measure received signal level (RFX900-RFX2400) or
temperature (WBX).

The AUX DACs are used to set gains on most of the daughterboards.

Matt

3

Matt E. wrote:

Just out of interest: What should the auxiliary DAC (AD5623) be used for?
Discuss-gnuradio mailing list
[email protected]
Discuss-gnuradio Info Page

Hi,

is it possible to read the ADC value (before decimation/filtering) on
the
USRP1/DBSRX?

Ondrej

–
View this message in context:
http://old.nabble.com/Auxiliary-ADC-tp27229723p27230626.html
Sent from the GnuRadio mailing list archive at Nabble.com.

4

Hi,

is it possible to read the ADC value (before decimation/filtering) on the
USRP1/DBSRX?

The auxiliary ADCs are not decimated, so you can read them directly. To
read the normal high-speed ADC without decimation you will need to make
a custom FPGA image.

Matt

5

Thanks for your answer.

is the measuring also possible for the RXCV2450 or what is missing to
achieve it?

Yes, the XCVR2450 also has RSSI measurement capabilities.

Matt

The USRP1 uses the read_aux_adc function to get the values. Does the
read_gpio
replace it for the USRP2? If not how is the USRP2 accessing the aux ADC?

Cheers,

Christoph

6

Eric B. wrote:

mailing list that could point me to a good direction to start.

Does the firmware currently do anything with the Aux ADC? I see the
definitions for reading from the SPI controller, and the function
(firmware/lib/lsadc.c: lsadc_read_rx(int)) which appears to be the only
place that reads from the correct SPI device. Also, it looks like it
would be difficult to read the value directly from inside the FPGA: i.e.
if I wanted to use the RSSI value for an AGC or squelch control, I’d
probably be best served by periodically reading the value from within
the firmware, and pushing it back into a register in, e.g., dsp_rx_regs.
This would likely mean I’d have some additional inherent delay in using
the value in the DSP chain. Is there a better way - e.g. I assume it
would be possible to load the data from the SPI controller in the FPGA,
but does that come with a (much?) larger cost in terms of logic, and
therefore area/etc.?
Thanks,
Doug

–
Douglas G.
Code 5545
U.S. Naval Research Laboratory
Washington, DC 20375
(202) 767-9048
[email protected]

7

On Wed, Jan 20, 2010 at 07:20:43PM +0100, Christoph T. wrote:

for?

The USRP1 uses the read_aux_adc function to get the values. Does the read_gpio
replace it for the USRP2? If not how is the USRP2 accessing the aux ADC?

Cheers,
Christoph

At this point, firmware in the USRP2 controls the daughterboards, and
the read_aux_adc functionality is not exported to the host.

Eric

8

At this point, firmware in the USRP2 controls the daughterboards, and
Does the firmware currently do anything with the Aux ADC? I see the
but does that come with a (much?) larger cost in terms of logic, and
therefore area/etc.?
Thanks,
Doug

Hi,

I am interested in logging the RSSI on the host’s side. Therefore I am
looking
for a way to push the values from the firmware to the host. Does anybody
have
some insides how to access these registers (written with dsp_rx_regs
from
within the firmware like mentioned by Doug) from the host. I already
looked at
the read_gpio functions but got stucked, not knowing exactly if they can
provide the wanted functionality.

BR Christoph

9

On Fri, Jan 22, 2010 at 09:24:24AM -0500, Doug G. wrote:

At this point, firmware in the USRP2 controls the daughterboards, and
the read_aux_adc functionality is not exported to the host.

Eric

Hi Doug!

Does the firmware currently do anything with the Aux ADC? I see the
definitions for reading from the SPI controller, and the function
(firmware/lib/lsadc.c: lsadc_read_rx(int)) which appears to be the
only place that reads from the correct SPI device.

We confirmed that it worked :slight_smile:

Also, it looks
like it would be difficult to read the value directly from inside
the FPGA: i.e. if I wanted to use the RSSI value for an AGC or
squelch control, I’d probably be best served by periodically reading
the value from within the firmware, and pushing it back into a
register in, e.g., dsp_rx_regs. This would likely mean I’d have some
additional inherent delay in using the value in the DSP chain. Is
there a better way - e.g. I assume it would be possible to load the
data from the SPI controller in the FPGA, but does that come with a
(much?) larger cost in terms of logic, and therefore area/etc.?

There’s a plan/idea to implement closed loop AGC in the fabric of the
FPGA. Part of that would entail moving the relevant SPI signals off
of the wishbone peripheral and directly into the fabric. We would
probably run the loop at something in the neighborhood of 300kS/s to
1MS/s, corresponding to the usable bandwidth of the low-speed ADCs and
DACs.

To handle all the d’boards there are a few variations that need to be
dealt with. There are about 3 ways that the daughterboards control
the gain. There are about 2 ways to sense the RSSI of the incoming
signal. Some d’boards provide an analog signal we can read with the
low speed ADC, others have nothing, so we’d have to use the output of
the high-speed ADC to sense. We’d need to implement suitable
approximations of fixed point exp and log in the FPGA[1], then we need
a couple of different variations in the control loop depending on
whether or not the inputs and outputs are already in log form or not.
We’d also need registers to control the loop gain and reference set
point.

If you’re so inclined, please feel free to give it a shot. I know
that Matt, Tom R., Johnathan and I have all given this some
thought, and between us, we can probably help sort it out.

Thanks,
Doug

Eric

[1] “Elementary Functions: Algorithms and Implementation, 2nd Ed”,
Jean-Michel Muller