Dear all

I am looking for ideas for a software CW decoder with ASCII output.
There are a number of programs published - what algorithms do these use in
general?
I presume the software would have to have some sort of PLL to select and
filter a signal
and then an adaptive algorithm to allow for sending operator error in
keying, noise and variations in keying speed. I am looking for a solution
which trades off accuracy for minimum codespace and speed. If necessary,
some of the work could be done in hardware - eg I could limit and square up
the audio waveform and present it the processor as digital level
transitions, so AGC would not be an issue.
Any ideas?

Thanks in advance

Richard

On Tue, 30 Dec 2003 11:49:39 +0800, "Richard Hosking"
wrote:

I am looking for ideas for a software CW decoder with ASCII output.
There are a number of programs published - what algorithms do these use in
general?

There are two steps that you have complete: make a digital signal out
of the received analog output - and decode it.

Have a look at:
http://wwwhome.cs.utwente.nl/~ptdebo...algorithm.html

73s
OE1MWW
Wolfgang

On Tue, 30 Dec 2003 11:49:39 +0800, "Richard Hosking"
wrote:

I am looking for ideas for a software CW decoder with ASCII output.
There are a number of programs published - what algorithms do these use in
general?

There are two steps that you have complete: make a digital signal out
of the received analog output - and decode it.

Have a look at:
http://wwwhome.cs.utwente.nl/~ptdebo...algorithm.html

73s
OE1MWW
Wolfgang

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
though it might be somewhat hard to implement in a small/slow codespace such
as a microcontroller. (It may well be impossible to do this job in such a
device.)
Still I thought I would try.
Off the top of my head I thought I would start with a hard limited audio
signal, with transitions at digital hi/low level, rather than a sampled
signal. This would obviously limit the signal to noise ratio, but I was not
planning to use this for weak signal work. The clock/demodulation algorithm
would then deal with the timing between transitions of the signal, rather
than a spectral analysis. This would be relatively simple to implement with
a timer to count the interval between transitions. The controller could
track carrier freq with a Freq Locked Loop algorithm, over a limted
range.(say 600-900 Hz) If there are no transitions or randomly timed
transitions (noise), then the controller assumes a space Similarly, the
controller tracks sending speed by timing the length of dots and dashes, and
adjusting the algorithm to track this. This length could be initially
acquired by timing an initial series of dots/dashes. The length would
presumably fall into two groups, with the shorter length being dots. The
average of these shorter "on" periods would be the bit rate. The controller
could keep a moving average of the signal, discarding any "on" periods that
are longer than say 2.0 times the current average. Finally, I would use the
bit rate to time gaps (say) 2.5 times the bit rate to separate characters
and decode them with a simple lookup table.
No doubt there are lots of problems with this approach!
I would be interetsed in your comments

Richard


Wolfgang K. Meister wrote in message
...
On Tue, 30 Dec 2003 11:49:39 +0800, "Richard Hosking"
wrote:

I am looking for ideas for a software CW decoder with ASCII output.
There are a number of programs published - what algorithms do these use
in
general?

There are two steps that you have complete: make a digital signal out
of the received analog output - and decode it.

Have a look at:
http://wwwhome.cs.utwente.nl/~ptdebo...algorithm.html

73s
OE1MWW
Wolfgang

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
though it might be somewhat hard to implement in a small/slow codespace such
as a microcontroller. (It may well be impossible to do this job in such a
device.)
Still I thought I would try.
Off the top of my head I thought I would start with a hard limited audio
signal, with transitions at digital hi/low level, rather than a sampled
signal. This would obviously limit the signal to noise ratio, but I was not
planning to use this for weak signal work. The clock/demodulation algorithm
would then deal with the timing between transitions of the signal, rather
than a spectral analysis. This would be relatively simple to implement with
a timer to count the interval between transitions. The controller could
track carrier freq with a Freq Locked Loop algorithm, over a limted
range.(say 600-900 Hz) If there are no transitions or randomly timed
transitions (noise), then the controller assumes a space Similarly, the
controller tracks sending speed by timing the length of dots and dashes, and
adjusting the algorithm to track this. This length could be initially
acquired by timing an initial series of dots/dashes. The length would
presumably fall into two groups, with the shorter length being dots. The
average of these shorter "on" periods would be the bit rate. The controller
could keep a moving average of the signal, discarding any "on" periods that
are longer than say 2.0 times the current average. Finally, I would use the
bit rate to time gaps (say) 2.5 times the bit rate to separate characters
and decode them with a simple lookup table.
No doubt there are lots of problems with this approach!
I would be interetsed in your comments

Richard


Wolfgang K. Meister wrote in message
...
On Tue, 30 Dec 2003 11:49:39 +0800, "Richard Hosking"
wrote:

I am looking for ideas for a software CW decoder with ASCII output.
There are a number of programs published - what algorithms do these use
in
general?

There are two steps that you have complete: make a digital signal out
of the received analog output - and decode it.

Have a look at:
http://wwwhome.cs.utwente.nl/~ptdebo...algorithm.html

73s
OE1MWW
Wolfgang

On Tue, 30 Dec 2003 11:49:39 +0800, "Richard Hosking"
wrote:

If necessary,
some of the work could be done in hardware - eg I could limit and square up
the audio waveform and present it the processor as digital level
transitions, so AGC would not be an issue.
Any ideas?

Thanks in advance

Richard

Would also be interested, but have not experimented in this field
since I used the Apple II computer. Good decoding was a problem, but
also too often simple detectors were described. I did some experiments
with slide-back detector which was originally constructed for two-tone
RTTY (850Hz shift) and as such a good choice for single signal, but I
couldn't see much difference from the ATC network used for RTTY

Also had some good experience with MC1496, S042P similar detectors
instead of using envelope detectors

73
Jan-Martin
LA8AK
http://home.online.no/~la8ak/c11.htm
--
Amount of SPAM is so large that MailWasher must delete 99% of the incoming mails
Cannot check every email manually. Please use intelligent title for email.
Mails without titles or using just "hi" is deleted

On Tue, 30 Dec 2003 11:49:39 +0800, "Richard Hosking"
wrote:

If necessary,
some of the work could be done in hardware - eg I could limit and square up
the audio waveform and present it the processor as digital level
transitions, so AGC would not be an issue.
Any ideas?

Thanks in advance

Richard

Would also be interested, but have not experimented in this field
since I used the Apple II computer. Good decoding was a problem, but
also too often simple detectors were described. I did some experiments
with slide-back detector which was originally constructed for two-tone
RTTY (850Hz shift) and as such a good choice for single signal, but I
couldn't see much difference from the ATC network used for RTTY

Also had some good experience with MC1496, S042P similar detectors
instead of using envelope detectors

73
Jan-Martin
LA8AK
http://home.online.no/~la8ak/c11.htm
--
Amount of SPAM is so large that MailWasher must delete 99% of the incoming mails
Cannot check every email manually. Please use intelligent title for email.
Mails without titles or using just "hi" is deleted

"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
though it might be somewhat hard to implement in a small/slow codespace
such
as a microcontroller. (It may well be impossible to do this job in such a
device.)
Still I thought I would try.
Off the top of my head I thought I would start with a hard limited audio
signal, with transitions at digital hi/low level, rather than a sampled
signal. This would obviously limit the signal to noise ratio, but I was
not
planning to use this for weak signal work. The clock/demodulation
algorithm
would then deal with the timing between transitions of the signal, rather
than a spectral analysis. This would be relatively simple to implement
with
a timer to count the interval between transitions. The controller could
track carrier freq with a Freq Locked Loop algorithm, over a limted
range.(say 600-900 Hz) If there are no transitions or randomly timed
transitions (noise), then the controller assumes a space Similarly, the
controller tracks sending speed by timing the length of dots and dashes,
and
adjusting the algorithm to track this. This length could be initially
acquired by timing an initial series of dots/dashes. The length would
presumably fall into two groups, with the shorter length being dots. The
average of these shorter "on" periods would be the bit rate. The
controller
could keep a moving average of the signal, discarding any "on" periods
that
are longer than say 2.0 times the current average. Finally, I would use
the
bit rate to time gaps (say) 2.5 times the bit rate to separate characters
and decode them with a simple lookup table.
No doubt there are lots of problems with this approach!
I would be interetsed in your comments

Richard

Many years back, I built a TTL deocder from a QST article- by Petway??
Anyway he used a number of storage registers- one for average dot length,
one for average character spece length and one for average word space
length. After initialization, a clock would run at the receipt of each
element. The count was then compared to previous average- if the clock count
was larger, the average was incremented by 1; shorter, it was decremented by
1.
The machine did a surprisingly good job on hand sent Morse. Although the
hardware technology is antiquated by today's standards, the algorithm was
elegant and easily understood. I would estimate this article (2 or 3 parter)
appeared in QST from the early 70's.

GL,

Dale W4OP

"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
though it might be somewhat hard to implement in a small/slow codespace
such
as a microcontroller. (It may well be impossible to do this job in such a
device.)
Still I thought I would try.
Off the top of my head I thought I would start with a hard limited audio
signal, with transitions at digital hi/low level, rather than a sampled
signal. This would obviously limit the signal to noise ratio, but I was
not
planning to use this for weak signal work. The clock/demodulation
algorithm
would then deal with the timing between transitions of the signal, rather
than a spectral analysis. This would be relatively simple to implement
with
a timer to count the interval between transitions. The controller could
track carrier freq with a Freq Locked Loop algorithm, over a limted
range.(say 600-900 Hz) If there are no transitions or randomly timed
transitions (noise), then the controller assumes a space Similarly, the
controller tracks sending speed by timing the length of dots and dashes,
and
adjusting the algorithm to track this. This length could be initially
acquired by timing an initial series of dots/dashes. The length would
presumably fall into two groups, with the shorter length being dots. The
average of these shorter "on" periods would be the bit rate. The
controller
could keep a moving average of the signal, discarding any "on" periods
that
are longer than say 2.0 times the current average. Finally, I would use
the
bit rate to time gaps (say) 2.5 times the bit rate to separate characters
and decode them with a simple lookup table.
No doubt there are lots of problems with this approach!
I would be interetsed in your comments

Richard

Many years back, I built a TTL deocder from a QST article- by Petway??
Anyway he used a number of storage registers- one for average dot length,
one for average character spece length and one for average word space
length. After initialization, a clock would run at the receipt of each
element. The count was then compared to previous average- if the clock count
was larger, the average was incremented by 1; shorter, it was decremented by
1.
The machine did a surprisingly good job on hand sent Morse. Although the
hardware technology is antiquated by today's standards, the algorithm was
elegant and easily understood. I would estimate this article (2 or 3 parter)
appeared in QST from the early 70's.

GL,

Dale W4OP

On Tue, 30 Dec 2003 20:10:53 +0800, "Richard Hosking"
wrote:

Wolfgang
Thanks for your reply

Richard,

I will dig into my paper piles - I do have a very small and tiny Basic
source with a flow chart, published years ago. I wanted to write this,
but time went by and in the meantime ready built software is available
in the net. Stay tuned - I will post it.

73s and DX for 2004

Wolfgang
OE1MWW