DXsoft Miscellanea / Break-In magazine review of CwGet and CwType
Gary E. J. Bold review from July/August issue of Break-In magazine.
More Morse with Computers
Ill say it again. The internet is a great plus for Hamming. Just after my last column got put to bed, Murray ZL1BPU passed on an email from a European Ham drawing our attention to yet another couple of shareware morse computer programs developed by Sergei, UA9OSV. I downloaded them immediately from http://ua9osv.da.ru and have been using them ever since. Dont hesitate. If you have a Win95/98 computer with soundcard, try these. Theyre sufficiently impressive that Ive postponed further work on similar software Ive been developing myself. If you dont have internet access, send me a disk and SASE. Here is a review.
This is the name of Sergeis code reader. Its written in Delphi*, and Sergeis help file says he has only tested it on a high end computer, but it runs fine on my 166 MHz Win98 machine. CwGet accepts input from the phone jack straight into the computers soundcard. No interface is required. The audio gain is very non-critical. I unzipped it, fired it up, plugged it in, and it started decoding.
The screen appears as in fig. 1, which shows part of a three-way QSO between Bruce, ZL1ADF, Jon, ZL1JON, and me. The decoded text in the middle screen shows Bruce exhorting Jon to try a keyboard sender. The band is not particularly noisy, and computer copy is pretty good as Bruces signal was very strong, and he sends excellent morse. You can see only a few letters are corrupted. Most signals youll copy on crash-infested 80 metres will not be as clean as this all code readers work better on 20 metres and up, where the static is less. At the end, where Bruce passes it to me, youll see some random characters between overs before the software picked me up and began to decode what I was sending.
Unlike the reader incorporated into the IZ8BLY Hellschreiber software which I reviewed in the last column, CwGet attempts to do everything for you. The top window is a continuously updated spectrogram display which runs from 0 2500 Hz. You can see the fuzzy peak which is Bruces signal overlaid with a vertical line indicating the frequency CwGet is tracking. I have told it to track the strongest signal in its receiving bandwidth by pressing the AFC and AutoGTM (Auto go to Max) buttons. The acquisition bandwidth is set with the up/down buttons, and I have selected the narrowest of the three supplied filters.
Incidentally, like other programs that read through the soundcard, the bandwidth of your receiver doesnt matter much. Sergei has implemented software bandpass filters in his case Bessel 16 pole types which automatically centre themselves on the frequency of the incoming signal.
The text is decoded in the centre window, and youll see by the scrollbar on the right that you dont lose anything off the top of the screen you can scroll up and get it back. And of course your own signal from the rigs audio monitor also goes through the soundcard and is also decoded, so you can see both sides of the conversation. If you register with Sergei (not obligatory, but a nice gesture) you get the capability of saving the text to a file.
The bottom window is time-domain display of the incoming audio envelope which scrolls from left to right, and you can see ZL1AN on the right-hand side. The horizontal line sets the decoding threshold as for Ninos software which I reviewed in the last column but Sergei has implemented an algorithm which you can invoke to set this automatically (the AutoThres button) which looks at the incoming amplitude and follows it up and down. This works pretty well, and allows the decoder to follow fades. My tests indicate that MRP373 decodes slightly better, but theres not much in it.
Speed-detection is also automatic, and the algorithm adapts unerringly from painfully slow to above 60 wpm and probably higher see later. I cant fault it. Better than MRP373.
You can set CwGet up and go away to do something else. It will automatically track and attempt to decode any QSOs in the passband and display them for you to inspect later. The size of the window, and each sub-window, can be adjusted to cope with the resolution of your computer screen.
This is Sergeis keyboard code sender, and you can run it simultaneously with CwGet, since CwType outputs digital morse to a com-port without using the soundcard. Sergei gives a simple one-transistor interface, and tells you how to configure the initialisation file to contain your own callsign, messages of choice, startup speed etc.
You can see a typical window in fig. 2. The Speed window (top left) is calibrated in characters/minute, which is how Europeans prefer to think. Theres a callsign buffer which allows you to send callsign exchanges automatically. Pressing Alt-C puts the cursor in the C (callsign) window. I enter the other stations callsign in there during his CQ. When its finished, I press F3. A callsign exchange immediately fires out from the com-port, the VOX turns the transmitter on, and were away.
Theyre also RST and Name buffers, allowing these to be embedded in messages. You can pause transmission and toggle the computer speaker on/off for audio monitoring.
The only useful feature CwType doesnt have is a weight control**. Many modern transmitters implement an optional keying mode which allows you to hear between elements and characters. The fast rx/tx changeover necessary often clips outgoing elements. Adding positive weight (delaying the turn-off of each element) compensates for this. Ive suggested to Sergei that he should add this, and also an optional speed display in Words per minute. Hes agreed that these would be good ideas, but he hasnt implemented them yet.
I noticed this immediately because Im keying my IC701 via the CMOS SuperKeyer. This keyer (like K1ELs K9) allows you to program a paddle as a straight key, and so I select this option and connect the computers keying output across the paddle. Why do I do this? I had an unfortunate experience once with RF getting back into my computer, and now I like to keep the computer isolated from the keying line even though I have an opto-isolator in there.
Anyway, it turns out that in straight-key mode, the CMOS SuperKeyer clips 6 ms off all my elements. At 35 wpm thats about a sixth of a dot, which makes the morse sound choppy (strangely, hardly anyone notices this, but I do). At 60 wpm, thats about a third of a dot. I checked CwGets reading by simply sending to it with CwType, on the same computer. I suspect that CwGet would read well above 60 wpm if the element weighting was correct.
Theres more. You can connect a paddle to the games port, and optionally use the software as an iambic keyer! I havent tried this, as Im sure Sergei hasnt implemented autospace, and my fingers and brain are accustomed to this. Besides, I love my SuperKeyer and K9 too much.
This is good software. Check it out.
Weighting and Ratio-changing
I mentioned weighting above, and you may not be quite sure what this means. Some people confuse it changing the ratio of the elements, but this is quite different.
Fig. 3 shows, at top, the letter R sent with correctly ratioed morse. The dah and dit elements have lengths in the ratio 3:1, and are separated by one dit-length.
Some keyers and keyboards (CwType is one) provide the facility for changing the element ratio. The middle plot shows the effect of changing the dah/dit ratio to 4.5 to 1, which increases the dah length by 50%, while keeping the space between the elements, and the dit element length constant. Actually, I dont know why youd want to do this, as the morse that comes out just sounds wrong.
The bottom plot shows correctly ratioed morse with positive weighting. All of the elements have been lengthened by the same amount, in this case, half a dit-length. This makes the morse sound full, but it still sounds right. This is exactly the type of weighting you need if your rig/keyer/keyboard clips bits off the front of each element. You simply add a bit at the end to compensate for this. CwType does not allow this (yet) but my DOS program MU does, and so does the CMOS SuperKeyer. Negative weighting does the opposite, reducing the length of each element by the same amount.
Some people contend that slower morse should be sent with positive weighting, and faster morse with negative weighting to make it more readable, but having tried both, I cant agree. Theres some evidence that early transmitters tended to turn off sluggishly, giving a positive weighting which could be compensated with negative weighted keying, but modern transmitters dont have this problem. On the other hand, the slightly negatively weighted morse I send with CwType doesnt seem to bother anyone.
Comments from UA9OSV: