CW (morse) decoder extension in KiwiSDR [added in v1.224]

edited September 2018 in Problems Now Fixed
Hi, I have been looking everywhere but there seems to be no "integrated" extension in KiwiSDR do decode CW transmissions... I found several video tutorials how to decode CW via virtual audio cable but building dedicated extension directly into the KiwiSDR would allow to decode CW on every web browser on any PC.
Is there any project to add CW decoder as an extension?


  • jksjks
    edited April 2018
    I have open source code for a CW decoder. But it is written is a newer version of Javascript called ES6 which is not yet widely compatible with all browsers (as far as I can tell). Converting it back to ES2015 is a pain because the guy made extensive use of ES6 OOP features. So there has been no progress on this project because of the time it would take.

  • What browsers are supported with the CW decoder? Maybe it is better to have something than nothing.
  • None. I wasn't going to take the time to create an extension that wouldn't work on an unknown percentage of the installed base. Better to invest the time in converting the package to ES2015 and be guaranteed success.

  • Perhaps this basic morse decoder on sourceforge is worth a look, however not as nice as the Javascript  ES6 decoder that John mentioned above.

    best regards, Ben

  • jks, you can use something like Babel ( to transpile code from ES6 to ES2015. This could be done one-time, or even better, in the Makefile as a build step that would compile it down.

    This looks basically a simple 3 step process to do it:

    Just requires wiring up npm, the package manager for node.js to fetch this.
  • I looked at Babel once. I immediately ran into trouble getting the required polyfill to work. I decided it would probably be less time to translate the package by hand. The code needs to re-factored anyway to be turned into an extension.
  • edited July 2018
    Do you have a link to said source code of the CW decoder? Just to take a look at babel issue.
    EDIT: Sorry, found it myself (at least the one benson mentioned):
  • edited July 2018
    ES2015 is the official name of ES6. You're looking for ES5, released back in 2009(!).

    Any reason to avoid those new JavaScript features, BTW? The vast majority of them are covered by way more than 90% of currently used browser versions.
  • Sorry about my incorrect use of the ES5/ES2015/ES6 terminology. I only learned about it a few months ago and found it very confusing.

    Trying to use more advanced Javascript and HTML/CSS/framework features with a large user base using a wide variety of browsers has been a problem. I added some contributed code sometime back. My email inbox started filling up because that code was using ES2015 "let" statements ("var" with different scope) that was failing on older browsers. Despite the fact that the feature compatibility charts on showed good availability.

    This situation is just as bad as when you have to include JS workarounds for early Internet Explorer versions. One of the many reasons I don't support IE at all!
  • I wouldn't support IE ... don't bother! You are at the cutting edge of tech .. force people to get up to speed :)
  • v1.224 has an early release of a CW decoder. Thanks to Martin, G8JNJ, for finding the open source code we used. Of course there are lots of missing features and the performance relative to other decoders is unknown. Limited testing indicates you need to use as small a bandwidth as possible (i.e. CWN mode) and anything else you can do to maximize the SNR. The decoder doesn't seem to perform very well on weak or fading signals. But this may be due to problems with our integration and not the decoder itself.
  • the extension does not always come up....
  • Hi John,

    Good job, it works surprisingly well, not quite as good as CW skimmer, but at least as good as some other (paid for) CW decoders I have tried.

    I think this new extension will be of interest to the 'Numbers' Station spotters.


    Martin - G8JNJ
  • It seems once I close the extension, it will not reload again. I have to close that browser session and restart another browser session to get it to work.

    73, Bob
  • CW decoders only seem to work on perfectly sent CW. Still it could be useful for some...
    Ron - KA7U
  • As others have already said, if you close and then try to reopen the CW decoder extension it seems to run but doesn't actually decode. A browser refresh is required before it will decode again.

    When it does run it's quite effective. I've been reading CW on the 60m (10MHz) amateur band without any major problems.


    Martin - G8JNJ
  • v1.225 fixes that problem.
  • It really doesn't work well for me. I gave it a pretty good test tonight. Mostly S-7 to S-9 signals, some hand sent and some machine sent. Decodes about 10% of the time. I refreshed and tried different browsers and stuff, but don't find it useful. It was all good code too. At least it was comfortable copy by ear. Sorry.
    Ron - KA7U
  • Hi Ron,

    None of the CW decoding programs I have tried are particularly good and will certainly not beat a proficient human decoder.

    However I think the new extension holds up well in comparison to some of the other reasonably well regarded offerings on the market such as CwGet and MultiPSK.

    Maybe when get some spare time I'll try performing a comparison.


    Martin - G8JNJ
  • edited September 2018
    HI , ok it seems to work... to many errors and too much time to read the decoded text,
    hence unusable...for now.
    To switch OFF the extension the web page must be reloaded loosing time.
    It is a young_extension and has a lot to learn ;-)
    I prefer much more CW_GET as it copies every strenght of signal and of course human_cw
    is very difficult to copy.
    attacehd is a 1to1 commparison on a S1 signal

  • To switch OFF the extension the web page must be reloaded loosing time. Can't you click on the 'X' icon at top right of the CW extension control panel? Also the escape key should close the current extension (and also help window). Neither help you on a small screen mobile device of course.

    Since the decoder code is not my own I'm not sure I can do much about it. I've noticed that its "training" time to determine wpm is longer than the periods during ham contest exchanges. And if it its error correction procedure fails it assumes the wpm has changed and restarts the training. This is not ideal. For ham rag chews or long-period utility transmissions where the signals are strong with little fading it seems to work fine. I've run some simultaneous comparisons against the decoder in fldigi which is marginally better for these cases.

    So there is good reason you pay for decoders targeted at the ham market. Those developers have invested considerable effort in optimizing their code.
  • further to the point of good decoders.... no commercial use of CW any more ... some special ops guy still use it when embedded but all manual, sometimes even keying an H-250 handset!
  • edited September 2018
    Hi All,

    I'm not quite sure what level of performance folks were expecting for 'free' ?

    It seems good enough to me. I can decode most morse signals reasonably well if they register >S4 on the signal strength meter, I suspect that CwGet performs slightly better because it has more user adjustments to play with.

    I've been experimenting with the KiWi extension and have found that selecting a narrow <50Hz CW bandwidth and then adjusting the AGC threshold for best results seems to be quite effective. Too low a threshold produces too much background noise and generates garbage like strings of EEEEEEEE and too high a level results in only decodes from very strong signals. A lot depends upon the noise floor of the KiWi in use. Reducing the AGC delay to 50ms also helps with fading signals.

    I suspect that some software tweaking of the level into the decoder may be required to optimise the extension. Maybe a simple graphical indication of the CW detection (slice) level could be provided to help fine tune reception.


    Martin - G8JNJ
  • v1.226 is out with some improvements:
    A "train" indicator that lights when cw speed training is active.
    Checkboxes for the threshold correction and word space correction options that were in the code. When threshold is checked signals around S3 are better decoded. A lot of times adjacent words are missing inter-word spacing. Changing the word space algorithm can improve that situation.
    The reset button will force the code to reinitialize and start over.

    I was wrong in my earlier comment about training. The dot and dash lengths during training are saved up. So once the wpm has been determined the dot/dash history is decoded at the computed wpm and you'll see a long burst of decoded characters appear. If the signal is strong enough (and the background level quiet enough so the total S/N is reasonable) then even contest traffic will decode.
  • edited September 2018
    OK, it is working reasonably well, quite well actually. Something definitely improved. I find it interesting that the decoder usually works ahead of the audio, so I'm reading it before I hear it. That is neat because it makes it easier to verify the decoder accuracy. Generally the decoder is accurate. a th that should have been a 6 is usually sent as a th, the sent code is at fault given the speed sent and spacing. So I change my mind, good decoder extension.

  • I'm seeing problems now where the audio will freeze (and the usual "audio underrun" messages appear) or, worse, the entire UI locks up. Looking more carefully at the code there are a number of places where they loop waiting for some condition. This is unacceptable in the Kiwi realtime environment and I need to fix those cases.
  • v1.227 should take care of it..
  • Hi John,

    Thanks for all your hard work.

    Unfortunately the v1.227 CW extension doesn't open on my iPad, the other extensions are OK, I suspect it's the same problem as previous times.


    Martin - G8JNJ
  • Okay. Reboot to get v1.228 which should fix it..
  • Whenever I change a Javascript file I now run it through a web validator ( which finds the problems ignored by the more permissive js interpreter in my browsers. This is supposed to prevent the "doesn't work on iPad" problem. Except of course when I forget to use it, lol.
Sign In or Register to comment.