If anyone will have fun with a little simpel Arduino projekt, this is maby something for you. It is far more simpel that the one which are shown in the ARRL book so here you dont need the big electronic skills....HAVE FUN .....http://skovholm.com/cwdecoder


Views: 5970

Reply to This

Replies to This Discussion

Nice project Hjalmar.  I converted one of my keyers (that already had the LCD interfaced to a ATmega328P chip) to try it out.

I used a "pure" sinewave sidetone from another keyer as the CW test source.  This is a preliminary test because I use a Hi-Per Mite filter on my sidetone, centered around 648 Hz.  So my output amplitude peaks near that QRG.  I can vary my tone from roughly 600 Hz to 750 Hz.  At 600 Hz, my output p-p level does not drop as low as at 750 Hz but neither 600 or 750 is optimum.  Neither is as close to your 558 Hz or 744 Hz frequencies, and I expect it will work even better when optimized and with a higher input amplitude.

With the "perfect" CW input from a test message sent by the keyboard, I have perfect decoding up to 30 wpm.  I need to optimize the tone frequency and level (at 600 Hz my input signal is only 1.6Vp-p) and see to what speed I have perfect decoding when the input is "perfect".

It will be very simple for others to download the software to an Arduino and have fun with your project.


Chuck, W5UXH

I migrated Hjalmar's project to a ChipKit Max 32 board (32-bit chip, 80 MHz clock).  I finally worked on auto speed tracking today so it now can track speeds from 10 WPM to 125 WPM  (my test source, a keyer/keyboard) only covers that range and I think it should be adequate :)  The test signal of course is "perfect", no QRN/QRM/QSB, so I am only testing the decoding and speed tracking under ideal conditions (except for the one off the air test mentioned below).

I still need to add automatic level control and support special characters like AS, BT, etc.  So far I am pleased with the performance.  I am sure I will have lots of features to slowly add and work on.

I suspect I should be able to add a keyer/keyboard in the same chip.  There is plenty memory, so it is just a matter of CPU time and I think there should be plenty of that also.  Most things are done in interrupt routines and even with the high sampling rate I am using, there is till lots of free time available.  I had been slowly working on migrating my keyer software from the 8-bit chips to the 32-bit chips, but got sidetracked by Hjalmar!  

I have only done one brief test with "off the air" signals, where I copied two bugs on 40M at around 25 wpm, and the W1AW/5 station at higher speed, but no more than 35 wpm since I did not have the speed tracking installed at that point.  I will probably work on ALC before going back to real signals, but I was surprised it worked as well with the one off the air test as it did.  I expect to record various signals / filter widths / band noise to have a good set of input signals to test with in the long term.

I do not have multiline scrolling on the LCD, I just used my existing software that only scrolls a single line.  I probably will also move to the ChipKit Uno32 and a Nokia 5110 tiny LCD (6 lines of 14 characters per line).  The current version uses a more expensive board (the Max32) because I already had it operating with the 4x20 LCD so that made a good platform for initial development.  The Uno32 does not cost much more than a typical Arduino like the Uno and Duemilanove.

By the way, the Uno32 is the board that TenTec uses in their new "open source" QRP rig, the "Rebel".  I have no idea how much free memory is available in the Rebel though.  The current version of this decoder uses about 75K bytes of memory (out of 512K bytes available).  I think I first looked at the ChipKit boards when I noticed it in the TenTec information.

The decoded CW is also sent to the serial port (the same USB interface that you use to download the program to the board).  So "unlimited" history of the text is available using a terminal emulator on a computer.

 For anyone interested in experimenting with "Arduino" for the first time, I recommend taking a look at the ChipKit boards.  I also recommend the IDE I am using.  It is UECIDE, and in my opinion is far better than the MPIDE (the ChipKit IDE that is just like the Arduino IDE).  It is likely if you are not that comfortable with this stuff, you might find UECIDE slightly more difficult to get going for the "Hello World" test (in the Arduino world this is actually the "Blink the LED" test).

Note that UECIDE can also be used with Arduino boards.

The image below is from this youtube video demo of the speed tracking:

Goertzel CW Decoder video demo

Other related links:

ChipKit Getting Started

One source of ChipKit boards



HI chuck


I am just so happy to see that my code did inspire somebody to develop futher on this decoder, and i am impressed how fast it can go with the chipkit board.

I just buy a board my self and will now try to use that board for the futher development.

I look forward to see the same video from a " on air" qso qrq and see if it so perfect as here.

Thats because noise is the big problem on air, to keep rid of so we can use a fine clear tone from the cw.

BUT because of the 80 mhz processor we can make a lot of more samples and then get the filter even better so i am pretty sure that it will do qrq fine on air also ..

keep on teh good work and please share with all of us ;o)

cuagn on the bands .. CW for ever ;o)



"I look forward to see the same video from a " on air" qso qrq and see if it so perfect as here."

It will never be that perfect!  The email I sent you with the off the air recording did have some band noise but the signal from Fred which was strong, and my lower amplitude sidetone (with band noise), decoded well (I think) except for the several QSB dips where Fred's signal went below my current thresholds.

I have no attempt to"filter" out noise spikes either.

So I look forward to you improving those areas! 

I need to experiment to see at what point a lower sample rate and/or larger number of samples start to degrade the QRQ decoding.  If such changes improve on the air performance and reduce the upper speed limit, then user options to trade off speed for conditions may be useful.

Chuck, W5UXH


© 2022   Created by Chuck aa0hw.   Powered by

Badges  |  Report an Issue  |  Terms of Service