This project began life a bit before Hjalmar posted his Arduino decoder project. I had barely begun to migrate my keyer software to the ChipKit PIC32 boards (Max32 and Uno32) at that time. I decided to play with Hjalmar's decoder first on an Arduino type processor (actually one of my AVR keyers) and then migrated it to the PIC32 processor with the goal of having it work for "real" QRQ.
This is the current short demo showing the three functions (keyer / kbd / decoder): youtube video
(Note that the acoustics in my room for the sidetone from the "remote" keyer that is being used for the sidetone to decod are very poor so it sounds awful, also the acrylic panels used for the "enclosure" were from scrap and had various extra holes that partly block the LCD etc.)
I have done some simple tests to verify that it can simultaneously decode audio input while sending from either the paddle or keyboard so I think it has the speed and resources to handle the desired features.
The decoded cw and the "transmitted" cw displayed on the LCD are also sent to the serial port for display on a terminal program on a PC. The screen shot below shows how the "RX" and "TX" characters are separated with a blank line.
The amount of "history" is only limited by the settings of the terminal program used.
I think this project will work well for iCW qsos, and the decoder does pretty well on off the air signals but depends on a good filter in the rig, and requires a decent signal, it will not dig signals out of noise. I doubt I will ever try to implement software to do a better job of decoding in the presence of noise.
I just got the fundamental routines for paddle sent code going today, and still have lots of work to do before the project is ready for "prime time" on the rig or iCW.
I use the UECIDE for development. Some months ago I tried to get the decoder software to build using MPIDE but had problems, and since I do not like MPIDE to begin with (it is a migration of the Arduino IDE to the ChipKit boards, I do not expect to ever try again. UECIDE is far better in my opinion. So anyone wanting to play with any of the software can expect it to not build under MPIDE and should just plan on using UECIDE.
Functionally, I do not expect the keyer / kbd functions to offer any advantages over the AVR keyers, but I just like the idea of using the 32 bit processors running at 80 MHz, compared to the 8 bit processors running at 16 MHz, and I believe it certainly makes it easier to include the decoder and have it function at "real" QRQ speeds. Originally I tested the decoder "only" up to 125 MHz, but now have it limited to 99 wpm, so I do not need a three digit field on the LCD to display the decoder speed, and the same thing for both paddle and kbd, they are limited to 99 wpm.
p.s. The first time I tried to "preview" this post I could not figure out how to come back to continue editing. I stumbled around and eventually noticed AutoRecover and got it back, but I will not try to preview again!
"Hi Chuck, Great to see your latest keyer/decoder I hope you will succeed in getting it going, I would love to be able to listen in to the high speed contacts on iCW and if I could use the decoder to help decode I hope it would help to raise my speed…"
I eavesdropped on the Saturday iCW net to see how the decoder did with multiple "stations". It turned out to primarily be KF7CX and AA0HW. I have the full "transcript" in a PDF file and the recording in a large MP3 file at this link:
The MS Word file that the PDF was generated from happens to also be in the folder. One could quickly download the PDF file to see the comments describing some of the setup and what was going on and the primary reason for providing this.
The MP3 file is about 72 MB so it would be a bit of a download. It also is not easy to locate parts of the transcript in the MP3 file but I provide the PDF and MP3 file just in case one or the other or both might be of interest to anyone e.g. Rich :)
It is likely that some of the word space decoding (words run together) is because I had the decoder target speed "locked" so it was not tracking the speed. When tested with "perfect" input word spacing the locked target speed provides proper word space decoding over a range of 40 to 80 wpm, but particularly if Joe is not using a space bar (I think he indeed does not use it) the decoder could be a bit picky but in that case it is quite impressive that he still decodes as well as he does with manual word spacing!
I'm sure FLDIGI does at least as good a job of decoding QRQ, but of course I prefer hardware over software :)
24 May 2015: I see that my original post was "only" two months ago. I feel like it has been six months or longer! I currently have the keyer and keyboard functions fully implemented (as well as the decoder of course) so that I am now using it at the operating position for both HF and iCW.
The youtube demo below only touches the surface to show some of the operation. I used a second login and keyer to send CW over the server to be decoded. I attempted to describe some of what is going on in the youtube comments for the video, so it is necessary to expand the comment window to see the full text.
The decoder works very well on iCW (unless there are lost packets of course). There is a decoder speed "lock" function that probably would improve the decoding in the presence of pops in the Mumble audio due to lost packets. Such events probably could cause the detected speed to suddenly jump very high and result in lost copy until the decoder reacquires the actual speed. I have not tested this at all other than to verify that the decode speed does lock. It should also help for noise on over the air signals.
The input limiter / buffer stage that I use produces better decoder performance for over the air signals than I expected. Using the K3 400 Hz filter on "decent" signals with low noise works very well. I think using the K3 NR feature on weaker signals also provides decent performance, but I am not much concerned about over the air performance.
I have started a PCB layout and hope to get it done in the next few months and build up a "final" version. The current Uno32 and Max32 breadboard versions are enclosed in acrylic enclosures that used scrap pieces so I will need to order more acrylic cut to size panels to make a better enclosure.
The hardware includes a Hi-Per Mite clone for the iCW features, so it is not just the ChipKit board plus a few components, but for just the keyer plus keyboard features one should be able to build a low parts count version. Or for just the decoder, including the input limiter stage, a reasonably simple version should be possible.
As mentioned in the original post, I used the UECIDE environment for the software project and it is unlikely that it will compile in MPIDE. I have not tried MPIDE in many months but the last attempt was not successful. Even after making changes to get it to compile error free, it still did not run and I did not pursue that any further since I really like UECIDE and do not care for MPIDE. (It is just like the Arduino IDE which I do not like.)
I will generate JPG images of the schematic and upload them in another post.
I have attached the two sheets of the schematic. I have checked the schematic fairly closely but always have some errors remaining. The hope is always that the final PCB layout will be useable without any serious rework required :)
I finally got the first PCB version built up and tested. No nasty layout problems, just my usual oversights on minor points. I am waiting for parts from Mouser to complete the other three boards, and waiting for acrylic panels from TAP for the crude enclosures.
I have gradually been adding information to a web page with project details here: Uno32 project
The schematics on the web page probably have some corrections more recent than the ones I previously posted on this site.
A snapshot of the software is also on the web page, but anyone wanting to play with it in a Uno32 should request the latest update from me.
Well, it looks like another year has passed and I never seem to stop this foolishness! I have recently been using the ChipKit "Fubarino SD" board because it is small with a better form factor (footprint) than the Arduino type ChipKit boards and it has a SD memory card slot. This is what I have been using for the "eBook" keyers on the iCW server, along with the older perfboard versions that used the Picadillo-35T boards that also have the SD slot, but are larger and cost much more because of the nice TFT LCD display that is attached.
The video link below does not show the keyer in operation, there are others that do that. It just shows the blank PCB, followed by the fully assembled PCB. Part of the reason for this current version was to learn to use Eagle CAD instead of ExpressPCB, and particularly to learn to create the Gerber files that can be sent to any PCB house. I used Seeed Fusion (China). My layout was not perfect, but there were no problems requiring rework, so I consider it a success. The quality of the Seeed boards was excellent.
The design includes the usual iCW audio interface features that all my recent designs include.
Seeed Fusion allows multiple board designs to be combined in a single layout. I may do another project to see if I can learn how to submit this type of job. It will be a "basic" keyer using the Fubarino, but without the iCW interface features. The total area of the two sections of the layout (one for the main items, one for the I/O panel) will still be less than the area of the PCB shown in the video, so the price will be noticeably less. If this works, I will probably design another stand alone iCW interface that the basic keyer can connect to so either paddle, keyboard, hand key, or straight key can be used for iCW.
I never plan to sell them, but have ended up selling a couple per year in recent years. I never seem to stop trying something different which means my shelf keeps filling up :)
I ended up doing a second PCB that is a "basic keyer". It does not have the Hi-Per Mite / iCW audio interface. So I ended up with 10 blank PCBs for both the first set (the iCW version) and the second set (the basic keyer). Send me an email to my QRZ address and I can let you know what the possibilities are. I will be happy to provide a blank PCB and the HEX file for download at no cost if you are interested in building one up. This will require that you can work with pretty basic non step by step information. But I probably can offer an assembled one for sale also.