View Full Version : Lazy way to keep code alive
Well there is good and bad news. The good news is that it can be done, the bad is it is not as easy as it sounds. Most of the software have a REALLY tough time decoding even computer sent code. The best seems to be CWGET but it is pretty bad at best. Sending is another story. Most multi data mode software like hamscope send cw (and try to decode). I have had a problem with setting up and getting these utilities to work well. I have found however that contest logging software like N1MM and TRLOG send excellent code, but they do not decode at all. All this said, I have found that the MFJ Pocket Reader has the best reading ability that I have tried. It will copy code that CWGET will not even try to decode. Then I team it up with N1MM Logger and just use the CW sending function. It works great. Although everything is even more easy with an interface like the Rigblaster Plus that I run. Good Luck, its a fun mode.
KH6OO
Tom
The problem I have with sending CW with a keyboard is that I forget what mode I am in, and drop into my RTTY-Digital habits. So instead of sending the "Q" signals, for instance, I start on a long winded dissertation about something, until I realize that I have probably left the other station in the dust.
BTW, there are some guys around that run high speed CW ( 40 or more wpm ) that claim that they are actually reading it. It is quite possible that they are, but the reason I am bringing this up is that the faster you go with CW, the easier it seems to be for software to decode it.
The question of on-off keying VS Frequency Shift keying was discussed many years ago when RTTY was being developed. It was decided then, and still seems to hold true today, that a carrier that is present all the time, but varies in frequency has a far better chance of being decoded properly by machine than one that comes and goes.
There are just too many chances for a noise pulse to come in and be detected as a "bit" and mess up the proper decoding of the letter! Our ears can differentiate between a tone produced by a carrier, and a pulse of noise being produced by a random electrical discharge ( qrn or static ) but it is much harder for a machine or computer to do that.
73 from Jim AG3Y
K0RGR
12-12-2003, 04:26 PM
Actually, I've been playing with MIXW on CW for some time, and it's the best working CW reader I've seen so far. Operating CW with MIXW is not much different than PSK31, if the other station is using a computer to send his code. It does a fair job in QRM and weaker signals.
I'm a fairly competent brass-pounder so I copy in my head while the machine is doing it's thing. There are times when the machine gets it right and I don't, and vice Versa.
A human sending code, even with a keyer, has control over the character and word spacing, which can affect copy. Usually, keyer-sent code is easily copied as long as the sender does a good job of spacing between letters. Otherwise, characters get run together, or more often, broken up. For example, CW ops will change the speed and spacing a bit for emphasis. 'R' , meaning you received everything, is often sent 'dit dah dit' instead of 'didahdit' and the computer reads it as 'ETE'.
If the code sounds like it was sent with a hammer and a knife switch, no computer will ever read it. Sadly, a lot of what passes for CW on HF these days actually sounds like this.
MIXW copies W1AW like it was RTTY.
If the no-coders eventually get HF CW priveleges, something I think is going to happen, I hope they can agree on a computer Morse format similar to W1AW - 18WPM with standard spacing. That way, we old brass pounders can easily read them in our heads, and we know how to make our sending sound for their computers to read it. 18 WPM is fast enough for decent ragchewing.
And, some people advocate learning code at that speed, instead of starting at 0 WPM, so it may benefit those who want to really learn how to use CW.
In order to be competitive with Morse, you will need to learn to copy faster by ear, and use of the computer as a crutch will probably delay that somewhat. Also, as a courtesy to others - including those who don't have the option of computer generating their code - you need to learn to read it 'the old way'. But if you want to get acquainted with the mode, see if you can find others with similar intentions on the air, and have fun.
Dood, if you're gonna keyboard the whole thing, you might as well be using PSK31. Honestly.
As others have said, receiving CW automatically is an inexact science unless the incoming transmission is locked in, synchronized, and perfectly spaced. Again, it's easier to accomplish that on PSK31, which is a fantastic and fun mode.
SENDING cw by keyboard is a common practice, and can be done, if that's what you want.
But aren't we missing the point here? The FUN of cw -- at least in my opinion -- is the human-generated element. And the simplicity. The fun I get from working CW is the same fun I'd get, say, by practicing speaking French, if that's what I were into. Would I enjoy "speaking French" if all I had to do was type English, and have a computer translate it for me? And then have the computer translate the incoming French back into English? #For me, the fun of cw is DOING IT. Not having it done for me, then saying I did it.
It's really very hard to explain to newer licensees why cw is or can be fun. As Novices, we old goats operated nothing BUT cw. It's how we cut our eye teeth in hamming. When we work cw now, it takes us back to those days, in a way.
I have always felt that cw was a "hard sell" for newer hams for that reason. Most newer hams began hamming on 2 meter FM repeaters - the EASIEST mode available. By comparison, cw must see like a real pain in the butt to those people, and I can understand why. WE began in cw, and that was the norm. All other modes were a walk in the park by comparison. Am I making sense?
Code will stay alive as long as there are people who think it's fun. Licensing requirements won't "save" cw. Lack of licensing requirements won't "kill" cw.
Cheerio OM....
dit dit
N8CPA
12-12-2003, 05:39 PM
Well said, SY! Computers can generate Morse and, in the right circumstances, read it. But the keyboard operator misses the "Brassfigneugen," to adapt a term from VW.
What ever happened to the CW robots on the RS satellites? Anyone ever work those? I didn't. I just wonder if they were actually able to receive, as advertised.
!!
w5alt
12-12-2003, 05:43 PM
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (w3sy @ Dec. 12 2003,13:17)</td></tr><tr><td id="QUOTE">As others have said, receiving CW automatically is an inexact science unless the incoming transmission is locked in, synchronized, and perfectly spaced. Again, it's easier to accomplish that on PSK31, which is a fantastic and fun mode.
[/QUOTE]<span id='postcolor'>
Actually, back in about 1983 or so I was playing with computer interpretation of Morse. By combining some fuzzy logic and identifying the correct parameters, it was possible to copy code so sloppy I couldn't copy it by ear. Unfortunately, my source code is on a cassette tape somewhere in Forth, implemented for a Z80 CPU.
Writing software to copy hand sent Morse is a pretty good technical challenge. And believe me, SY, the feeling of having copied CW with my own software was just about as good as having made my first CW novice contact. The challenge is different, but the thrill is still great.
73,
AE6IP
12-13-2003, 12:55 AM
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (w5alt @ Dec. 12 2003,10:43)</td></tr><tr><td id="QUOTE"></span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (w3sy @ Dec. 12 2003,13:17)</td></tr><tr><td id="QUOTE">As others have said, receiving CW automatically is an inexact science unless the incoming transmission is locked in, synchronized, and perfectly spaced. Again, it's easier to accomplish that on PSK31, which is a fantastic and fun mode.
[/QUOTE]<span id='postcolor'>
Actually, back in about 1983 or so I was playing with computer interpretation of Morse. By combining some fuzzy logic and identifying the correct parameters, it was possible to copy code so sloppy I couldn't copy it by ear. Unfortunately, my source code is on a cassette tape somewhere in Forth, implemented for a Z80 CPU.
Writing software to copy hand sent Morse is a pretty good technical challenge. And believe me, SY, the feeling of having copied CW with my own software was just about as good as having made my first CW novice contact. The challenge is different, but the thrill is still great.
73,[/QUOTE]<span id='postcolor'>
darn it. now you've got me interested in signal processing CW.
Hey Walt,
If your program overcome the effects of the "Lake Erie Swing," a mis-adjusted bug, or an Iron Curtain Country operator, I think you have something there. Port it to the Wintel environment, and you'll retire a rich man, my friend! http://www.qrz.com/iB_html/non-cgi/emoticons/smile.gif
Call it the QLF2000.
Way cool.....
w8amd
12-13-2003, 09:12 AM
Like was said above, if you use a machine to send/receive you may as well be running rtty. The heart and soul of morse is in the human brain. Anything else is a sad imitation. Then again that is what makes it such a great mode.
w5alt
12-13-2003, 03:59 PM
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (w3sy @ Dec. 13 2003,02:43)</td></tr><tr><td id="QUOTE">If your program overcome the effects of the "Lake Erie Swing," a mis-adjusted bug, or an Iron Curtain Country operator, I think you have something there. Port it to the Wintel environment, and you'll retire a rich man, my friend! #http://www.qrz.com/iB_html/non-cgi/emoticons/smile.gif
Call it the QLF2000.
Way cool.....[/QUOTE]<span id='postcolor'>
Well, I may have to dig up my algorithms and give it a rework. Basically, I kept track of several parameters, including pulse lengths and space lengths. The algorithm then classified the lengths into various categories using fuzzy logic. Short pulses or spaces were considered to be noise and ignored. intermediate pulses were considered to be dits, long pulses were considered to be dahs. Intermediate spaces were between dit-dahs, long spaces between characters, longer spaces between words. By keeping track of the statistics over a window of time, it is possible to adjust the estimates based on the actual received characters and track speed changes fairly accurately. It was written in Forth to take advantage of the processing speed needed on the old machines I had. The algorithm needed a decent estimate of speed to get started and abrupt changes in speed would throw it off for a while, but slow changes in speed would be tracked just fine.
The basic procedure was to store a string of signal pulse lengths as a signal was copied. I used + integers for signal and - integers for no signal. #When a change from + to - or - to + was detected, the length was compared to the standard lengths and a fuzzy classification was done to determine whether the pulse was noise, dit, dah, or a type of space. When a character space was detected, the character was interpreted and printed in ASCII, then the statistics were updated to keep a running estimate of the various timing parameters.
What I found out was that the relative spacing and pulse lengths is the determining factor -no big surprise. When the ratio between dahs and dits drops below 2, humans have trouble deciding whether a dit or dah was sent, but the algorithm just classifies and still copies. Noise was fairly easy to remove due to the short random nature. QRM was another matter, though, since back then I didn't do any special DSP filtering. The statistics indicated that poorly sent code normally had a wider variation in timing than well sent code, but generally there were differences in the timing that could be detected. Swings were easily handled for the most part.
The problem with most machine interpreted Morse seems to be the use of too simple an algorithm that doesn't account for the variations and uses too simple a classification procedure.
I would think that writing software to copy hand sent CW would tickle the fancy of some young, sharp programmers looking for a real challenge.
73,
AE6IP
12-13-2003, 10:24 PM
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (AB8RP @ Dec. 13 2003,02:12)</td></tr><tr><td id="QUOTE">Like was said above, if you use a machine to send/receive you may as well be running rtty. #The heart and soul of morse is in the human brain. #Anything else is a sad imitation. #Then again that is what makes it such a great mode.[/QUOTE]<span id='postcolor'>
While true, the irony of this statement is that Samuel F. B. Morse designed a code that was originally meant to be sent and decoded by machine.
AE6IP
12-13-2003, 10:28 PM
W5ALT,
Thanks for the description of your approach. I haven't played with many of the current breed of CQ decoders, but the one I've played with the most is CWGET. It has an interesting problem with threshold detection, as it selects a particular input signal level to be its crossing point, to compensate for noise.
It would seem to me that your approach would require some very effective noise removal to avoid a similar problem. How did you set thresholds in the presence of high levels of noise?
w5alt
12-13-2003, 11:16 PM
Marty,
I couldn't get that sophisticated back then. I had a 1 MHz Z-80 CPU with a 1-1/2 bit ADC, if I recall! The threshold was whatever the ADC had - it was actually a cassette interface. Sampling speed was set totally by the software speed - counting CPU cycles for the instructions - very crude, but that was 20 years ago, before the PC was common. My noise removal algorithm was equally simple. If a signal (or space) was too short, it was considered noise and replaced by the preceeding signal level.
Noise and threshold detection didn't seem to be a major problem, but maybe my memory has faded. When I saved all the statistics and looked at histograms of the pulse and space lengths, the distribution of noise, dits, dahs, etc. was fairly obvious. If a signal was way down in the noise, that would have been more difficult, of course. But I wasn't trying to copy with poor SNR - just poorly sent code.
If I were to do it now, I would use some simple DSP filtering and smoothing ahead of the detection, along with some digital AGC. One could probably come up with an optimum threshold based on the SNR, but that's a guess. On any reasonable PC one could do a digital AGC, take the FFT, throw in a brick wall filter, equalize, then an inverse FFT with overlap-add, if one wanted to get fancy. Then do peak detection over a cycle or two and go on about decoding.
Or another approach, which is beyond me to implement at the moment, would be to train a neural net on a variety of poorly sent and low SNR CW signals. My hypothesis is that there are a low number of parameters that determine whether code can be copied or not, but the choice of parameters is not obvious at first glance to most people.
That would be an interesting exercize for one of those super sharp fellows who are kept off of HF by CW, doncha think? #http://www.qrz.com/iB_html/non-cgi/emoticons/wink.gif
Actually, I may tackle something like that one of these days when I get bored. I was thinking (I know it's dangerous) with the software defined radios, it should be fairly easy (in theory) to implement coherent CW and derive the timing from the signal itself.
Another problem I've been thinking about, but not tried anything yet, is to determine the SNR from the input signal plus noise. That would be valuable. Maybe someone has already come up with a good way to do that, but it's not an easy problem when the signal is below noise level. Every idea I've come up with involves somehow improving the SNR first, but that assumes you know what type of signal you're looking for and isn't necessarily very general.
73,
AE6IP
12-14-2003, 12:50 AM
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (w5alt @ Dec. 13 2003,16:16)</td></tr><tr><td id="QUOTE">Marty,
I couldn't get that sophisticated back then. I had a 1 MHz Z-80 CPU with a 1-1/2 bit ADC, if I recall! The threshold was whatever the ADC had - it was actually a cassette interface. Sampling speed was set totally by the software speed - counting CPU cycles for the instructions - very crude, but that was 20 years ago, before the PC was common. My noise removal algorithm was equally simple. If a signal (or space) was too short, it was considered noise and replaced by the preceeding signal level.
[/QUOTE]<span id='postcolor'>
Yeah, I remember those boxes. In the late 70s, I built distributed process control systems using z80s as embedded controllers to run the actuators and sample the metrics.
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">
Noise and threshold detection didn't seem to be a major problem, but maybe my memory has faded. When I saved all the statistics and looked at histograms of the pulse and space lengths, the distribution of noise, dits, dahs, etc. was fairly obvious. If a signal was way down in the noise, that would have been more difficult, of course. But I wasn't trying to copy with poor SNR - just poorly sent code.
[/QUOTE]<span id='postcolor'>
That sounds reasonable to me. #CWGET's problem tends to be most obvious when a noise burst causes the trailing edge to not get below the threshhold, so it thinks there's been signal for too long.
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">
If I were to do it now, I would use some simple DSP filtering and smoothing ahead of the detection, along with some digital AGC. One could probably come up with an optimum threshold based on the SNR, but that's a guess. On any reasonable PC one could do a digital AGC, take the FFT, throw in a brick wall filter, equalize, then an inverse FFT with overlap-add, if one wanted to get fancy. Then do peak detection over a cycle or two and go on about decoding.
[/QUOTE]<span id='postcolor'>
sounds reasonable. #CWGET does AGC and FIR bandpass filtering. I'm not sure if that makes much difference or not. #I do know that it gets really confused when I turn the narrow bandpass filter on the 706 on, though.
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">
Or another approach, which is beyond me to implement at the moment, would be to train a neural net on a variety of poorly sent and low SNR CW signals. My hypothesis is that there are a low number of parameters that determine whether code can be copied or not, but the choice of parameters is not obvious at first glance to most people.
[/QUOTE]<span id='postcolor'>
I'm not a big fan of neural nets. #It's been the experience of people I've worked with that by the time you know enough to know how to train the neural net, you know enough to write a heuristic that does as well but is more efficient.
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">
That would be an interesting exercize for one of those super sharp fellows who are kept off of HF by CW, doncha think? #http://www.qrz.com/iB_html/non-cgi/emoticons/wink.gif
[/QUOTE]<span id='postcolor'>
Indeed. http://www.qrz.com/iB_html/non-cgi/emoticons/wink.gif
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">
Actually, I may tackle something like that one of these days when I get bored. I was thinking (I know it's dangerous) with the software defined radios, it should be fairly easy (in theory) to implement coherent CW and derive the timing from the signal itself.
[/QUOTE]<span id='postcolor'>
Bwahahaha. #http://www.qrz.com/iB_html/non-cgi/emoticons/wink.gif
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">
Another problem I've been thinking about, but not tried anything yet, is to determine the SNR from the input signal plus noise. That would be valuable. Maybe someone has already come up with a good way to do that, but it's not an easy problem when the signal is below noise level. Every idea I've come up with involves somehow improving the SNR first, but that assumes you know what type of signal you're looking for and isn't necessarily very general.
[/QUOTE]<span id='postcolor'>
tough problem that. #I've never given it any though.
Marty
w5alt
12-14-2003, 02:56 AM
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (AE6IP @ Dec. 13 2003,20:50)</td></tr><tr><td id="QUOTE">sounds reasonable. #CWGET does AGC and FIR bandpass filtering. I'm not sure if that makes much difference or not. #I do know that it gets really confused when I turn the narrow bandpass filter on the 706 on, though.[/QUOTE]<span id='postcolor'>
That's odd. I remember that my software worked better with narrow fiters, as long as they didn't start ringing. And on the SDR-1000, I can set the filter to 25 Hz and adjust the squelch and it's pretty much crystal clear to the ear and on the waveform display until it gets down close to the noise level.
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote </td></tr><tr><td id="QUOTE">I'm not a big fan of neural nets. #It's been the experience of people I've worked with that by the time you know enough to know how to train the neural net, you know enough to write a heuristic that does as well but is more efficient.[/QUOTE]<span id='postcolor'>
Yep, I agree. I've seen some interesting applications where a neural net was used to help figure out the heuristics. In every practical application I've seen, though, a fuzzy logic based system would out-perform anything but a trivial neural net.
Another problem with neurals nets that I've seen is that they are really good at finding patterns .... even when no patterns exist.
73,
kc9dfj
12-14-2003, 05:04 AM
Hey Walt,
If you do port over the program, don't forget us Mac guys.
System 9 would be nice too. http://www.qrz.com/iB_html/non-cgi/emoticons/biggrin.gif
Lenny
w5alt
12-14-2003, 12:38 PM
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (kc9dfj @ Dec. 14 2003,01:04)</td></tr><tr><td id="QUOTE">If you do port over the program, don't forget us Mac guys.[/QUOTE]<span id='postcolor'>
What's this got to do with hamburgers?
This is great -- look at the inovation and the folks up for a challenge!
Keep it coming!
AE6IP
12-15-2003, 11:52 PM
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (w5alt @ Dec. 14 2003,05:38)</td></tr><tr><td id="QUOTE">http://www.qrz.com/iB_html/non-cgi/emoticons/wow.gif4--></span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (kc9dfj @ Dec. 14 2003,01http://www.qrz.com/iB_html/non-cgi/emoticons/wow.gif4)</td></tr><tr><td id="QUOTE">If you do port over the program, don't forget us Mac guys.[/QUOTE]<span id='postcolor'>
What's this got to do with hamburgers?[/QUOTE]<span id='postcolor'>
you mean you don't fry yours on your linear, during CW QSOs? http://www.qrz.com/iB_html/non-cgi/emoticons/wink.gif
w5alt
12-16-2003, 01:02 AM
</span><table border="0" align="center" width="95%" cellpadding="3" cellspacing="1"><tr><td>Quote (KC0LNU @ Dec. 15 2003,13:51)</td></tr><tr><td id="QUOTE">This is great -- look at the inovation and the folks up for a challenge!
Keep it coming![/QUOTE]<span id='postcolor'>
Innovation? I've been waiting for all of the young Techs to jump in and straighten me out.
We're discussing some old stuff done 20 years ago by a OF who passed the Morse test.
73,