Introduction |
I included this design in the Keyer section, because I thought it was interesting. The idea behind this design is to help cleanup hand sent Morse code. This can be from a straight key or a bug. The interface was originally designed by Jonathan Titus, KZ1G (ex-KA4QVK) and was published in Ham Radio, June 1983. I have also recreated the original as a web page, to make it a bit easier to read. I redrew all of the graphics but left out a photograph because, it reproduced poorly.
Note that the original version, and the recreated version, is missing the Power/Ground wiring. It's not large or complicated, but should be included. I included a Power/Ground drawing below.
Now this article was published many years ago, but I have never come across any kind of follow-up. I hunted through the next two years of Ham Radio but didn't find any feedback. Why? The bands are still full of bad actors. Especially now since they dropped the code requirements. I carefully read the article and it seemed like a good idea to me. Maybe it was just way ahead of it's time. So I thought I would give it a closer look.
I wanted to see the circuit in operation, but I didn't want to actually build it. So I wrote a Verilog simulation. I had a little trouble getting the timing relationships correct, but I managed to work that out. At this point, it is assumed that you read the original article, and understand the schematic, as the description references both.
I use 20 WPM as a base for all of my tests. That speed is totally arbitrary. The results would be the same at any speed.
Sending the letter "C", with perfect timing.
The image on the right is a clipping from the simulator viewer. It shows the sending of the letter C (dah-dit-dah-dit) at 20 WPM, with perfect timing. This makes a dot, and a element space, 60ms in length. A dash would then be 180ms long. I have annotated it a bit so that you can see the sequencer state (Q0-Q5) easier. The KEY signal is the output of U6D which inverts the Debounced KEY Input (KEY). The MORSE signal is the processed output that would be used to key a transmitter or code practice oscillator.
The rise of the KEY signal (T=100ms) starts the internal oscillator. As the first dash progresses, you can see the sequencer, Q0-Q5 incrementing. It looks like the counter never goes back to the Q0 state, until after the entire character is complete, but it does. Just for a short time at the end of each element space time, Q4. The resolution of the image isn't good enough to see it very well. But, with the waveform viewer, I can zoom in of the end of the first dash and see it clearly. In fact, just prior to the start of the first dot (T=340ms), the sequencer is reset to Q0 and the clock, CLK, is disabled. Note that the CTR_RST signal also happens at the end of each dot and dash sequence. Each sequence includes the element space.
It's also important to note that, the DASH signal (U4A-Q) recognizes that the key is being held longer than a dot. There doesn't seem like a lot of time between the end of a dot and the DASH signal. But more on that later.
You might also notice that the MORSE signal has a small glitch 1/3 of the way through the dash output. This is due to the inherent propogation delays in the ICs that make up the sequencer portion of the circuit. It should be too small to cause any jitter in keying.
Sending with not so perfect timing. (Short Elements)
But what happens when the keyed code is less than perfect. What does the circuit do if a dot is shorter or longer than perfect?
The whole purpose of the circuit is the assist in cleaning up, timing that is a little off. Dots, dashes, and element spaces that are a little shorter, or longer, than they should be. So I ran some other simulations, but with different input timing parameters.
This timing diagram shows sending four dots at a speed slightly higher than the speed that the clock is set for. Specifically, the clock is set for 20 WPM (60ms key down) but the dots are at 22 WPM (58ms key down). The spacing between dots is standard (60ms). This is actually a possible problem with the setting of the automatic dots on a bug. Dots on a bug should be set so that they are symmetrical (equal on and off time). I guess that's debatable, but that is how I set mine.
If you look closely at the timing diagram, you can see the shortened KEY signal in relation to the processed MORSE signal. The processed MORSE signal is stretched slightly to the full 60ms. Following the KEY time, there is a full 60ms until the next dot. But the next input dot is actually happening sooner than expected. So the processor enforces the full 60ms space before creating the next dot. This shows that the processor recognizes the start of the second dot and starts the sequencer when it is the correct time.
It's interesting to note that, the processed dots skew further and further, with each sucessive dot. While this makes perfect dots with perfect spaces, I would be curious how this sounds. Does the user feel/hear the delay?
This timing diagram shows the same clock relationship (clock = 20 WPM, dashes at 22 WPM). However, with dashes. The first four dashes are lengthened properly, but the skewing of the output causes the last dash to not be recognized. That's because the 5th dash comes before the 4th dash is being generated. Slowing down a little bit, by just 1 WPM to 21 WPM, fixes this issue.
Sending with not so perfect timing. (Long Elements)
But this timing has me a little concerned. This timing show a string of four dots sent at a speed that is slightly slower then 20 WPM. The CLK is set to 60ms, for 20 WPM sending but the dots are 63ms in length. The spaces between the dots are 60ms, the standard element space for 20 WPM. But what I am seeing is that the dots are not recognized as dots. Because the dots are slightly longer than a dot should be at 20 WPM, dashes are generated. The schematic indicates that this should happen but it just seems a little odd. It means that you need to be very consistent with your sending speed and the clock needs to be carefully set.
Straight Key Interface Schematic |
The drawing below contains the missing Power/Ground specifications and the Automatic Tune-Up feature. The Power/Ground for each IC includes a 0.1µF/50V capacitor on the power pins. The capacitors are for noise reduction and should be placed as close to the IC's power pins as possible. For want of a better place, I included the Automatic Tune-Up feature. The circuit shown uses left over gates from the original schematic. I did not include this feature in my analysis because, I don't find it very useful. I would rather have a simple toggle switch or a switch that moves the key terminals to the output, for tuning purposes.
Straight Key Contact Debounce |
The Straight Key Interface discussed here, requires a key input that is contact bounce free. Any amount of contact bounce can cause the interface to generate eroneous dots or dashes.
I have done a little research on contact bounce. However, most of the materal is about switches, rather than straight keys and bugs. If your interested in switch bounce, a somewhat interesting paper called A Guide to Debouncing, by Jack G. Ganssle, is probably worth a read. Below are some bounce solutions that are specifically aimed at straight keys and bugs.
Debounce Using a Capacitor or RC Network.
Probably the simplest debounce solution is simply adding a small capacitor across the key terminals. DL6ZB, Rolf Heine, has a few scope traces showing the bounce from the dot contacts of a bug. In Rolf's case it looks like the bounce from the dot contacts is about 3ms to 4ms. A 330pF capacitor was all that was necessary to eliminate the noise from the bounce. It's a short page so it's probably best just to read what he has to say.
A more effective approach, and still very simple, might be the circuit on the right. With the KEY open, C1 is charged through R1. In this position, D1 bypasses R2. The result is a logic "1", after the delay created by R1 (~1ms).
When the KEY closes, it discharges C1 through R2. The R2/C1 time constant (~10ms) determines the delay until a logic "0". The junction of R2, D1, and C1 is connected to the CD40106 Schmidt Trigger Inverter. The output of U1 will be a logic "1" when the KEY is closed and a logic "0" when it is opened. The CD40106 Schmidt Trigger Inverter provides hysteresis which effectively provides two trigger points. The trigger points are above and below VCC/2. The higher the VCC, the wider the trigger points. For example, assuming VCC = 10 Volts, the trigger points would be approximately 4 Volts and 6 Volts. This helps eliminate any noise triggering during the close and release of the KEY.
Now, a logic "1", when the KEY closes, is not what the interface requires, but that can be remedied by simply adding another inverter.
Debounce Using a CD4013 Dual D-Flop and a CD4049 Inverter.
This debounce circuit is a suggestion from the original interface article. With the KEY open, the input to U1A-D, and U2 is a logic "1". This causes the reset (R) inputs to be logic "0". The rising edge of CLK will then pass a logic "1" to the "Q" outputs of U1A and U1B. Until the KEY is closed, the circuit will just idle in that state.
When the KEY closed, U1A and U1B are reset, causing their Q outputs to be logic "0". Any bounce from the contacts will cause the reset signal to toggle. But unless the positive edge of a CLK happens when the KEY input is bouncing "1", U1A and U1B will stay in the reset condition. However, the CLK is asynchronous to the KEY signal which means that, this can happen. But, it will take another CLK cycle to get through U1B. By that time, U1A would be reset again.
What I see is that this circuit wouldn't be very useful. The timing diagram shows a single KEY down operation with simulated contact bounce at the start and end (blurry area). The initial KEY closure seems to work fine. The contact on the releasee of the KEY also seems to be good. But with the Clock Input running at a 100 Hz rate, and being completely asynchronous to the keying, extra time is needed to shift the KEY release through U1A and U1B.
In the example shown, the KEY closure lasts 60ms, from initial closure to initial release. But the need to shift the release through a couple of flip-flops, adds 16ms to the overall KEY operation. Plus, due to the Clock Input being asynchronous to the keying, this extra time can vary from one KEY operation to the next. While the image of the simulation only shows one KEY operation, the simulation contains multiple KEY operations. In the simulation, I can see the KEY operation being extended from 10ms to 20ms.
I guess you could use this with the interface, but you would have to adjust the interface clock so that it fixes the length of each and every dot and dash.
Debounce Using a SN74LS221 Dual Monostable and a SN74LS00 Quad NAND gate.
The drawing below handles contact bounce on both the closure and release. The circuit employs a SN74LS221 Dual Monostable and two gates from a SN74LS00 Quad NAND gate package. The two gates form a RS Flip-Flop. The input components R1, R2, and C1 form a low-pass filter to help remove some of the contact bounce before it reaches the monostables. D1 and D2 form a noise clipper that limits spikes above VCC and below ground.
At rest, with the KEY open, the Q output from the monostables, U1A & U1B, are a logic "1" and the RS Flip-Flop is set so that DOT/DASH is a logic "1".
When the KEY is initially closed, Q of U1A is triggered and generates a pulse. This pulse prevents U1B from being triggered until the contact bounce signals have ceased and sets DOT/DASH to a logic "0".
When the KEY is then opened, U1B is triggered and it's Q generates a pulse. This pulse prevents U1A from being triggered until the contact bounce signals have ceased and sets DOT/DASH back to a logic "1".
The timing diagram on the drawing gives you a good idea or it's operation. The components on U1A & U1B set the pulse widths to about 4ms. This should be good for dots or dashes from a bug. Increasing the values will increase the pulse width.
IMHO, this circuit would work better with the Straight Key Interface. The only disadvantage is that it is a TTL design. However, it could be converted to CMOS using a CD4098 Dual Monostable and a CD4011 Quad 2-Input NAND gate package. You would probably have to change the timing components.