[CW] morse code decoder !

[HL 1 WOU]

 

PIC16LF84A_datasheet.pdf

picmrsrc.HEX

picmrsrc_asm.htm

 

Morse Code Decoder Circuit - Using a PIC Microcontroller

9/30/2006 - This project is right up my alley! I gathered all parts and started building the circuit on a breadboard first before designing the circuit board to etch. - KC2NDA

9/30/2006 - Click Here for the the original Author/Designer's notes and pictures.

12/02/2007 - I have been getting a lot of emails about this project. Most of them are because of the bad source code listing at the end of the author's notes. I have seen this problem all over the web and I too have ran into the same problem when compiling the code. I am assuming that the code has been copied and pasted so many times that things have been jumbled. You will notice that the code does not compile because of the duplicate labels "dlp1". I have not had time to fully break apart the code yet, but I am assuming the extra code that exists with the duplicate label is extraneous and should be removed. Once this block of code is removed, it should compile. I modified the code and reposted it. I also included the compiled hex file as well. NOTE: I changed the header to be used with the PIC16F84A since those are readily available from Microchip.

Original Author/Designer Notes

by Lawrence Foltzer, KE6UDL

So you want to become a HAM, or you've got one of those no-code licences, but like me feel somewhat lacking,... not having obtaining that age old badge of proficiency that differientiated the HAM from other radio operators. However, like thousands and thousands of others, you have trouble learning the code. The problem for most people is the non-real time nature of the process, i.e., writing down the last character while listening to, and decoding the signature of the next character. Furthermore, when you make a mistake, the entire process collapses as your mind tries to perform error correction, trying to fill in the missing blanks, causing you to miss even more characters.

One way out of this delimma is to remove the burden of writing down the characters altogether during the process of building up your code speed. But to do this you need a device that copies and displays the code in parallel with you, which is what the stand-alone device described in this article is designed to perform.

The decoder is designed for code speeds ranging from about 6 words per minute (WPM) to greater than 36 WPM. The rate adaptive algorithm responds quickly to code speed changes, so you can copy both halves of a QSO, even when the parties transmit at different rates.

The Hardware

The schematic of the decoder is shown in figures 1a and 1b. It consists of four major pieces, all powered from a set of four (4) AA cells. The first piece, the front-end, is composed of an electret microphone and a common emitter transistor amplifier. This building block provides a wireless hookup to your radio receiver or code practice oscillator. The 15Kohm resistor biasing the electret may have to be changed to a different value, depending on the requirements of the electret you use. In addition to providing gain, the transistor amplifier also acts as a first level bandpass filter. Its band edges are determined by the size of the coupling capacitors, and the feedback capacitor between Q1's base and collector terminals.



The second functional block is a narrowband PLL based tone detector, consisting of a tunable NE567 PLL tone decoder (Click here for the datasheet). There's nothing radical here, the circuit is right out of the manufacturers data sheet, and employs hysteresis for chatter prevention to, in effect, debounce the decoded signal. The small signal, narrowband detection capability of this block enables one to easily discriminate one signal from another, even when the signal you are copying is substantially smaller that the adjacent channel interference, as long as there is 100Hz or so frequency separation between them. The output of the detector is a one-zero pattern replicating the DIT-DAH sequence of the received signal. This output drives both an input to the PIC16F84 microcontroller and an LED which is used as a receiver tuning aid. More on that later.

The third functional block is the PIC16F84 (Click here for the datasheet) microcontroller (CPU). Its function is to measure the duration of the one-zero input string from the tone decoder, and translate the pattern into DITs, DAHs, symbol spaces, character spaces, or word spaces. The CPU also perfoms input signal debounce, just in case the front-end missed something. This feature was one I found absolutely essential for the robust operation of the decoder under varying signal conditions.

The CPU also has the task of code speed adaptation, which it performs by performing a running average on the various components of the signal in real time. The symbol averages are then used to compute time threshold levels for correct symbol interpretation. As each of the symbols are received, a "code word" is assembled and used to lookup/convert to its ASCII equivalent character for display. The CPU also drives an LED in synchronism with the input. While this feature was used initially as a debug aid, it also serves as a tuning aid, and verifies that the CPU is receiving what the front-end sent. Finally, the CPU interfaces to the LCD line display, sending ASCII characters to it and monitoring LCD status.

The final building block is the LCD display. I used a surplus display that uses an Hitachi HD44780 LCD controller based interface. You can purchase a similiar OPTREX unit through DigiKey Electronics, P/N DCM-117A, for about $12.00, or Hitachi display I used from me for $8.00, while my limited supply lasts.

In the prototype implementation of the CPU, figure 1a, I used a crystal to generate the CPU clock since I had a sizeable stash of crystals in my junk box. But one could just as easily use the RC oscillator configuration since the PIC16F84 spends most of its time sitting around anyway, and could easily do the job running at 1MHz.

Construction

I built my decoder as two separate pieces, and recommend this approach for two reasons.

1) It allows you to distance the CPU and LCD away from your receiver, minimizing digital noise coupling the the receiver.

2) It keeps the CPU and LCD clock noise away from the sensitive front-end of the electret amplifier and PLL.

The front end was constructed using point-to-point wiring on a 2.0" by 2.5" piece of perf-board. I wrapped the edges with adhesive backed copper tape to provide a convenient place to ground components. The 10Kohm variable resistor off pin 5 of the NE567 provides frequency adjustment capability so you can tune it to the frequency of a code practice oscillator, or to a comfortable pitch to copy signals off the airwaves. A three (3) wire interface connects the front-end to the CPU/LCD assembly, carrying the signal, power and ground.

The CPU was also point-to-point wired on a 2" by 2.5" perf-board. I decided to interconnect the CPU and LCD using a 14 pin (2 * 7) plug and socket arrangement I made up for easy connect and disconnect. I used machined pin and collet type sockets and pins for this connection. A three pin header socket was used to make the connection to the front-end consisting of power, ground, and the decoder output.

The PIC16F84 Assembler/Machine Code

The firmware for this project is shown in Listing 1. This code was written in Microchip's native assemby language, and only took 365 instruction to implement. To help follow the flow, read the pseudocode at the end of the listing. You will find other important design details at the end of the listing also. The heart of the code is two running average buffers that keep tabs on the length of the four previous DIT and DAH interval samples. With these short buffers, speed adaptation appears almost instantanous. But I must confess that I didn't start out with this approach. In my first implemetation, I averaged DITs and DAHs in the same buffer, since over time there would roughly be an equal number of DITs and DAHs, and the average, therefore, would be (2 DITs long) right in the middle and be the perfect symbol discriminator. But when you copy sequences like "he is 55 .....", the symbol decision threshold becomes corrupted quickly unless the buffer depth is quite large. But a larger buffer means a slow code speed adaptation rate, so I quickly abandoned that approach in favor of the dual buffer approach.

The three subroutines at the end of the code drive the LCD display interface. Perhaps you will find uses for them in other PIC related projects.

DIT DAH DIT DIT DAH DAH DAH DAH DAH DAH DAH DIT DAH DAH !

DAH DIT DAH DIT DAH DIT DIT DIT DIT DIT DIT DAH DAH DIT DIT DIT DAH DIT DIT

DAH DIT DAH