Re: Calculating SNR of an incoming signal

[Alex Batts]

Sorry for the delayed response. 

I do have info on the object I am tracking and can calculate the radar cross section. It is a model rocket that can most likely be estimated as a cylinder with small error between the two calculations.

The system as a whole will technically be active since we will also be sending out the sine wave and directing it, but the receiving SDR will not simultaneously be transmitting. It could technically be considered an active bistatic system, but since the receiving SDR is the only influence on range detection we were just going to consider it passive. We will be using the BladeRF 2.0 Micro xA9.

Yes, EO is electro-optical/a camera system.

Right now I am struggling to set up the equation for the range detection in gnuradio. There doesn't seem to be any support for inverse log functions or fractional exponents (or taking the exponent of a non-complex number). Since I am having to convert to mag^2 to calculate the power, I am working with floats. Is there a workaround for this that you know of, or is there an extension/add-on for gnuradio that extends it's mathematics capabilities?

Thank you,

Alex

On Mon, Jun 29, 2020 at 4:43 AM Johannes Demel <demel@ant.uni-bremen.de> wrote:

Hi Alex,

please keep this discussion on the mailing list. Thus, I included the
mailing list in this reply again.

Let's summarize your system
carrier frequency 5.8GHz
Radar ranging with reflection loss. Do you have any info on your
reflecting object? An objects radar cross-section may heavily influence
your results.
You stated, you'd work on a passive RF ranging system. The setup you
describe is active though. I'm curious how you'll convert this to a
passive system.

What's the signal structure you send? Is it just a sine? Is it random
QPSK symbols? What's your frontend's carrier frequency? Which SDR
frontend do you use? A USRP? A HackRF?

As long as your bandwidth definition together with your SNR definition
is sound, it might work to pre-calibrate your system. You might want to
do this periodically in case you'll run it for a longer time.

EO (Electro-Optical?)

Cheers
Johannes

On 26.06.20 18:01, Alex Batts wrote:
> Hello,
>
> Yes, I understand the Nyquist sampling theorem and my hardware
> limitations. That is why I assumed filtering would not work although I
> gave it a shot anyways. I am not trying to demodulate any baseband
> signal, rather I am going to be receiving a reflected signal at around
> 5.8 GHz and using that signal for range detection. The signal itself
> will not contain any information, but the strength of the signal is the
> information I need. However, I need a method for determining, or at
> least estimating, SNR because that is the key variable that will change
> throughout my experiment in the radar range equation and will ultimately
> be the deciding factor to determine how far away the object is. That was
> why I proposed doing a pre-trial calculation where my source is not
> transmitting to get the average noise power, and then set that as a
> constant block and subtract it in real time from my average total power
> with noise and signal both included. The constant block would then be
> updated prior to each run.
>
> A necessary part of the radar range equation is the transmit power from
> the source as well as the directivity. The SNR I'll be looking for is at
> the receiver. So the equation takes care of any signal attenuation.
>
> I'm building a passive RF range calculation system in conjunction with
> an EO object tracking system.
>
> Thank you,
>
> Alex
>
>
>
> On Fri, Jun 26, 2020 at 11:14 AM Johannes Demel <demel@ant.uni-bremen.de
> <mailto:demel@ant.uni-bremen.de>> wrote:
>
>     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>
>      > <mailto: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>>
>      >      > <mailto: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
>      >      >
>      >
>