Disclaimer: I've never decoded morse in my life, so most of what I write is
educated guessing.

For my master's thesis I built a receiver that demodulated 400 baud MSK.
The RF chain delivered a signal centered around 2kHz to a 68HC11 which
sampled at 6400Hz and demodulated the data entirely in software -- and it
only had 2k bytes of code space. Granted, it was all in assembly, and it
used 94% of the available processor time to do it, but it did work. In
spite of having some really ugly compromises in the signal processing (the
sampling rate was really too low, and the only "multiply" was to add, not
add, or subtract from an accumulator) the receiver had performance within a
dB of the theoretical optimum. I think with something modern like an AVR or
a PIC a 16-baud OOK signal should be possible (fun, too).

OK, so you still have the problem with the math.

Consider using not one, but two comparators to square up your signal, so a
"non-signal" rarely gets above the threshold. You're back to needing AGC
(at least to set the comparator), but you can close the loop in your
software by looking at the comparator outputs for the right signatures (too
much output = too low threshold, too little output = too high threshold),
and set the threshold from the uP. With a good signal to noise ratio this
should have a nice broad center to it that'll be easy to find. With a good
narrow CW filter your signal to noise ratio will get better...

Once your threshold is set you can integrate the "buzz" from the comparators
to see if you're receiving a carrier. You should probably integrate for
some period of time (the length of the fastest code you want to receive
would be good, it'd give you a sorta-kinda-matched filter) and take the
presense of signal 1/2 of the time to indicate the transmitter is "on".

I like the idea of using the dibits to form a PLL, but for receiving bad
code at an unknown rate you'd probably be better off making a little
histogram of the on and off times of the code. You should be able to see
two peaks in the histogram for "on" corresponding to dot and dash, and three
for "off" corresponding to intra-letter, inter-letter and inter-word
spacing. At this point you can start looking for dashes, dots, and spaces
(maybe going back over your data to catch the beginning of the message, if
you have enough RAM) and decoding words. You could also estimate the speed
of the code that you're receiving and feed it back to your KSMF (that's
kinda-sorta-matched filter, of course) for better noise figure.

Once you have your stream of dashes, dots, inter-charater and inter-word
spaces you can separate the charaters, look them up in a table and just
reject anything that doesn't seem to fit. I suspect that your performance
would be pretty good at this point, and if not the theoretical ne-plus-ultra
of decoders it would be better at receiving the lousy senders than
Wofgang's.

"Richard Hosking" wrote in message
u...
Wolfgang
Thanks for your reply
I am not very sophisticated mathematically and I have not studied
communication theory. Your article is most helpful. However it looks as