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, <f...@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 > > > >