[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Measure the power using USRP

From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Measure the power using USRP
Date: Tue, 8 Dec 2015 12:17:03 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

To emphasize on what the other Marcus said:
GNU Radio only knows numbers, not physical units. The USRP delivers numbers, relative to full ADC range, to the computer. What these numbers represent depends on a lot of factors, most of which are in the analog domain and different for every device, every application etc.

Now, the USRPs and their daughterboards are pretty linear for a very large range of powers [1], so you can measure once with a signal source of known power (a standard), and derive a factor between "digital number power" and "physical receiver power" for a given frequency/bandwidth/gain/sample rate/antenna/... configuration, as long as the powers you observe don't leave the linear range (again, [1]).

Problem is: OFDM is notorious for having a large dynamic range due to its potentially high PAPR. Usually, you configure your receiver gain so that it gets a high signal power out of OFDM symbols that have a modest PAPR, because it's not as bad to lose a bit of precision with a symbol that has an extreme PAPR as to constantly have bad SNR. Now, for exactly these high-PAPR symbols, your receiver gets pushed into nonlinearity, and then your power estimate will be a little too low (if you're not really tricky about correcting that, but that would be very close to equalization based on data knowledge, and has little to do with receive strength).

So: get yourself a signal source of known power, connect it to your USRP, state very clearly what you use as a reference (makes a difference whether you incorporate antenna efficiency or not, for example), and run a quick calibration, then you'll have a factor between digital power and physical power. Be aware that for high digital powers, your physical power estimate is less exact.

Best regards,

[1] compare your daughterboard's data from http://files.ettus.com/performance_data/

On 08.12.2015 04:38, Marcus D. Leech wrote:
On 12/07/2015 10:25 PM, w xd wrote:

           What is the deviation between the result calculate by the formula and the result measured by the calibration source for the USRP N210?  For example,when I ues the formula:10*log10(var(x))+30 to calculate the power of the receiver data is -20dbm.What is the true range for the true result?

I can't tell you that, because there's the whole bit about:


The numbers you get out of the end of a Gnu Radio are (largely) linearly-proportional to the power as seen at the antenna inputs.
  The purpose of using an external calibration source is to determine what the proportionality constants are for each of your
  configurations of settings of frequency/bandwidth/gain/sample-rate.

The FFTs in Gnu Radio necessarily can only show dB relative to full-scale.  Gnu Radio has no way of knowing what those actually
  correspond to in terms of power as seen at the antenna terminals.

2015-12-08 10:53 GMT+08:00 Marcus D. Leech <address@hidden>:
On 12/07/2015 09:34 PM, w xd wrote:
    I want to measure the power.I'm now transmit the OFDM signal.

    I use the usrp to receive data,and I save it to a file.I read all the data.Then:
I use the formula to calculate the power:
    10*log10(sum(abs(data).^2)/0.001)   dbm
    Is it the right way to calculate the power under the ofdm?

Best Regards,
z sw

Instantaneous signal power is proportional to:


You can average that to whatever interval you want, and then scale (perhaps converting into dB, as above).  But to determine *absolute*
  power at the antenna terminals you'll need a known calibration source or two, and use that to come up with calibration constants for
  your particular setup of frequency/gain/bandwidth/sample-rate.

Discuss-gnuradio mailing list

Discuss-gnuradio mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]