discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: SNR calculations


From: Al Grant
Subject: Re: SNR calculations
Date: Mon, 1 Apr 2024 23:00:17 +1300

Hi Fons

I am detecting beeps on CW that happen about 1/second with a pulse length of 18ms. At a decimated sampling rate of 10240 this equates to 189 samples.

I found that after the smoothing filter (orange line) I could calculate the orange beep length and divide by 2 to get close to blue beep length.

The blue line as you guessed is after a filter and abs.

Al

On Mon, 1 Apr 2024, 22:21 Fons Adriaensen, <fons@linuxaudio.org> wrote:
On Mon, Apr 01, 2024 at 01:50:32PM +1300, Al Grant wrote:

> I have a block of code in my wildlife tracker that detects high/low beeps
> in a frequency.

It's not clear what the signal (blue trace in your png) actually
represents and what exactly you are trying to do.

- Detect any signal that exceeds the noise level by some margin ?

  In that case S/N ratio makes sense.

- Detect a signal at a particular frequency ?

  In that case S/N isn't relevant, S/No (signal to noise density
  ratio) is the relevant metric.

So until you provide a bit more detail, just a few comments.

I assume the signal (blue trace) is the absolute value or
square of something - it must be nonnegative for what you
do to make sense.

>  samples = signal.convolve(samples, [1]*189, 'same')/189

So you are convolving with a rectangular pulse in the time domain,
which becomes a sinc in the frequency domain. This is not a very
good choice. If you are convolving anyway (there may be simpler
solutions), better use a shape that transforms to a good lowpass
filter. This would be a truncated or windowed sinc in the time
domain.

> 189 is the number of expected samples

What do you mean by 'expected' ? Why 189 ?

> 1. Beep length calculations are off because of the extended
> length of "high samples"

Look at the points in your plot where the orange line intersects
the blue pulse. This happens at half the peak value of the orange
trace. A threshold at that level will give you a good estimate of
the pulse lenght.

> 2. SNR calculations are considerably higher (and I am not sure
> which SNR is "correct")

Which may be because S/N isn't the relevant parameter (see above).
You need to provide more details about what comes before (how
you get the blue signal).

Ciao,

--
FA




reply via email to

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