It is interesting to speculate whether or not, given enough effort on the

algorithms, a CW decoder could match the capability of the human ear/brain

of a competent CW operator.

Short answer: I don't think so, I've been working on the decoder for JackAl for the past three weeks. I can get 35wpm from W1AW without a hitch, but their code is "machine-sent"...it's a perfect 1-3-7. However, even with a keyer generating the CW atoms, each operator has his own "fist". Even W1AW is a little tricky because, above 18wpm, they switch to Farnsworth encoding, which messes with the 1-3-7 timing. Currently, I'm feeling pretty happy with 25-30wpm on a "real fist", and Al and I have the advantage that we already have FFT's in place. (The Goertzel algorithm you've probably heard about is really a one-bin FFT from an audio source.) Hans' encoder is about as good as I've seen, although the code by Hjalmar Skovholm Hansen, OZ1JHM, looks pretty good, too.

Truth be told, I'm probably spinning my wheels on this. Reason: The CW operators I admire most simply sit there, eyes closed, and read the code across the back of their eyelids...and can do it at better than 30wpm. That said, I think my code speed has increased about 5wpm just writing this stupid code and listening to the results. I find myself now hearing words rather than letters, so in that sense, this has been a wonderful, yet frustrating, experience. For learning reasons alone, we will probably keep the decoder in JackAl. However, someone who it really good at CW probably will never use it. As it stands now, this is what we have:

In this shot, we are listen for CW on 7.046 MHz (actually, W1AW, but the crystal wasn't calibrated yet) using the 300Hz filter, and the decoder is on (CODR is green) so the text is scrolling across the bottom.

In sum, decoding CW is not a trivial task, especially when it's a human on the other end. My guess is that, with enough memory and a fast enough µC you could probably copy very close to 100%, but maybe never get it perfect. If you do, please send me your code!

Jack, W8TEE

On Thursday, November 8, 2018, 5:26:38 AM EST, jmh6@... <jmh6@...> wrote:

Hi Hans and all,

  Ah. The holy grail of CW decoding. I bet it would make a good AI
problem for some 'smart' college types!

  John


On Thu, 8 Nov 2018, Hans Summers wrote:

> All
> FYI... the CW decoder in QCX tracks the speed it is hearing, and it tracks
> the amplitude as well. You cannot "set the speed of the decoder". The
> default start speed of the decoder is set to the Keyer speed at power up,
> and also whenever you press the key. So it should automatically start
> decoding your own keying instantly, because your keying and the decoder
> speed will match immediately. 
>
> When decoding a received signal it can take some symbols going by to lock
> on. If your sending speed matches the other station - which normally you
> should try to do - then the decoder speed will already match so it should be
> slick. 
>
> If you have your keyer speed set to the speed of the other station then it
> will lock on immediately; otherwise the decoder will start to measure the
> dits an dahs and take some symbols to be able to match the speed. 
>
> CW decoding could be a life's worth of work... the QCX decoder works pretty
> well and gets good feedback. 
>
> It is interesting to speculate whether or not, given enough effort on the
> algorithms, a CW decoder could match the capability of the human ear/brain
> of a competent CW operator. 
>
> 73 Hans G0UPL
> http://qrp-labs.com
>
> On Thu, Nov 8, 2018 at 12:38 AM Brian N <cl@...> wrote:
>      Seems to work best if speed is set to about the WPM of sending
>      station.  If you are trying to learn faster code and it is set
>      too slow, it won't decode real well.
>      Also, if you use practice mode, set the decoder to what your
>      keyer speed is set at (left button fast click).  Otherwise it
>      has trouble copying your own practice.
>
>      And the decoder volume seems to be dependent on the audio gain
>      control in some way too.  Seems that way.  Maybe i'm wrong on
>      this.
>
>
>
>