Re: [Discuss-gnuradio] rssi questions

[Johnathan Corgan]

George Nychis wrote:

> Thanks for all the responses and info on the RSSI.  I'm following most
> of it, but will probably have a bunch more questions the further we get
> in to it.
> 
> The reason we are poking at this is because we are interested in using
> it for carrier sense.  I agree that reporting it in terms of dB would be
> nice.  I guess theres a tradeoff here of complexity/power at the FPGA
> which we can discuss.  But you're saying that given information in
> registers from the daughterboard setup, it is possible?

How the power level gets reported to the host can be different from how
it is used in either an AGC loop or as a carrier sense/squelch block on
the FPGA.

The first thing to understand is that for a given hardware gain setting
of a daughterboard, there is a fixed, multiplicative relationship
between the RF amplitude and the ADC full scale output.  (In the log
domain, this becomes an additive relationship.)  You can determine one
from the other in either direction if you know the gain multiplier (or
log power additive constant).  In practice you'd have to measure this as
a calibration step and supply the conversion value as a configuration
register.  A suitable default could be based on a theoretical
calculation using the daughterboard design and configuration settings,
but manufacturing tolerances will cause this to be somewhat inaccurate.

But what you measure and use as a control value on the FPGA can be
manipulated on the host into whatever format (dBm, etc.) you want for
display; you don't need to worry about that at the FPGA.

The next thing to consider is how to measure the ADC output "power". The
RSSI block in the existing code implements an exponential averaging
filter on the absolute magnitude of the ADC output.  The "alpha"
multiplier for this filter is fixed at 2^-10.  This gives a time
constant of about 16 us.  A step change in the ADC output would result
in the measurement output reaching 63% of the change after one of these
periods.  Five time constants get you to 99%.

So you could threshold on this value to determine whether there is
sufficient signal magnitude to say "carrier-sensed."  To avoid "bounce"
you'd want to two thresholds to add hysteresis.

The limitation of the current rssi.v implementation is that the time
constant is fixed.  It could be too long or too short depending on what
it is being used for.  And some more advanced carrier-sense or squelch
algorithms alter the time constant to get different dynamics during open
or closed states.  The main reason it is fixed is this results in very
simple logic (shift by 10 bits and add vs. two multipliers.) So if you
want to implement a more complex algorithm you'll have a lot more area
involved.

Another factor to consider is that the signal, at the output of the ADC,
represents all the energy of the entire passband of the daughter card.
If your signal of interest is narrow band and you haven't implemented
external pre-filtering, then you're measuring energy from more than your
signal of interest.  This might be ok, but probably not.  You could put
the RSSI block after the DDC, which would help, but now your
relationship to real RF power vs. RSSI block output becomes complicated
by the decimation rate and DDC filter passband.

Next, if you want to use this value in an AGC feedback loop to control
hardware gain, there are further issues.  One is loop response time.
Can you measure, calculate a new gain value, reconfigure the hardware,
and track your signal fast enough to be useful?  For a digital comms
system, maybe you only need to do this during the packet preamble and
hold the gain constant for the duration of the data burst.

Gain control on the RFX boards is controlled mostly by the motherboard
AD9862 auxiliary DAC.  Normally, this is done on the host through the
SPI bus via the FX2 USB controller.  Implementing a SPI master on the
FPGA and sharing the lines with the FX2 master doesn't sound
straightforward, and might even require jumpering the SPI enable lines.

Perhaps the USRP2 design will make all this much simpler.

(Matt--please step in any minute now :-)

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com