DXsoft — Miscellanea / “Break-In magazine” review of CwGet and CwType (Version for printing)

Products  | Downloads | Registration | Feedback | Awards | Links

Gary E. J. Bold review from July/August issue of “Break-In magazine”.

More Morse with Computers

I’ll 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. Don’t hesitate. If you have a Win95/98 computer with soundcard, try these. They’re sufficiently impressive that I’ve postponed further work on similar software I’ve been developing myself. If you don’t have internet access, send me a disk and SASE. Here is a review.

CwGet

This is the name of Sergei’s code reader. It’s written in Delphi*, and Sergei’s 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 computer’s 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 Bruce’s signal was very strong, and he sends excellent morse. You can see only a few letters are corrupted. Most signals you’ll 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, you’ll 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 Bruce’s 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 doesn’t 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 you’ll see by the scrollbar on the right that you don’t lose anything off the top of the screen — you can scroll up and get it back. And of course your own signal from the rig’s 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 Nino’s 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 there’s 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 can’t 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.

CwType

This is Sergei’s 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. There’s 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 station’s callsign in there during his CQ. When it’s finished, I press “F3”. A callsign exchange immediately fires out from the com-port, the VOX turns the transmitter on, and we’re away.

They’re 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 doesn’t 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. I’ve suggested to Sergei that he should add this, and also an optional speed display in Words per minute. He’s agreed that these would be good ideas, but he hasn’t implemented them yet.

I noticed this immediately because I’m keying my IC701 via the CMOS SuperKeyer. This keyer (like K1EL’s K9) allows you to program a paddle as a straight key, and so I select this option and connect the computer’s 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 that’s about a sixth of a dot, which makes the morse sound choppy (strangely, hardly anyone notices this, but I do). At 60 wpm, that’s about a third of a dot. I checked CwGet’s 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.

There’s more. You can connect a paddle to the games port, and optionally use the software as an iambic keyer! I haven’t tried this, as I’m sure Sergei hasn’t 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 don’t know why you’d 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 can’t agree. There’s 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 don’t have this problem. On the other hand, the slightly negatively weighted morse I send with CwType doesn’t seem to bother anyone.

Comments from UA9OSV: