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 _______________________________________________ Discuss-gnuradio mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
