A keyer is an interactive device. It needs to respond to the paddle in a timely manner and produce transmitter keying that results in a clean and easy to understand signal. Timing is a big issue in any keyer design and each part of the device runs in its own time scale or time regime. These all need to be made to mesh together for proper operation.
The microcontroller (mcu) will execute an instruction in about a microsecond. A sidetone at 1000 Hz has a period of a millisecond. A dot at 20 WPM is 60 milliseconds long. Precision and accuracy are factors to consider in any of these regimes. The microcontroller clock is adjustable but you need to know what it is because it is the basis for measuring all the other time regimes. In this application, the sidetone pitch isn’t that critical but it is worth considering that music scales step in 6% increments. For transmitter keying, the most critical issue is in getting the proper proportion between cw elements and less in actual speed. A 5% variance in the fundamental cw element (the dot length) means only a 1 WPM variance at 20 WPM.It should be easy to get better than this because the mcu instruction time is so much shorter than a dot period.
The EI9GQ keyer mentioned in a previous post provides a good base for evaluating mcu requirements in terms of the other regimes. The program instructions cover about 55 instruction cycles at one per instruction plus an additional cycle for every instruction that changes the program counter (like a goto or call). At default 12f683 mcu speeds, the delay loop would provide a dot time representing about 75 WPM. That makes sense as the external adjustable resistor-capacitor clock EI9GQ uses probably runs at a slower speed.
A basic program loop that checks for paddle contacts, sets transmit keying periods, and makes the other necessary decisions based on the example can be used to compare time regimes. By this measure, the sidetone period is about 18 program loops and a 20 WPM dot length is a bit over 1000 program loops. Even a 99 WPM dot with only 25% weighting would occupy 100 or so of these program loops.
Key bounce is often considered a hassle in devices that use switches for input devices. Some switches take 5 to 10 milliseconds to calm down. Rather than wait the 200 or so program loop measures for this, a keyer could just assume any indication of switch closure was indeed a switch closure. Bounce considerations would be accommodated by not allowing repeats within the approximate dot or dash command time frame. Much like in the example code, once you detect a paddle request for a dit or dah, go key the transmitter and don’t look for another paddle press until that’s done.
There are three ways commonly used to match up time regimes, often in combination. One is to cange the regime clock speed, another is to engage in busy loops to idle away time, and a third is to use interupts. The mcu can be set to run a special program when a timer value counts down to zero or a switched is closed or some other event occurs. This interuption in normal program control can be used to allow the mcu to do whatever else is useful but still respond to paddle input, transmitter keying, or other things in a timely manner. How to use interupts instead of the busy loops in the sample code will be a topic to explore.
The transmitter keying time regime also has complications that could be interesting to explore. This will take a look at the impact of Farnsworth keying at speeds lower than 18 WPM and key ‘weighting’ that changes the duty cycle between key down and key up between elements in order to improve readability or compensate for transmitter behavior.
simple project with lots of facets — that makes for a good target!
Post a Comment