21 Jan 2017:
NOTE:  I am leaving this site in place but this is no longer the primary site for the current generation of keyers.  See this site instead:  More current site

16 Mar 2016:  Just a reminder, in case I have not mentioned this elsewhere.  The "decoder" is a fun addition to demonstrate the capability of the ChipKit boards (32 bit processor, 80 MHz clock, lots of memory and chip resources etc.).  One would not want to depend on a decoder for CW operation, but they can be useful for demonstrating CW to non hams or non-CW hams. 

I do keep it running over the serial port so I can check back through the "history" of iCW QSOs, but since the keyer LCD display is right in front of me when operating, I keep the LCD display of the decoder output off, particularly for QRQ QSOs because I find it too distracting.
Also, the decoder works nearly perfect to my artificial limit of 100 WPM on iCW.  For actual use on HF, I have briefly tested while in a daily QRQ HF sked and as long as the signal is strong with little QSB and QRM, I think it possibly works as well as other ones I have heard of.  I have tried to compare it to the K3 built in decoder that I had never looked at and think on a given signal, it compared well to the K3, but possibly I do not know how to use the K3 decoder.  But the rig must provide the filtering, the algorithm I use does not provide any filtering.  I trade off speed for filtering.

But no one should decide they want to try to duplicate this version in order to have a decoder, I do not suggest it would be good for general use on the bands!  I only suggest it can be fun to experiment with.

24 May 2015:  This is another in a long line of "final" keyer projects.  Will it never end?  (NOTE:  I am beginning this web page in preparation for eventual documentation of the project, but initially it is mostly a place holder.)

This is the Keyer + KBD + Decoder Project
Front view (breadboard)                              Bottom view (PCB Prototype #1)             Top view (PCB Prototype #1)
(Click on photos for full size views)

The original breadboard version is shown on the left.  This was built on perfboard.  The other two photos are the first prototype built up on one of the PCBs from ExpressPCB.  It is in a scrap enclosure.  I am waiting for a new order of precut acrylic panels and will move the internals to a new enclosure when I have one built.
13 Aug 2015:  Oops:  I just learned that the ChipKit Uno32 is being discontinued.  There is an excellent chance that the uC32 is totally compatible and I only need to include it as a target when compiling.  I need to determine if this is the case.  The uC32 has more memory, so if it is easy to target it and plug it into the PCB, that will be good.  I will update this when I know more about it.

27 Sept 2015:  I thought I had added an earlier note mentioning a random crash event that had been happening, but I do not find it.  There was a problem where it sometimes crashed once or twice in an hour while in qso.  A few weeks ago I tried something involving the interrupt handler for the PS-2 input and I now have confidence that this has eliminated that problem.  This is not say a crash is not possible.  The PIC32 and MPIDE/UECIDE environment provides a "core" that is not an OS but it does add a level of complexity to the software, with many interrupts running for both the keyer application itself and the core.  So I tend to feel there is more chance of rare events that might cause a crash and be very difficult to debug.  Since the software seems to be working "perfectly" at the moment, I will upload the most recent archive of the project to the software page.
Note:  I have been working on the "eBook mode" in the PICadillo (see comments on this board below).  So most of the software work in the past few weeks has been tested only in the PICadillo.  The latest version in the Uno32 keyer at the rig operating position is from 20 Sept 2015.

18 June 2015:  Because this page has continued to get longer as I think of comments to provide, I will attempt to do a quick summary here:  This project uses the ChipKit Uno32 and provides a paddle keyer plus CW keyboard plus CW decoder.   The decoder performance from 15 wpm to 100 wpm is "perfect" for a perfectly clean input signal.  For over the air signals, it works fairly well if the rig filtering and noise reduction are used on weaker signals and it works well for strong signals if there is no QRM or high noise level.  It will not dig signals out of the noise or QRM.  I present the information here in case there are those who are interested in working with either a Uno32 or Max32 board and in using the UECIDE environment.  It should be pretty easy to build up a barebones version to only use as a keyer / keyboard with the rig.  My version uses a printed circuit board to fully support "iCW"  (internet CW).  But if one is not interested in iCW, it could still be a fun project to play with, with or without the decoder section.

21 July 2015:  I have been working on a variant of the target hardware, the PICadillo.  This module combines the same processor as the Max32 with a nice TFT graphics display.  I will start this page:  PICadillo Variant  where some information on this board will be provided.

A comment on speakers:  For this "2015" version of the keyer, I am not including an internal speaker like I have done in the past few years.  It takes a lot of work to drill the speaker grill (one of the breadboard photos above has a piece of scrap acrylic for the top panel that had a grill pattern from a project in the past).  

The internal speaker cost from Mouser is nearly half the price of the external MFJ-281 speakers that I use.  So I decided to put the Piezo speakers back in as an option when one needs to just test the keyer features without a speaker available.  

A front panel switch turns the Piezo on / off.  A second switch does the same for the external speaker jack.  You can always use headphones for the high quality sidetone, but for normal operation I use both headphones and the MFJ-281.  I have about 5 or 6 of the MFJ, two on the K3, and they are excellent for CW.

When used with iCW (see iCW below), the received signal is also heard in the headphone (and speaker if connected).  This is in addition to the sidetone.  The Piezo speaker only provides the sidetone. 

The basic keyer and keyboard functions of the AVR keyer projects have been migrated from the Atmel 8-bit chips to the PIC32 chips and merged with the decoder project that evolved from the original Arduino project by Hjalmar, OZ1JHM.  

Note:  The decoder works very well up to 99 wpm when the input signal is "perfect".  My interest in including the decoder in the keyer project is only "for the fun of it".  I originally tested the decoder up to 125 wpm, which happened to be the artificial limit in the keyer I used as the CW source.  I later limited the decoder to 99 wpm so I did not need to provide 3 digits on the LCD display to show the current detected speed.  The decoder works well on iCW (internet CW), but of course lost packets mean audio glitches resulting in decoder glitches.  

The decoder also works well on over the air signals but requires that the receiver provide the filtering so you have a clean signal to decode.  The decoder will not dig signals out of noise or QRM.

For the last few years, my keyer projects have included full support for iCW.  Functionally I think of them as "transceivers" because the output audio has the sidetone mixed with the received iCW "signal" and independent volume controls for each audio stream.  They of course do not need to be used on iCW, they can just be used as a normal paddle keyer + keyboard (and now + decoder) with a high quality sidetone.

For information on iCW see:

In the photo, four pot knobs can be seen.  Three are the usual sidetone volume, received audio (iCW) volume, and iCW drive level.  The fourth pot is for controlling paddle speed in stand alone mode (no keyboard attached).  The speed pot is one of the differences between the AVR and PIC32 projects.  There is also a small pushbutton switch for resetting the keyer if needed.

A preliminary demo is seen below.  I stepped through various settings at times which will probably be confusing as the display is cleared a number of times while CW is being displayed.  e.g. I think I switched between weight and compensation modes and stepped through ranges of settings while a canned message was being sent.  The display was being cleared each time I stepped to a new setting.  Some day I will need to work on clearer examples of each feature / function.

An early demo of a "simulated" iCW QSO

This is a later demo in a "real" iCW QSO.  Upper case is "me" and you can hear me pounding on the keyboard.  Lower case is K6KX.

Demo in a "real" iCW QSO

This next video shows the final enclosure and hardware in more detail.  It also happens to show a few of the features in the process.

Hardware and Enclosure

See this page:  SerialPortDisplayFeature for an example of displaying keyer and decoder "text" on a computer display using the USB port feature.

I use the UECIDE environment, not MPIDE and the last time I tried to build the early decoder only project in MPIDE, I was not successful.  That was sometime last year and some day I suppose I should try to find why it does not work under MPIDE.  
I currently use UECIDE version v0.8.7z36.   I believe perhaps Matt Jenkins (the primary force behind UECIDE) is using a different compiler or compiler version than the latest MPIDE and that most likely is the problem.  When I first tried to get the original decoder working under MPIDE I found a few things (one was queues) that had to be changed before it would compile error free, but it still failed to execute.  I would not be surprised if some day Matt migrates to the same compiler / version as MPIDE and could break my project if I were forced to update.

For information on UECIDE:  UECIDE page  I have to add that without help from Matt on several key items, particularly the timer and SPI_RAM libraries in the project, I doubt I would have ever gotten very far in this project.  He was a great resource on the forum, as many others have also discovered.  

The "official" project uses a Uno32 board.  I built the Max32 breadboard seen above in order to test that I can target both the Uno32 and Max32. The software project can be compiled for either board and I do not expect the memory requirements of the software to exceed the Uno32 resources, but it may get close in either program or ram memory.

The PCB layout for the "final" assembly will use the Uno32.

The breadboard currently seen in the photo above has now been in full use at the rig / iCW operating position and I believe it is very close to being fully implemented.  At this point I expect only minor refinements as I find items that need some work.  

The fundamental keyer and kbd features are identical to the AVR project, with some new key stroke functions for controlling certain parameters like the sidetone frequency.  I now support a "compensation" option in addition to my usual weight control, where I varied the duty cycle of a string of dits.  The weight option still specifies weight as a duty cycle percentage, where a weight of 50% specifies that the dit duration equals the element space duration.  A heavier weight (e.g. 53%) indicates dits are 3% longer and element spaces are 3% shorter than when the weight is 50%.

The compensation option adds or subtracts a specified time to elements and subtracts or adds the same amount of time to element spaces.  The compensation is specified in tenths of msecs.

In the AVR project, the arrow keys were used to change paddle speed, kbd speed, or weight in steps of 1 or 5 msecs.  The PIC32 project adds other parameters that are controlled from the arrow keys (sidetone, weight, compensation, decoder speed lock).  

The "auto focus" feature is similar to that in the AVR project.  Eventually I would hope to prepare a "user manual" for the PIC32 version where I would try to explain the auto focus differences between the AVR project and the PIC32 project.  I will also need a new key layout "cheat sheet" to identify the special function keys.

The Hi-Per Mite design is used with permission of Dave Cripe, NM0S,  the designer.  Dave designed the filter for a club fund raising project of the 4SQRP club.      I have previously used many of the club Hi-Per Mite kits in the iCW keyers.  The web site for the filter is:  4SQRP Club Hi-Per Mite filter.

Flag Counter