Hi guys:
I noticed that in the adc_interface, there are registers called rssi_0,
rssi_1, rssi_2, and rssi_3. All of which are 32 bits. However, according
to the header format:
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb
The rssi should be 6 bits. Do I just use the lower 6 bits?
By the way, thanks for all the help we received on the burst problem. We
were able to fix the problem by using a logical analyzer.
Leo
On 8/7/07, Zhuocheng Y. [email protected] wrote:
Hi guys:
I noticed that in the adc_interface, there are registers called rssi_0, rssi_1, rssi_2, and rssi_3. All of which are 32 bits. However, according to the header format:
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb
The rssi should be 6 bits. Do I just use the lower 6 bits?
According to the instantiation:
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/sdr_lib/adc_interface.v#L43
The lower 16 bits has the RSSI value, and the upper 16 bits has the
over-count value.
If you were to just use 6 bits of the RSSI value, I’d recommend the
MSBs and not the LSBs.
Is this really the RSSI - or should the RSSI actually be a function of
the amount of gain or attenuation in the RF stages? I am sure it gets
pretty difficult calculating an estimate for the amount of power at
the antenna.
Should this value be an expression in dB of the received power?
Brian
Brian P. wrote:
Is this really the RSSI - or should the RSSI actually be a function of
the amount of gain or attenuation in the RF stages? I am sure it gets
pretty difficult calculating an estimate for the amount of power at
the antenna.
It’s a “digital RSSI” value, meaning it’s based on the output of the ADC
and not the true RF power at the antenna. Furthermore, it’s really a
single pole low pass averaging filter on the absolute value of the ADC
value, with no way to adjust the time constant.
You would have to use this value on the host, which has knowledge of the
daughterboard in use, gain settings, ADC configuration, etc., to
estimate the Rx power.
Should this value be an expression in dB of the received power?
That would be nice, but would require actually measuring this in the RF
front end using some sort of logarithmic amplifier or square law
detector. This has it’s own disadvantages as it diverts power from the
receive chain (and of course adds cost, power, complexity, and board
space.)
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com
On 8/7/07, Johnathan C. [email protected] wrote:
That would be nice, but would require actually measuring this in the RF
front end using some sort of logarithmic amplifier or square law
detector. This has it’s own disadvantages as it diverts power from the
receive chain (and of course adds cost, power, complexity, and board space.)
I haven’t taken a look at the daughterboards, but do they all use
different amplifiers and different numbers of stages? Are the
amplifiers setup in a linear or logarithmic mode? Do they change
significantly between the boards, or could a generic AGC module be
created?
Since the FPGA would control the values written to some AGC DAC, it
could be possible to calculate a pretty close estimate to the actual
RF RSSI without extra components. Is the gain just set once
currently? Does the FX2 write to the DAC, or is it within the FPGA?
Brian
Johnathan C. wrote:
change significantly between the boards, or could a generic AGC
(I haven’t looked into controlling the RFX board gain from the FPGA.
Matt is better to answer this one.)
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?
Doing the calculations on the FPGA would give us much tighter control,
this is kind of what I was tossing up for discussion in my carrier sense
thread. If the host does the RSSI calculation, there is a delay of
essentially a round trip to the USRP:
If we calculate the RSSI in the FPGA, we can mark a packet and specify
that we want to carrier sense before its transmission. The FPGA could
compute the RSSI, wait for the carrier to go below some threshold for a
given amount of time, and then toss the packet out or transmit.
Brian P. wrote:
I haven’t taken a look at the daughterboards, but do they all use
different amplifiers and different numbers of stages?
They are mostly different. All the RFX boards are similar, but the RFX
uses a different front end from the TVRX, DBSRX and the new boards still
in development.
Are the amplifiers setup in a linear or logarithmic mode? Do they
change significantly between the boards, or could a generic AGC
module be created?
I think you could create a generic “rx power estimator” module on the
FPGA that used the ADC output and some configuration registers that were
poked at by the host code when the daughterboards are configured. From
the host point of view this doesn’t add much value, as you could more
easily just do the same calculations on the host. If you need the value
as part of an AGC loop, though, obtaining it on the FPGA is needed for
tight control.
(I haven’t looked into controlling the RFX board gain from the FPGA.
Matt is better to answer this one.)
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com
George N. 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 C.
Corgan Enterprises LLC
http://corganenterprises.com
There are many forms of RSSI measurement between the daughterboards and
FPGA.
The RFX900, 1200, 1800, and 2400 (but not the 400) have analog RSSI
measurement at baseband. By reading one of the low speed ADCs in the
9862 you can get the signal level at baseband. To translate that to an
RF level at the antenna, you would need to know the current gain.
None of the other daughterboards has explicit RSSI measurement. That is
what the rssi.v block is for, to measure signal levels coming out of the
ADC.
Matt
Zhuocheng Y. wrote:
Hi guys:
I noticed that in the adc_interface, there are registers called rssi_0, rssi_1, rssi_2, and rssi_3. All of which are 32 bits. However, according to the header format:
http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/doc/inband-signaling-usb
The rssi should be 6 bits. Do I just use the lower 6 bits?
6 bits of RSSI is probably too little. At least 8, maybe 12 would be
better. In any case, you would need to process the 32 bits which are
computed in the rssi.v block into something smaller. For now you can
just send the high 6 bits of the rssi value.
Matt
On Thu, Aug 16, 2007 at 12:36:05PM -0400, George N. wrote:
- What exact information needs to be shared?
Some measure of the received signal strength.
- Where can we get the information? I’m assuming when the
daughterboards are initialized most of this information is available.
For the time being, assume that you are getting it from the “Post ADC”
rssi block, rssi.v. See also usrp_std.v (search for rssi).
- How exactly would you compute the RSSI in dB given this information
on the FPGA efficiently? Equation?
For now, don’t worry about getting it into dB on the FPGA.
The representation can be manipulated on the host.
Thanks!
George
Eric
Eric B. wrote:
For now, don’t worry about getting it into dB on the FPGA.
The representation can be manipulated on the host.
OK, so how do I get post-ADC rssi out of the USRP for any arbitrary
daughtercard?
My radio astronomy receiver could benefit from this, especially if the
RSSI is low-pass
filtered to some degree onboard the FPGA. Part of my host side stuff
computes
RSSI from the samples coming from the USRP (by squaring and low-pass
filtering).
I could probably save about 20% of my CPU load if I could get that
squaring, and at least
a first-stage low-pass filter done on the FPGA.
Okay, so I’m a little bit intimidated, I’m not too familiar at this
level.
So I’m going to ask for some help me through with baby step questions
We managed to get reading/writing to some unused registers working
through in-band C/S packets. So, we’re ready to use this code to pass
information from the host to FPGA about the daughterboard configuration.
We want to compute the RSSI in dB on the FPGA, we’re not even interested
in the FPGA responding back with the RSSI at this point.
What exact information needs to be shared?
Where can we get the information? I’m assuming when the
daughterboards are initialized most of this information is available.
How exactly would you compute the RSSI in dB given this information
on the FPGA efficiently? Equation?
Thanks!
George
George N. wrote:
We want to compute the RSSI in dB on the FPGA, we’re not even
interested in the FPGA responding back with the RSSI at this point.
Okay, but–why do you need units of dB? This is in the log domain, so
at some point on the FPGA you’ll need to take a logarithm of an
amplitude. If it is for the user’s benefit, then it is much simpler to
do the conversion on the host.
- What exact information needs to be shared?
The output of the ADC is a fixed multiple of the signal at the antenna
input. Since the gain settings are controlled by the host, the host
would need to calculate what the overall gain is and poke a register
with a value the FPGA logic could use.
Again, though, why do you need to get the actual RSSI? If you’re going
to use it for carrier-sense, then all you really need to do is threshold
the average magnitude of the ADC output. You’ve already got that value
calculated in rssi.v (perhaps that’s a confusing name for the Verilog
file.)
The only downside of rssi.v output is that the time constant for
averaging is fixed (to make the logic very simple, fast, and low-area.)
- Where can we get the information? I’m assuming when the
daughterboards are initialized most of this information is available.
It would be different for each daughterboard, but code could be added to
the host daughterboard handling code to determine the overall antenna to
ADC gain when the gain settings are set by the user. That overall gain
value would then be poked into a register on the FPGA to be used by your
code to get actual antenna power (assuming you still really need to do
this.)
Finally, for an AGC, the power measurement portion of the control loop
doesn’t need to be taken all the way to dB.
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com
Eric, we want feedback from you on this one
I think you’re right Jonathan, for performing carrier sense in the FPGA,
we really do not need it in dB. Calculating the average to determine a
threshold will get the job done with less the hassle. And right, if the
host really wants it in dB, it can do the conversion.
So here is what I want feedback on… how to communicate the RSSI to the
host. What we figure is that the host should determine the threshold,
in other words calculate the average and write it to a register that the
FPGA can read. This saves the floating point computation on the FPGA,
and the host can decide how many RSSI samples it wants to compute the
threshold on.
But, we’ve already determined that the 6-bits in the header are not
enough for properly reading the RSSI from the FPGA. So, what do we want
to do about this?
We can store the RSSI in a register and read from it using C/S packets,
then compute the average. This gives the full 32-bits.
However, I still think it would be useful for each packet to contain an
RSSI reading. I’m sure others would put use to this in the future. I
propose adding a 32-bit RSSI field to the packet header. This doesn’t
even incur 1% overhead, it’s ~.7% additional overhead per packet. Then
with the higher bandwidth of USRP2, it’s going to become even more
insignificant.
George N. wrote:
I think you’re right Jonathan, for performing carrier sense in the
FPGA, we really do not need it in dB. Calculating the average to
determine a threshold will get the job done with less the hassle.
You may want to implement two thresholds, one for rising power and one
for falling (hysteresis), to avoid “switch bounce” when the power is
right at the threshold.
…and the host can decide how many RSSI samples it wants to compute
the threshold on.
If you implement an FPGA block to calculate the trailing-“n” sample
average, you’ll need to use memory to store the samples in a ring
buffer. Much more efficient is to implement an exponential averager,
which only needs to keep track of the previous averager output. (This is
what the existing rssi.v does.) If the time constant (~16 us) is not
correct for what you need, you can either modify the hardcoded shift, or
implement a programmable shifter. That would at least let the user have
some selection from a small number of fixed values.
To make a completely generic one, you’d have to use two multipliers,
which the USRP1 doesn’t have (but the USRP2 will.)
–
Johnathan C.
Corgan Enterprises LLC
http://corganenterprises.com
PS. We have a hacked up version of carrier sense working right now
We’re just using the C/S read register method to get a couple RSSI
readings, computing an average, then writing the threshold to a register
on the FPGA.
The packets are then marked with a carrier sense flag, which we stole a
‘mbz’ bit for now, however we think that the ‘rssi’ bits in the first
word of the header should be reused as more bits for flags, so all of
the flags in the header are back to back.
Leo already hacked up the FPGA code, checks the RSSI value and the
threshold, and only transmits when the RSSI < threshold. We’ve verified
this over the air already 
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Sponsor our Newsletter | Privacy Policy | Terms of Service | Remote Ruby Jobs