A single word is sent, using one of two alternative keying methods. This is displayed graphically and analyzed to determine two "Merit ratings" of the Morse on scales of 0 - 100.
The grading algorithm penalizes errors quite harshly. Often, code which only achieves grades of 50 - 60% will be quite readable by humans, although it's far from "perfect". Humans, especially expert ones, can compensate mentally for quite severe imperfections. But this program was designed to highlight these imperfections, and help you to eradicate them. Many with good fists regularly score over 90%. Those with poor fists are frequently indignant and refuse to believe it.
Older computers, constructed before about 2005, included a beeper speaker which sounds an audio tone to monitor keying. Well, sometimes it sounds, and sometimes it doesn't. I've no idea why. Later computers didn't have this, but a relay and separate audio monitor can be used instead.
Operating instructions
Comments on Merit ratings
Program background
Connecting a key to the mouse
Connecting an external audio monitor
Setting compatibility mode for Win 7
Appendix: Perfect Morse
The Merit ratings calculated show only how nearly "perfect" the Morse is, in terms of timing. This doesn't necessarily relate to "readability". For example, longer than normal spaces between the characters will result in Morse that is perfectly readable, but not "perfect". But shorter than normal spaces will result in much less readable Morse. Weightings that differ from the perfect "1" won't affect the readability much.
My Merit ratings are based on only three ratios, which I judge from experience to be basic indicators of "good Morse". There are many other parameters that could be used, for example the variability of the elements. For simplicity, these have not been included.
People have asked ``why can't you send the audio tones to the soundcard?''. The soundcard expects to play a specified waveform for a pre-determined time. We don't know how long the key will be down. If you know something I don't, contact me.
The photograph below shows a USB mouse with the top removed. This usually requires undoing a single screw on the bottom of the mouse. This can be a separate mouse, plugged into another USB port. Both mice will operate normally. The 4-wire cable connected to the standard USB plug is attached near the bottom of the PCB and normally exits from the notch on the right of the case. For clarity, his has been pulled out of the way at the bottom of the picture.
The two micro-switches activated by the mouse buttons are the black rectangular modules next to the right-hand edge of the PCB in the photo below. The terminals on mine were soldered through holes to tracks on the bottom of the PCB, so I had to remove the board to get at them. The board sat on mounting studs friction-pushed into holes, and was easily pried up.
Caution! If you wish to re-assemble the mouse afterwards, take careful note of how everything comes apart! When you re-assemble it, normal mouse action will be unchanged.
There are normally 3 terminals: "common", "switch open" and "switch closed". Using a multimeter, determine which two transition from infinite to zero resistance when the switch (the red button on top here) is pressed. Solder two wires to these contacts (the green leads shown) and bring them out through the notch. Use thin wire, so the original mouse cable can also be led through.
An external Morse key can now be connected between these two wires. The top casing can be replaced, and the mouse will still act as a normal mouse. Alternatively, you can construct the interface circuit below, which also provides an audio monitor.
The terminals marked "To mouse contacts" connect to the microswitch as described above.
Timing: Deriving timing information accurate to milliseconds is impossible using the Windows-supplied PC clock functions. Hence all element timing is done with software loops. The loop-time interval is found and converted to milliseconds using the elapsed time of the total recorded waveform derived with the windows "Get Ticks" function, which has a resolution of 1 ms, but an accuracy which may be only 55 millseconds - acceptable for "seconds" scale timing, but not for timing individual elements.
Speed: Morse speed is calculated using the ARRL-defined algorithm "24 words per minute = 10 dits per second". Since each dit requires a dit-space as well, there must be 20 time units in a second at this speed, or each dit itself lasts for 50 ms. Thus, the "wpm" rate doesn't actually correspond to the "number of words" that are sent in a message, but to a baud rate. This algorithm was based upon the "standard" word "PARIS", but since most common words are shorter than this, about 10 - 20% more "real, English" words will be sent than the "wpm" speed indicates.
For "perfect" Morse, this standard corresponds to the algorithm "wpm = (24 * 50)/(dit-length)", where the dit-length is measured in ms.
But it is simplistic to compute the speed using the average dit-length alone, as neither the weighting nor the ratio of hand-sent Morse will be perfect. It is better to use an estimate of the "dot-unit" based on the 4 parameters dit-length, dah-length, ditspace-length, dah-space length. This better reflects what speed "this sender" will actually achieve with these particular keying parameters.
It would be nice to sound the Morse, as it's being keyed, through the soundcard, but this doesn't seem possible. Sound cards are designed to play pre-corded sounds stored in files. As far as I can determine, it's impossible to instantaneously start and stop playing these in real time. If you know something I don't, let me know?
This program was compiled under windows XP. Under Windows 7, you'll have to set a "compatibility mode" for a version of Windows XP. If you don't, the program may not run, or stop with an error message.
So far, users have reported that setting compatibility for Windows XP (Service pack 2) has fixed the problem.
To set this:
Timing is done using the hardware internal clock, which runs pretty fast, at a rate determined by the clock speed of the computer in use. Typically there are are thousands of clock counts per dot. An initial routine (In Delphi it's "Gettickcount()" ) finds the conversion factor to convert recorded intervals to millisec, using the "time of day" clock. This is later used to compute the code speed, in WPM.
The code is read from two mouse contacts, or an external key connected as above.
When the "start" button is pressed, The state of the key is continuously sensed, and the times and polarity of each key state change (up to down, or down to up) written to an internal buffer.
"Markav", the "average Mark time" is computed by dividing the total key-down time by the number of down periods.
"Spaceav", the "average Space" time is computed by dividing the total key-up time by the number of up periods.
The marks and spaces recorded are individually sorted:
Assign marks with lengths > Markav/2 as dahs
Assign marks with lengths < Markav/2 as dits
Assign spaces with lengths > Spaceav/2 as letter spaces
Assign spaces with lengths < Spaceav/2 as inter-letter (dit) spaces
Parameter "weighting" is computed to determine whether the code is "heavy" or "light", using dit and dit-space lengths:
weighting = (average dit length) / (average dit-space length)
For "correct" code, weighting = 1.
Parameter "ratio" computes the ratio (dah + ditspace) / (dit + ditspace). This is a measure of the relative perceived lengths of the elements. Normalising, for "correct" code, dah = 3, dit = 1, ditspace = 1, so ratio (ideal) = 2.
This parameter incorporates estimates of the relative lengths of both mark and space elements, and includes a measure of their "heaviness" or "lightness". This is used to form the primary estimate of "code goodness". Extensive listening and subsequent visual analysis of code recorded from the Ham bands has convinced me that closeness to the optimum value of (ratio = 2) is the major factor in determining "subjective code readability".
Now "penalties", arising from departures from these optima have to be assigned, and this is where real subjectivity comes in. The code in DK computes the "Figure Of Merit", like this:
Line 2 defines an additional penalty for weighting less than 2, which means that "the weighted dahs plus space are too short compared to the weighted dits plus space. Or roughly "dahs are too short compared to the dits". This is added to the weighting error. Example: If the dit and ditspace lengths are correct, but the dash "keydown" time is 2 units instead of 3 (short dashes), the error is increased by 50.
Line 3 defines a similar penalty for high weighting or "the dahs are too long compared to the dits". Example: If If the dit and ditspace lengths are correct, but the dash "keydown" time is 4 units instead of 3 (long dashes), the error is increased by 25.
"Long dashes" are penalised less than "short dashes" since they don't detract from the readability of the code as much.
Line 4 computes the overall rating by subtracting the sum of the weighting plus ratio errors from 100.
The rating's departure from 100, or relative error sensitivity, is predominantly set by just one parameter, one of the the multipliers (100 or 50) in lines 2 and 3 in the "rating caculation code" section above. Decreasing these would give higher rating values. These values were empirically chosen to reflect the subjective bias of the author and the performance of other Hams tested. A more sophisticated code might include estimates of the variance of individual elements and spaces.
Gary, ZL1AN
garyzl1an@gmail.com