Copying CW

by Walt Fair, Jr., W5ALT

If you thought I was going to talk about how to learn how to copy CW, here, I apologize. There are plenty of resources for learning to copy CW, but to me the most challenging is figuring out how a computer can copy this simplest of digital modes. It would seem to be the proverbial "piece of cake," but surprisingly computer copy of hand sent CW is most definitely not easy! So here I will discuss some things involved in copying CW with software.

It's all in the Timing

As we learned in preceding sections, CW is a simple digital mode that can be perfectly sent by a simple binary machine. In fact I showed how to write a program to send CW and the digital part was pretty simple, involving only a table look up to convert characters from ASCII to a CW coding scheme, then substituting the correct sequence of 0's and 1's to turn the carrier on and off. The complications all came in when converting the simple binary code into soundcard audio and making sure that the waveforms had the right shape. So why can't we just do the same thing in reverse to copy CW automatically?

As a matter of fact, for perfectly sent CW that approach would work fairly well. We simply sample the signal in the middle of every dit time interval and record a 0 if there is no signal and a 1 if there is a signal. That will give us a string of binary 1's and 0's that should define the CW characters being received. Once we have accumulated enough 1's and 0's, when we find a sequence of 1110, we replace that with the symbol for a dah and replace the sequences of 10 with a dit. When we see a longer space like 00, we know that's the end of a character, so we look up the ASCII code in our CW character table and save the ASCII code in a regular string ready to display. In the same way, when we find a longer sequence of 0's, like 00000, we know we've found the end of a word, so we simply add an ASCII "space" to the interpreted string. Simple and straight forward.

Actually we made a couple of assumptions in defining that algorithm and as it is, it likely won't work except in the case of a miracle. The first detail we overlooked is how to figure out when to take the samples. In order to sample in the middle of every dit time interval we have to know a couple of things: 1) when the time interval starts and 2) how long it is. The length of the dit time interval depends on the CW speed, of course, so we pretty much need to know ahead of time exactly what speed is being sent and exactly when the transmission starts. But CW is not a synchronous mode that depends on the exact speed or the exact timing, so in effect copying CW as described above is in general totally impossible. One slight hesitation or minor variation in CW speed and our timing would be all messed up and copy would be lost. So we need to find a way to determine when each element starts and how long they last, which is equivalent to knowing the CW speed.

One approach might be to sample the signal at a higher rate, which is a common ploy in digital signal processing. In fact since we don't know the starting time, it's fairly easy to show that you have to sample at least twice as fast as the data in order to guarantee that you don't miss anything in between samples. And since we don't know the speed, we could take the approach of sampling so fast that we wouldn't miss the fastest possible CW signal. So for example we could figure that we'd never need to copy CW faster than 120 WPM. At 120 WPM, the time for a dit would be 1.2/120 = 0.01 seconds or 10 ms, so we could sample at 5 ms and be assured of copying every dit at 120 WPM and everything slower, too, even if we don't know exactly when the transmission started. That is equivalent to a sampling rate of 200 Hz, which is still excruciatingly slow for most digital techniques. Recall that a soundcard can go along at 44100 Hz sampling with no apparent problem.

If we implement that sort of sampling, we'll end up with sequences of 1's and 0's, but they probably won't be exactly 1 and 3 units long, because the CW speed is probably not 120 WPM starting exactly at our chosen sample timing. So now we have to look at the sequences and decide just how long is a dit and a dah, so we can tell them apart. In principle that's not too hard, since the dahs should be 3 times longer than the dits and the same holds for the spaces between elements, characters and words. It should be apparent which ones are short, which ones are long and which ones are really long. And once we figure that out, we can convert the signal stream to the CW character codes and proceed with our lookup as above.

So How Can a Computer Send CW?

Under Construction