[Top][All Lists]

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

Re: Is there a Gnu Radio block to compute the power of a signal?

From: Rachida SAROUI
Subject: Re: Is there a Gnu Radio block to compute the power of a signal?
Date: Fri, 19 Nov 2021 11:45:46 +0100

Hello everyone,

I tried multiplying the signal with a complex conjugate of itself and then taking a moving average. The log10 is taken to convert to dB. I also used Probe signal and function signal to get my signal power value as a variable. Yet the value of my variable is not changing (it's always the default value). What did I do wrong? Can anyone help me please?

You will find my flowgraph attached.

Thank you all for your help.

Best regards

Le jeu. 18 nov. 2021 à 17:59, Marcus Müller <mueller@kit.edu> a écrit :
Hi Martin,

RSSI is "even worse", because it's not universally defined – some standards define it,
others don't, and what any given device displays as RSSI can be pretty arbitrary. For
example, IEEE802.11 (so, WLAN/wifi) does not say an RSSI is directly related to a received
power in watts.

4G/LTE introduces a whole set of signal quality metrics for the actual operation (not for
displaying), so that there's no single number to deal with. Which is fair - your phone
doesn't just do "one" transmission mode, it has several, with different modulation and
error correction schemes, and it makes a big difference whether a channel is mediocre
right now and expected to stay that way, or good but expected to vary a lot over time. So
a single number can't do the complex situation a receiver is in any justice, simply
because there's no single requirement: is it more important to the user that they can
download high speed bursts of website data, or that they have a relatively constant medium
streaming bandwidth, or a really highly guaranteed minimum data rate? What about latency?
What about power efficiency? All these are things that are different in "hardness" in
different scenarios.
In short: the bars at the top right of your phone screen, they're there for decoration,
are typically updated in a very slow/smoothed out manner, the same applies to information
like "signal strength -82 dB 60 asu" (phones literally say "asu", that stands for
"arbitrary strength unit", and while it *is* defined by standards, guess how consistent
phone implementations of something called "arbitrary" are).
Wireless mobile channels change a couple hundred times a second at modest speeds of
movement, to which the phone and network need to react; what would a human-visible
indicator even do with that much information?

Whenever I see an RSSI number, I interpret it as "An estimate of how well this receiver
will work in this RX scenario, measured in something that the developers found easy to
implement, and marketing thought it might appease the user hunting for best conditions".

That's not to say a received signal strength indicator is always useless – but it often
needs to come with a big footnote that defines what it actually tells you, and what "good"
RSSI actually means, operationally. Still, it's often a better idea to estimate e.g. the
"cleanliness" of your signal's constellation and call it RSSI than just looking at RX
power – for example, we're very often in interference-limited scenarios, so high RX power
is given through either the signal you want to receive – or the sum of signals you don't.

In that way, RSSI is "much better" than actual receive power: Your receiver doesn't
/actually/ work better due to a higher RX power, it works better with a higher SNR! So,
estimate the SNR from the signal you're receiving; then you get a ratio of "power in stuff
my receiver needs to know" to "power that disturbs my receiver", and that can be done
without external calibration.

Best regards,

On 18.11.21 13:48, Martin Spears wrote:
> This is good to know. After reading this I was going to ask a similar question about RSSI.
> I will look further into this as well
> Get Outlook for Android <https://aka.ms/AAb9ysg>
> ------------------------------------------------------------------------------------------
> *From:* Discuss-gnuradio <discuss-gnuradio-bounces+mspears=icmt.ca@gnu.org> on behalf of
> Marcus Müller <mmueller@gnuradio.org>
> *Sent:* Thursday, November 18, 2021 7:37:08 AM
> *To:* discuss-gnuradio@gnu.org <discuss-gnuradio@gnu.org>
> *Subject:* Re: Is there a Gnu Radio block to compute the power of a signal?
> That's almost certainly not an answer to the question you're posing, namely "How do I
> measure the power of a specific class of signals".
> A function probe is just a method of getting some data out of a flowgraph, and it's almost
> never the appropriate solution (function probes are really more for debugging, or very
> sporadically/randomly updated GUIs and such, not for signal processing).
> First of all, it's important to note that basically none of the SDRs you'd attach to GNU
> Radio come calibrated by default – so the numbers you see in GNU Radio are only
> proportional to some amplitude of electrical field. So, digital powers are only
> proportional to the powers on the air, but can easily be calculated taking the squared
> magnitude of your complex samples.
> Best regards,
> Marcus
> On 18.11.21 11:45, Rachida SAROUI wrote:
>> Thank you very much!
>> Le jeu. 18 nov. 2021 à 11:40, Van-Dung PHAM <dungdkt27@gmail.com
>> <mailto:dungdkt27@gmail.com <mailto:dungdkt27@gmail.com>>> a écrit :
>>     Hi, you can use the Function Probe in GNU Radio to measure the Power in dBm
>>     Vào Th 5, 18 thg 11, 2021 vào lúc 11:23 Rachida SAROUI <rachidasaroui@gmail.com
>>     <mailto:rachidasaroui@gmail.com <mailto:rachidasaroui@gmail.com>>> đã viết:
>>         Hello everyone,
>>         I'm looking for a gnuradio block or a method to determine the power of a received
>>         LORA signal from an arduino. Can anyone help me please?
>>         Thank you
>>     --
>>     -----------------------------------------------------------------------
>>     Van-Dung,PHAM

Attachment: RX_USRP.pdf
Description: Adobe PDF document

reply via email to

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