0
$\begingroup$

I am trying to decode Morse code from an audio (wav) file. Here is the technique I am using to detect the presence of the signal:

I have a window of size (sampling_freq/tone), where tone is the frequency of the Morse code tone, as determined by the fft (most prominent tone). I move this window across the entire recording, and for each window location, I detect if there is any signal above a user-defined threshold by checking the samples in that window (sample freq is 11025, tone is 981 Hz.)

This pretty much works, giving dots and dashes where they should appear. HOWEVER: these dots and dashes are not solid; if I zoom in, there are lots of empty spaces which make it difficult (impossible?) to determine where the real dots and dashes are.

How can I fix this, or is there a better approach?

EDIT: I am detecting where dots and dashes are as: when I detect a signal in the window, I make all the entries in a corresponding output array '1' for that same window.

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ If you downvote, it is generally useful to leave a comment. $\endgroup$
    – Ken - Enough about Monica
    Jul 24, 2014 at 8:25
  • $\begingroup$ Maybe some example, figure? $\endgroup$
    – jojeck ♦
    Jul 24, 2014 at 10:35
  • $\begingroup$ @jojek - What sort of example would be useful, figure? $\endgroup$
    – Ken - Enough about Monica
    Jul 24, 2014 at 13:41

2 Answers 2

Reset to default
0
$\begingroup$

Let's ignore the practical implementation and assume you have a pure sine : $$y = \sin(2\pi x)$$Now assume you shift your window somewhat: $$y=\sin(2\pi x' + \pi/2)$$

Clearly it's still the same signal, but a naive signal detector would find no signal when it should be present, and yet find a signal when there shouldn't be one. How naive is your detector?

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thanks for the input. In order to avoid this situation I make the window large enough to contain an entire alternation of the signal, and the sample rate >> 2f $\endgroup$
    – Ken - Enough about Monica
    Jul 24, 2014 at 14:29
  • 1
    $\begingroup$ @horsehair: Neither prevents this kind of phase problems. $\endgroup$
    – MSalters
    Jul 24, 2014 at 16:06
0
$\begingroup$

Some statistical analysis of your input signals may be in order. You need to determine how long an FFT window you need for the tone detection probability to be high enough for your reliability goals, as well as the statistics for the noise level to be low enough to differentiate between signal presence and false-positive noise registration.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.