discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: Calculating SNR of an incoming signal


From: Johannes Demel
Subject: Re: Calculating SNR of an incoming signal
Date: Fri, 26 Jun 2020 17:14:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0

Hi Alex,

your cut-off frequency needs to be lower than half your sampling rate.
If your sampling rate is 61.44MHz, your maximum cut-off frequency can be 30.72MHz. And it should probably be a bit lower. You're working in baseband here. It is really important to understand the concepts of digital signal processing. That's also the reason I pointed out several resources.

SNR calculation itself is not always trivial. You need a way to distinguish samples that should only carry noise energy and those that should carry signal energy. Often people distinguish between SNR estimation for AWGN channels and for fading channels. While your estimator will probably not distinguish between the two, some estimators just fail for fading channels especially. For OFDM you might want to look into Schmidl&Cox preamble based SNR estimation. There might be an M2M4 estimator for symbol based SNR estimation.
What kind of system are you using?

Cheers
Johannes


On 26.06.20 15:49, Alex Batts wrote:
Right, because the filter cutoff frequency needs to be at least half the sampling rate, I figured I would not be able to use a filter since the bladeRF I will be using has a 61.44 MHz sampling rate and I will be operating in the GHz range.

What I will probably end up having to do is do a pre-run calibration where the tone is not playing, use a complex to mag^2 and average power combination, set that as a constant block, and then subtract the calibrated constant from the total power when the tone is on to get the most accurate possible signal power. While not ideal because it is not a truly live SNR calculation, it is the best workaround that avoids the filter I can think of.

If there are any other suggestions to get a more live/real time SNR calculation I am open to that as well.

Thank you for the help,

Alex



On Fri, Jun 26, 2020 at 4:17 AM Johannes Demel <demel@ant.uni-bremen.de <mailto:demel@ant.uni-bremen.de>> wrote:

    Hi Alex,

    "0 < fa <= sampling_rate/2" is correct and should always be
    enforced. If
    you try to set your filter cut-off frequency at >= samp_rate/2, you'll
    experience aliasing.

    After reading your mails, I get the impression you try to set your
    filter cut-off frequency at your carrier frequency $f_c$ + bandwidth/2
    $B/2$. Or something in that range. That won't work in baseband.
    Effectively, your signal at $f_c$ goes through a mixer and is shifted
    such that it would appear at $0$ in your baseband signal.

    There's a lot of digital signal processing fundamentals involved. I
    like
    the explanations given in [0]. Though, of course there are well known
    books such as the ones by Proakis or Sklar on the topic.

    Cheers
    Johannes

    [0] https://dspillustrations.com/pages/index.html

    On 25.06.20 22:22, Alex Batts wrote:
     > The effective noise bandwidth is part of the calculation. I'm
    using the
     > radar range equation.
     >
     > My purpose for including the bandwidth in my response was that
    any time
     > I try to use a filter with a frequency greater than my sampling
    rate/2 I
     > get an error returned. I agree that ideally I would use a band-pass
     > filter with very narrow cutoffs to best capture the signal in its
     > entirety, however, I can't because the frequency I'm trying to
    set my
     > filter at is more than half my sampling rate, giving me an error.
    Maybe
     > there is something askew with that error and it's something else,
    but it
     > returns saying 0 < fa <= sampling_rate/2
     >
     > On Thu, Jun 25, 2020 at 3:27 PM Marcus Müller <mueller@kit.edu
    <mailto:mueller@kit.edu>
     > <mailto:mueller@kit.edu <mailto:mueller@kit.edu>>> wrote:
     >
     >     Hi Alex,
     >
     >     On 25/06/2020 21.00, Alex Batts wrote:
     >      > I'm sampling an incoming signal, but only around 2 MSps.
     >      >
     >
     >     and that's fine! that's the *equivalent* baseband, it has all
    the same
     >     information as the RF signal.
     >
     >      > I need the signal power to noise power ratio at the
    receiver as
     >     part of
     >      > my range calculation.
     >
     >     Yes, but you'd always want to do that "signal to noise" only
    in the
     >     bandwidth that actually contains your tone; the rest will
    just contain
     >     more noise, interferers... to make your measurement worse.
     >
     >      > So I would need to be able to distinguish between
     >      > the power of the tone vs the power of the surrounding
    noise and use
     >      > those two numerical values in an equation to calculate the
    range.
     >
     >     You need to define "surrounding"! Your signal doesn't get
    worse by
     >     applying a filter that only selects your tone and as little
    else as
     >     possible. So you should do that – it makes your SNR better.
    Hence, your
     >     Signal power estimate gets more reliable (which you
    definitely want).
     >
     >     (that also highlights why I have a bit of doubt on your
    measurement
     >     methodology – if your SNR depends on receiver bandwidth, then
    how much
     >     does it actually tell you about the range, unless you specify the
     >     bandwidth alongside with it?)
     >
     >     Think about it: we typically assume noise to be white, i.e.
    to have
     >     identical power spectral density all over the spectrum, e.g. -170
     >     dBm/Hz.
     >
     >     Now, if your receiver bandwidth is set to 2 MHz (because
    that's what
     >     your SDR is probably configured to filter out if you ask for
    2 MS/s),
     >     then you get twice as much noise power than if you set the
    sampling
     >     rate
     >     to 1 MS/s.
     >
     >     It's the same thing that I always let students figure out by
    themselves
     >     the first time they use the lab spectrum analyzer:
     >     Feed a 2 GHz -60 dBm tone into the spectrum analyzer.
     >     Set the resolution bandwidth of the spectrum analyzer to 1
    MHz, and
     >     tell
     >     me what the SNR is. Now set the resolution bandwidth to 300
    kHz and
     >     tell
     >     me again.
     >     You get as much "N" in your SNR as you let through your
    system. In the
     >     case of the spectrum analyzer, every point on the display is
    the power
     >     in 1 MHz (or 300 kHz) of filter. In the case of your Qt plot,
    it's the
     >     power in a FFT bin. There's (f_sample)/(FFT length) bandwidth
    to each
     >     bin; so your graphical analysis hinges on the setting of
    sample rate
     >     and
     >     FFT length (also, on window choice and labeling, and software
     >     convention). Proportionally!
     >
     >     It's really hard to define "SNR" for 0-bandwidth, i.e. a
    single tone
     >     (having a single tone, actually, gets tricky physically, but
    there's a
     >     lot of people who could tell you more about oscillators than
    I could).
     >
     >     If you'd be fair, the only choice for the noise filter
    bandwidth would
     >     be 0 Hz, because if you chose any wider, you always get more
    noise. But
     >     in 0 Hz, there's actually 0 noise power! So, that doesn't work.
     >
     >     Instead, you need to define SNR exactly on the bandwidth your
    detection
     >     system will have to use. That's a design parameter you haven't
     >     mentioned
     >     so far!
     >
     >      > This
     >      > is why I referenced the green and red lines on the qt gui
    freq.
     >     display,
     >      > this would seem to give me signal strength in dB.
     >
     >     Hopefully, above explained how much these lines depend on your
     >     configuration and aren't "SNR".
     >
     >     Cheers,
     >     Marcus
     >




reply via email to

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