Introduction

W5UXH Version of OZ1JHM CW Decoder Project
Introduction


3 Mar 2015:  A few weeks ago I finally got inspired to pick up the software project again.  I got keyboard CW generation implemented, including kbd speed control in steps of 5 wpm with the up and down arrow keys.  I then got the EEPROM storage checked out but not implemented for user settings.  I then started a second breadboard that is larger, with the idea of switching to only using the 4x20 LCD for the combined keyer / decoder.  I now have decided to try to keep the software flexible so that at compile time, using a TargetHardware.h header file I can support either the Max32 or the Uno32 with either the Nokia LCD or the 4x20 LCD.  I probably will eventually start a new web page for the combined keyer + decoder where I should be able to provide some hardware details.  For anyone interested at this point, I can always provide the current schematics and software.  If I can keep up the interest in working on the project, possibly by summer I will have something fairly complete and stable.

2 Feb 2015:  I have not updated this page with any details yet.  I have built a prototype using a MAX32 board seen here:  MAX32 version  and a UNO32 version seen here: Uno32 version hardware (this is the video that shows the details of the prototype breadboard seen in the image above) and here:  Short demo showing the LCD display      One more demo of the UNO32 decoding, showing the output on a computer display instead of the LCD is seen here:  Longer demo showing output on computer display

I don't think it would be practical for anyone to try to duplicate my breadboard.  But the software along with the analog input buffer / limiter stage, depending on narrow band filtering in the receiver instead of in the software, should be reasonable for others to build.  I may never provide details here, but am happy to provide information to anyone who wants to play with a higher speed version of the decoder.

The input buffer circuit is shown here:  Input Buffer Stage

Originally I tested up to 125 wpm with clean decoding of a perfect input signal.  This was in the MAX32 prototype.  Recently I have noticed the max speed in the UNO32 version seems to be more like 100 wpm.  I have not looked into the reason, but it certainly is not important.  You will not find any on the air signals at such speeds!  Later I noticed I had intentionally ignored any measurements greater than 99 wpm as a crude "noise filter".  I then removed that limit, but now think I will go back to it so that I do not need more than a two digit field on the display.  Maybe I will limit keyer speed to 99 wpm also.

I have been intending to migrate my keyer / kbd software to the PIC32 environment, combined with the decoder and have not been able to get myself in gear to do serious work, so the current version remains as a decoder only implementation with a lot of pieces of the keyer in place but not yet taken to the point of generating CW.

Original comments:
16 Sept 2014:  For just over a week I have been playing with a project that originated from 
Hjalmar Skovholm Hansen, OZ1JHM.  He posted this link:  Hjalmar's Project describing his project using an Arduino board (I believe it is the Arduino Uno).  He uses an algorithm for "tone detection" that I was not aware of, the Goertzel algorithm.  I have worked with many FFT algorithms, but never this alternative for tone detection.  I found it quite interesting.

Hjalmar provided this link to a paper discussing the algorithm:  Kevin Banks Goertzel paper.  The link in this paper to the C++ listing did not work for me but a Google search found what I think is the same listing:  C++ Code Listing.  I installed Hjalmar's Arduino code and ran it on an Arduino Pro Mini that happened to be configured to interface to the standard 4x20 LCD used in his project.  It ran easily.

This project was of specific interest to me because I have recently been playing with ChipKit boards.  These are "Arduino like" but use 32-bit PIC processors running at 80 MHz, with much more memory and more timer resources.  I had thought I would like to try a FFT implementation of a CW decoder, and the Goertzel algorithm is far simpler and faster so Hjalmar's project got me going.  (Which means that two other projects with ChipKit boards are sitting on the sidelines now!)

Some related links:
Digilent:  One Source of the Uno32   (Note:  I am using a Max32, but will switch the Uno32 eventually, the Max32 already interfaced to a LCD so it was easy to use.)

The Uno32 price is currently $29.95 at Amazon Prime.  Orders from Digilent seem to have a high cost of shipping, and Microchip Direct Sales may also be on the high side.  So the ChipKit Uno32 will cost a bit more than an Arduino Uno or Duemilanove, but I believe they are well worth the difference considering the capabilities of the 32-bit PIC chips.


The ChipKit site will provide details for downloading an "Arduino like" IDE (Integrated Development Environment) that users of Arduino boards will be completely at home with.  I have never cared for the Arduino IDE.  But fortunately for me, at the start of working with ChipKit boards I was introduced to UECIDE and am very pleased that I did!  I highly recommend UECIDE to both ChipKit and Arduino board users.

My primary interest in a CW decoder is for demonstrations to people interested in CW.  But if I am going to play with decoders, I want them to handle QRQ speeds, preferably above 60 wpm, "just for the fun of it".  I expected the ChipKit boards would be capable of handling "QRQQ" speeds, and my tests thus far confirm this.  I am not concerned about the software being able to dig signals out of the noise.  I figure receivers can handle that for me, so my emphasis in the software is the spectral analysis (tone decoding) and CW decoding.

I will end this "Introduction" with a few comments about the current state of the software.  My current tests indicate that with a "perfect" computer generated input signal, I can decode from 10 WPM to 125 WPM (the current limits of my keyers).  This is way more than enough range.  I believe my equations for calculating the software timing parameters as a function of speed are working well.  I have not implemented automatic speed tracking implemented yet, but believe that should be pretty easy.  (Of course it will take far more work than I expect, it took two days to get my word space detection working when I thought it would be ten minutes!)

I did the first test with on the air signals today, using some recordings from the K3, all slow speeds (in the 25 wpm range) and some with bugs.  Because I do not have "noise filtering" and no automatic level threshold adjustment (ALC), I was not expecting it to work very well.  So I was pleased to find that it actually decoded better than expected.  I expect I will need some ALC eventually.  But for now, my primary interest is accurate decoding and speed tracking for strong signals.

I wanted to begin this web page mostly as a place holder for now, and I expect I will be cluttering it up in my usual fashion as the project proceeds.