![]() |
CW software decoder algorithm?
Dear all
I am looking for ideas for a software CW decoder with ASCII output. There are a number of programs published - what algorithms do these use in general? I presume the software would have to have some sort of PLL to select and filter a signal and then an adaptive algorithm to allow for sending operator error in keying, noise and variations in keying speed. I am looking for a solution which trades off accuracy for minimum codespace and speed. If necessary, some of the work could be done in hardware - eg I could limit and square up the audio waveform and present it the processor as digital level transitions, so AGC would not be an issue. Any ideas? Thanks in advance Richard |
On Tue, 30 Dec 2003 11:49:39 +0800, "Richard Hosking"
wrote: I am looking for ideas for a software CW decoder with ASCII output. There are a number of programs published - what algorithms do these use in general? There are two steps that you have complete: make a digital signal out of the received analog output - and decode it. Have a look at: http://wwwhome.cs.utwente.nl/~ptdebo...algorithm.html 73s OE1MWW Wolfgang |
On Tue, 30 Dec 2003 11:49:39 +0800, "Richard Hosking"
wrote: I am looking for ideas for a software CW decoder with ASCII output. There are a number of programs published - what algorithms do these use in general? There are two steps that you have complete: make a digital signal out of the received analog output - and decode it. Have a look at: http://wwwhome.cs.utwente.nl/~ptdebo...algorithm.html 73s OE1MWW Wolfgang |
Wolfgang
Thanks for your reply I am not very sophisticated mathematically and I have not studied communication theory. Your article is most helpful. However it looks as though it might be somewhat hard to implement in a small/slow codespace such as a microcontroller. (It may well be impossible to do this job in such a device.) Still I thought I would try. Off the top of my head I thought I would start with a hard limited audio signal, with transitions at digital hi/low level, rather than a sampled signal. This would obviously limit the signal to noise ratio, but I was not planning to use this for weak signal work. The clock/demodulation algorithm would then deal with the timing between transitions of the signal, rather than a spectral analysis. This would be relatively simple to implement with a timer to count the interval between transitions. The controller could track carrier freq with a Freq Locked Loop algorithm, over a limted range.(say 600-900 Hz) If there are no transitions or randomly timed transitions (noise), then the controller assumes a space Similarly, the controller tracks sending speed by timing the length of dots and dashes, and adjusting the algorithm to track this. This length could be initially acquired by timing an initial series of dots/dashes. The length would presumably fall into two groups, with the shorter length being dots. The average of these shorter "on" periods would be the bit rate. The controller could keep a moving average of the signal, discarding any "on" periods that are longer than say 2.0 times the current average. Finally, I would use the bit rate to time gaps (say) 2.5 times the bit rate to separate characters and decode them with a simple lookup table. No doubt there are lots of problems with this approach! I would be interetsed in your comments Richard Wolfgang K. Meister wrote in message ... On Tue, 30 Dec 2003 11:49:39 +0800, "Richard Hosking" wrote: I am looking for ideas for a software CW decoder with ASCII output. There are a number of programs published - what algorithms do these use in general? There are two steps that you have complete: make a digital signal out of the received analog output - and decode it. Have a look at: http://wwwhome.cs.utwente.nl/~ptdebo...algorithm.html 73s OE1MWW Wolfgang |
Wolfgang
Thanks for your reply I am not very sophisticated mathematically and I have not studied communication theory. Your article is most helpful. However it looks as though it might be somewhat hard to implement in a small/slow codespace such as a microcontroller. (It may well be impossible to do this job in such a device.) Still I thought I would try. Off the top of my head I thought I would start with a hard limited audio signal, with transitions at digital hi/low level, rather than a sampled signal. This would obviously limit the signal to noise ratio, but I was not planning to use this for weak signal work. The clock/demodulation algorithm would then deal with the timing between transitions of the signal, rather than a spectral analysis. This would be relatively simple to implement with a timer to count the interval between transitions. The controller could track carrier freq with a Freq Locked Loop algorithm, over a limted range.(say 600-900 Hz) If there are no transitions or randomly timed transitions (noise), then the controller assumes a space Similarly, the controller tracks sending speed by timing the length of dots and dashes, and adjusting the algorithm to track this. This length could be initially acquired by timing an initial series of dots/dashes. The length would presumably fall into two groups, with the shorter length being dots. The average of these shorter "on" periods would be the bit rate. The controller could keep a moving average of the signal, discarding any "on" periods that are longer than say 2.0 times the current average. Finally, I would use the bit rate to time gaps (say) 2.5 times the bit rate to separate characters and decode them with a simple lookup table. No doubt there are lots of problems with this approach! I would be interetsed in your comments Richard Wolfgang K. Meister wrote in message ... On Tue, 30 Dec 2003 11:49:39 +0800, "Richard Hosking" wrote: I am looking for ideas for a software CW decoder with ASCII output. There are a number of programs published - what algorithms do these use in general? There are two steps that you have complete: make a digital signal out of the received analog output - and decode it. Have a look at: http://wwwhome.cs.utwente.nl/~ptdebo...algorithm.html 73s OE1MWW Wolfgang |
On Tue, 30 Dec 2003 11:49:39 +0800, "Richard Hosking"
wrote: If necessary, some of the work could be done in hardware - eg I could limit and square up the audio waveform and present it the processor as digital level transitions, so AGC would not be an issue. Any ideas? Thanks in advance Richard Would also be interested, but have not experimented in this field since I used the Apple II computer. Good decoding was a problem, but also too often simple detectors were described. I did some experiments with slide-back detector which was originally constructed for two-tone RTTY (850Hz shift) and as such a good choice for single signal, but I couldn't see much difference from the ATC network used for RTTY Also had some good experience with MC1496, S042P similar detectors instead of using envelope detectors 73 Jan-Martin LA8AK http://home.online.no/~la8ak/c11.htm -- Amount of SPAM is so large that MailWasher must delete 99% of the incoming mails Cannot check every email manually. Please use intelligent title for email. Mails without titles or using just "hi" is deleted |
On Tue, 30 Dec 2003 11:49:39 +0800, "Richard Hosking"
wrote: If necessary, some of the work could be done in hardware - eg I could limit and square up the audio waveform and present it the processor as digital level transitions, so AGC would not be an issue. Any ideas? Thanks in advance Richard Would also be interested, but have not experimented in this field since I used the Apple II computer. Good decoding was a problem, but also too often simple detectors were described. I did some experiments with slide-back detector which was originally constructed for two-tone RTTY (850Hz shift) and as such a good choice for single signal, but I couldn't see much difference from the ATC network used for RTTY Also had some good experience with MC1496, S042P similar detectors instead of using envelope detectors 73 Jan-Martin LA8AK http://home.online.no/~la8ak/c11.htm -- Amount of SPAM is so large that MailWasher must delete 99% of the incoming mails Cannot check every email manually. Please use intelligent title for email. Mails without titles or using just "hi" is deleted |
"Richard Hosking" wrote in message u... Wolfgang Thanks for your reply I am not very sophisticated mathematically and I have not studied communication theory. Your article is most helpful. However it looks as though it might be somewhat hard to implement in a small/slow codespace such as a microcontroller. (It may well be impossible to do this job in such a device.) Still I thought I would try. Off the top of my head I thought I would start with a hard limited audio signal, with transitions at digital hi/low level, rather than a sampled signal. This would obviously limit the signal to noise ratio, but I was not planning to use this for weak signal work. The clock/demodulation algorithm would then deal with the timing between transitions of the signal, rather than a spectral analysis. This would be relatively simple to implement with a timer to count the interval between transitions. The controller could track carrier freq with a Freq Locked Loop algorithm, over a limted range.(say 600-900 Hz) If there are no transitions or randomly timed transitions (noise), then the controller assumes a space Similarly, the controller tracks sending speed by timing the length of dots and dashes, and adjusting the algorithm to track this. This length could be initially acquired by timing an initial series of dots/dashes. The length would presumably fall into two groups, with the shorter length being dots. The average of these shorter "on" periods would be the bit rate. The controller could keep a moving average of the signal, discarding any "on" periods that are longer than say 2.0 times the current average. Finally, I would use the bit rate to time gaps (say) 2.5 times the bit rate to separate characters and decode them with a simple lookup table. No doubt there are lots of problems with this approach! I would be interetsed in your comments Richard Many years back, I built a TTL deocder from a QST article- by Petway?? Anyway he used a number of storage registers- one for average dot length, one for average character spece length and one for average word space length. After initialization, a clock would run at the receipt of each element. The count was then compared to previous average- if the clock count was larger, the average was incremented by 1; shorter, it was decremented by 1. The machine did a surprisingly good job on hand sent Morse. Although the hardware technology is antiquated by today's standards, the algorithm was elegant and easily understood. I would estimate this article (2 or 3 parter) appeared in QST from the early 70's. GL, Dale W4OP |
"Richard Hosking" wrote in message u... Wolfgang Thanks for your reply I am not very sophisticated mathematically and I have not studied communication theory. Your article is most helpful. However it looks as though it might be somewhat hard to implement in a small/slow codespace such as a microcontroller. (It may well be impossible to do this job in such a device.) Still I thought I would try. Off the top of my head I thought I would start with a hard limited audio signal, with transitions at digital hi/low level, rather than a sampled signal. This would obviously limit the signal to noise ratio, but I was not planning to use this for weak signal work. The clock/demodulation algorithm would then deal with the timing between transitions of the signal, rather than a spectral analysis. This would be relatively simple to implement with a timer to count the interval between transitions. The controller could track carrier freq with a Freq Locked Loop algorithm, over a limted range.(say 600-900 Hz) If there are no transitions or randomly timed transitions (noise), then the controller assumes a space Similarly, the controller tracks sending speed by timing the length of dots and dashes, and adjusting the algorithm to track this. This length could be initially acquired by timing an initial series of dots/dashes. The length would presumably fall into two groups, with the shorter length being dots. The average of these shorter "on" periods would be the bit rate. The controller could keep a moving average of the signal, discarding any "on" periods that are longer than say 2.0 times the current average. Finally, I would use the bit rate to time gaps (say) 2.5 times the bit rate to separate characters and decode them with a simple lookup table. No doubt there are lots of problems with this approach! I would be interetsed in your comments Richard Many years back, I built a TTL deocder from a QST article- by Petway?? Anyway he used a number of storage registers- one for average dot length, one for average character spece length and one for average word space length. After initialization, a clock would run at the receipt of each element. The count was then compared to previous average- if the clock count was larger, the average was incremented by 1; shorter, it was decremented by 1. The machine did a surprisingly good job on hand sent Morse. Although the hardware technology is antiquated by today's standards, the algorithm was elegant and easily understood. I would estimate this article (2 or 3 parter) appeared in QST from the early 70's. GL, Dale W4OP |
On Tue, 30 Dec 2003 20:10:53 +0800, "Richard Hosking"
wrote: Wolfgang Thanks for your reply Richard, I will dig into my paper piles - I do have a very small and tiny Basic source with a flow chart, published years ago. I wanted to write this, but time went by and in the meantime ready built software is available in the net. Stay tuned - I will post it. 73s and DX for 2004 Wolfgang OE1MWW |
On Tue, 30 Dec 2003 20:10:53 +0800, "Richard Hosking"
wrote: Wolfgang Thanks for your reply Richard, I will dig into my paper piles - I do have a very small and tiny Basic source with a flow chart, published years ago. I wanted to write this, but time went by and in the meantime ready built software is available in the net. Stay tuned - I will post it. 73s and DX for 2004 Wolfgang OE1MWW |
Disclaimer: I've never decoded morse in my life, so most of what I write is
educated guessing. For my master's thesis I built a receiver that demodulated 400 baud MSK. The RF chain delivered a signal centered around 2kHz to a 68HC11 which sampled at 6400Hz and demodulated the data entirely in software -- and it only had 2k bytes of code space. Granted, it was all in assembly, and it used 94% of the available processor time to do it, but it did work. In spite of having some really ugly compromises in the signal processing (the sampling rate was really too low, and the only "multiply" was to add, not add, or subtract from an accumulator) the receiver had performance within a dB of the theoretical optimum. I think with something modern like an AVR or a PIC a 16-baud OOK signal should be possible (fun, too). OK, so you still have the problem with the math. Consider using not one, but two comparators to square up your signal, so a "non-signal" rarely gets above the threshold. You're back to needing AGC (at least to set the comparator), but you can close the loop in your software by looking at the comparator outputs for the right signatures (too much output = too low threshold, too little output = too high threshold), and set the threshold from the uP. With a good signal to noise ratio this should have a nice broad center to it that'll be easy to find. With a good narrow CW filter your signal to noise ratio will get better... Once your threshold is set you can integrate the "buzz" from the comparators to see if you're receiving a carrier. You should probably integrate for some period of time (the length of the fastest code you want to receive would be good, it'd give you a sorta-kinda-matched filter) and take the presense of signal 1/2 of the time to indicate the transmitter is "on". I like the idea of using the dibits to form a PLL, but for receiving bad code at an unknown rate you'd probably be better off making a little histogram of the on and off times of the code. You should be able to see two peaks in the histogram for "on" corresponding to dot and dash, and three for "off" corresponding to intra-letter, inter-letter and inter-word spacing. At this point you can start looking for dashes, dots, and spaces (maybe going back over your data to catch the beginning of the message, if you have enough RAM) and decoding words. You could also estimate the speed of the code that you're receiving and feed it back to your KSMF (that's kinda-sorta-matched filter, of course) for better noise figure. Once you have your stream of dashes, dots, inter-charater and inter-word spaces you can separate the charaters, look them up in a table and just reject anything that doesn't seem to fit. I suspect that your performance would be pretty good at this point, and if not the theoretical ne-plus-ultra of decoders it would be better at receiving the lousy senders than Wofgang's. "Richard Hosking" wrote in message u... Wolfgang Thanks for your reply I am not very sophisticated mathematically and I have not studied communication theory. Your article is most helpful. However it looks as |
Disclaimer: I've never decoded morse in my life, so most of what I write is
educated guessing. For my master's thesis I built a receiver that demodulated 400 baud MSK. The RF chain delivered a signal centered around 2kHz to a 68HC11 which sampled at 6400Hz and demodulated the data entirely in software -- and it only had 2k bytes of code space. Granted, it was all in assembly, and it used 94% of the available processor time to do it, but it did work. In spite of having some really ugly compromises in the signal processing (the sampling rate was really too low, and the only "multiply" was to add, not add, or subtract from an accumulator) the receiver had performance within a dB of the theoretical optimum. I think with something modern like an AVR or a PIC a 16-baud OOK signal should be possible (fun, too). OK, so you still have the problem with the math. Consider using not one, but two comparators to square up your signal, so a "non-signal" rarely gets above the threshold. You're back to needing AGC (at least to set the comparator), but you can close the loop in your software by looking at the comparator outputs for the right signatures (too much output = too low threshold, too little output = too high threshold), and set the threshold from the uP. With a good signal to noise ratio this should have a nice broad center to it that'll be easy to find. With a good narrow CW filter your signal to noise ratio will get better... Once your threshold is set you can integrate the "buzz" from the comparators to see if you're receiving a carrier. You should probably integrate for some period of time (the length of the fastest code you want to receive would be good, it'd give you a sorta-kinda-matched filter) and take the presense of signal 1/2 of the time to indicate the transmitter is "on". I like the idea of using the dibits to form a PLL, but for receiving bad code at an unknown rate you'd probably be better off making a little histogram of the on and off times of the code. You should be able to see two peaks in the histogram for "on" corresponding to dot and dash, and three for "off" corresponding to intra-letter, inter-letter and inter-word spacing. At this point you can start looking for dashes, dots, and spaces (maybe going back over your data to catch the beginning of the message, if you have enough RAM) and decoding words. You could also estimate the speed of the code that you're receiving and feed it back to your KSMF (that's kinda-sorta-matched filter, of course) for better noise figure. Once you have your stream of dashes, dots, inter-charater and inter-word spaces you can separate the charaters, look them up in a table and just reject anything that doesn't seem to fit. I suspect that your performance would be pretty good at this point, and if not the theoretical ne-plus-ultra of decoders it would be better at receiving the lousy senders than Wofgang's. "Richard Hosking" wrote in message u... Wolfgang Thanks for your reply I am not very sophisticated mathematically and I have not studied communication theory. Your article is most helpful. However it looks as |
"Richard Hosking" wrote in message
u... I am not very sophisticated mathematically and I have not studied communication theory. Your article is most helpful. However it looks as though it might be somewhat hard to implement in a small/slow codespace such as a microcontroller. (It may well be impossible to do this job in such a device.) In the August '98 QST, IK3OIL published an article on a CW decoder based on a PIC16F84, which may well be, by today's standards, the most limited microcontroller in use by hobbyists. (Well, I suppose you could tie one hand behind your back by adding a Basic compiler on top of it or something like that!) That particular device, while far from perfect, works a lot better than the various PC based programs that I've tried. Last I looked, he still had most of the information on his web site. I know others have done work to improve on his program, but I don't know of any of that work that has been published. One nasty feature is that a long series of dahs can greatly confuse his algorithm and it can take a while to recover from that. Were you to implement his algorithm in a '628 or something like that, or even to simply replace the rather lengthy code he has around displaying the speed with a little more work on the algorithm, I'm sure it could be improved. He did use an external decoder to recognize the CW signal, a 567 or something of that ilk. Some folks have worked on that end, too. It seems like there should be a better approach, but I haven't seen anything dramatically better. ... |
"Richard Hosking" wrote in message
u... I am not very sophisticated mathematically and I have not studied communication theory. Your article is most helpful. However it looks as though it might be somewhat hard to implement in a small/slow codespace such as a microcontroller. (It may well be impossible to do this job in such a device.) In the August '98 QST, IK3OIL published an article on a CW decoder based on a PIC16F84, which may well be, by today's standards, the most limited microcontroller in use by hobbyists. (Well, I suppose you could tie one hand behind your back by adding a Basic compiler on top of it or something like that!) That particular device, while far from perfect, works a lot better than the various PC based programs that I've tried. Last I looked, he still had most of the information on his web site. I know others have done work to improve on his program, but I don't know of any of that work that has been published. One nasty feature is that a long series of dahs can greatly confuse his algorithm and it can take a while to recover from that. Were you to implement his algorithm in a '628 or something like that, or even to simply replace the rather lengthy code he has around displaying the speed with a little more work on the algorithm, I'm sure it could be improved. He did use an external decoder to recognize the CW signal, a 567 or something of that ilk. Some folks have worked on that end, too. It seems like there should be a better approach, but I haven't seen anything dramatically better. ... |
Thanks to all for your replies
With regard to Tim's idea of the dual comparators, I presume these would in "series". For the integration idea to work, the comparators would obviously have to have their gain set carefully, otherwise random noise would integrate to 1/2 time and be interpreted as signal. The circuit I was thinking of would set the DC comparison point at halfway (say 2.5V for a 5V logic level) with the DC level of the signal also at 2.5V. I presume in your system the uP controls the comparison voltage and sets it with a DAC and the signal DC level is 0V. Is this correct? In my idea I was going to use the timing of signal transitions in a hard limited signal. If there were several transitions with the same timing, I would presume a "tone" was present and signal was being received. Randomly timed transitions would indicate noise.The uP could follow the tone as an adaptive filter to track carrier freq. Once carrier is received the uP then captures dot, dash and space timing with the histogram as you describe. If a moving average filter of these is kept, then the uP could track sender speed variations. Anyone have ideas as to the theoretical performance of such an idea or any potential problems? Thanks again Richard Tim Wescott wrote in message ... Disclaimer: I've never decoded morse in my life, so most of what I write is educated guessing. For my master's thesis I built a receiver that demodulated 400 baud MSK. The RF chain delivered a signal centered around 2kHz to a 68HC11 which sampled at 6400Hz and demodulated the data entirely in software -- and it only had 2k bytes of code space. Granted, it was all in assembly, and it used 94% of the available processor time to do it, but it did work. In spite of having some really ugly compromises in the signal processing (the sampling rate was really too low, and the only "multiply" was to add, not add, or subtract from an accumulator) the receiver had performance within a dB of the theoretical optimum. I think with something modern like an AVR or a PIC a 16-baud OOK signal should be possible (fun, too). OK, so you still have the problem with the math. Consider using not one, but two comparators to square up your signal, so a "non-signal" rarely gets above the threshold. You're back to needing AGC (at least to set the comparator), but you can close the loop in your software by looking at the comparator outputs for the right signatures (too much output = too low threshold, too little output = too high threshold), and set the threshold from the uP. With a good signal to noise ratio this should have a nice broad center to it that'll be easy to find. With a good narrow CW filter your signal to noise ratio will get better... Once your threshold is set you can integrate the "buzz" from the comparators to see if you're receiving a carrier. You should probably integrate for some period of time (the length of the fastest code you want to receive would be good, it'd give you a sorta-kinda-matched filter) and take the presense of signal 1/2 of the time to indicate the transmitter is "on". I like the idea of using the dibits to form a PLL, but for receiving bad code at an unknown rate you'd probably be better off making a little histogram of the on and off times of the code. You should be able to see two peaks in the histogram for "on" corresponding to dot and dash, and three for "off" corresponding to intra-letter, inter-letter and inter-word spacing. At this point you can start looking for dashes, dots, and spaces (maybe going back over your data to catch the beginning of the message, if you have enough RAM) and decoding words. You could also estimate the speed of the code that you're receiving and feed it back to your KSMF (that's kinda-sorta-matched filter, of course) for better noise figure. Once you have your stream of dashes, dots, inter-charater and inter-word spaces you can separate the charaters, look them up in a table and just reject anything that doesn't seem to fit. I suspect that your performance would be pretty good at this point, and if not the theoretical ne-plus-ultra of decoders it would be better at receiving the lousy senders than Wofgang's. "Richard Hosking" wrote in message u... Wolfgang Thanks for your reply I am not very sophisticated mathematically and I have not studied communication theory. Your article is most helpful. However it looks as |
Thanks to all for your replies
With regard to Tim's idea of the dual comparators, I presume these would in "series". For the integration idea to work, the comparators would obviously have to have their gain set carefully, otherwise random noise would integrate to 1/2 time and be interpreted as signal. The circuit I was thinking of would set the DC comparison point at halfway (say 2.5V for a 5V logic level) with the DC level of the signal also at 2.5V. I presume in your system the uP controls the comparison voltage and sets it with a DAC and the signal DC level is 0V. Is this correct? In my idea I was going to use the timing of signal transitions in a hard limited signal. If there were several transitions with the same timing, I would presume a "tone" was present and signal was being received. Randomly timed transitions would indicate noise.The uP could follow the tone as an adaptive filter to track carrier freq. Once carrier is received the uP then captures dot, dash and space timing with the histogram as you describe. If a moving average filter of these is kept, then the uP could track sender speed variations. Anyone have ideas as to the theoretical performance of such an idea or any potential problems? Thanks again Richard Tim Wescott wrote in message ... Disclaimer: I've never decoded morse in my life, so most of what I write is educated guessing. For my master's thesis I built a receiver that demodulated 400 baud MSK. The RF chain delivered a signal centered around 2kHz to a 68HC11 which sampled at 6400Hz and demodulated the data entirely in software -- and it only had 2k bytes of code space. Granted, it was all in assembly, and it used 94% of the available processor time to do it, but it did work. In spite of having some really ugly compromises in the signal processing (the sampling rate was really too low, and the only "multiply" was to add, not add, or subtract from an accumulator) the receiver had performance within a dB of the theoretical optimum. I think with something modern like an AVR or a PIC a 16-baud OOK signal should be possible (fun, too). OK, so you still have the problem with the math. Consider using not one, but two comparators to square up your signal, so a "non-signal" rarely gets above the threshold. You're back to needing AGC (at least to set the comparator), but you can close the loop in your software by looking at the comparator outputs for the right signatures (too much output = too low threshold, too little output = too high threshold), and set the threshold from the uP. With a good signal to noise ratio this should have a nice broad center to it that'll be easy to find. With a good narrow CW filter your signal to noise ratio will get better... Once your threshold is set you can integrate the "buzz" from the comparators to see if you're receiving a carrier. You should probably integrate for some period of time (the length of the fastest code you want to receive would be good, it'd give you a sorta-kinda-matched filter) and take the presense of signal 1/2 of the time to indicate the transmitter is "on". I like the idea of using the dibits to form a PLL, but for receiving bad code at an unknown rate you'd probably be better off making a little histogram of the on and off times of the code. You should be able to see two peaks in the histogram for "on" corresponding to dot and dash, and three for "off" corresponding to intra-letter, inter-letter and inter-word spacing. At this point you can start looking for dashes, dots, and spaces (maybe going back over your data to catch the beginning of the message, if you have enough RAM) and decoding words. You could also estimate the speed of the code that you're receiving and feed it back to your KSMF (that's kinda-sorta-matched filter, of course) for better noise figure. Once you have your stream of dashes, dots, inter-charater and inter-word spaces you can separate the charaters, look them up in a table and just reject anything that doesn't seem to fit. I suspect that your performance would be pretty good at this point, and if not the theoretical ne-plus-ultra of decoders it would be better at receiving the lousy senders than Wofgang's. "Richard Hosking" wrote in message u... Wolfgang Thanks for your reply I am not very sophisticated mathematically and I have not studied communication theory. Your article is most helpful. However it looks as |
Remark: The interface via a LPT port is possible by PortIO or other
free add ons to access direct the LPT port in Windows. Visual Basic or Powerbasic could be used. The PEEK statement has to be replaced by the equivalent access methode from the language to the port. Please double check, could be there are some errors due to OCR conversion. 73s Wolfgang World of the Brass Pounders: Receive the Morse Code the easy way by ROBERT L KURTZ 4 SANTA BELLA RD ROLLING HILLS CA 90274 scanned from an very old paper copy by OE1MWW WOLFGANG MEISTER WENHARTGASSE 27/5 WIEN A-1210 AUSTRIA email: oe1mww(at)qsl.net (replace the (at) with an @) Original article starts he A great feature of a personal-computing hobby is that it can be used to work with other hobbies. A case In point is this little program to decode and print out Morse code. I original-ly wrote this in machine lan-guage for my KIM system, where it took up less than one page, and finally decided to try it in BASIC. Even though the program looks simple, it has some unusual surprises, such as self-adaptive adjustment for changes in code speed. In addi-tion, the influence of changes in dash or dot length is weighted so that they must occur five or six times in succession be-fore the computer decides that there has been a bona fide speed change. As a result, an occasional "bad" character will not mess up your copy; the printout is extremely stable and the copy is relatively foolproof. The program also detects the end of the word and prints out a space, if required. The program's memory needs are minor—just a little over 1K of RAM is required. The program is written in Microsoft BASIC on the KIM computer, but should operate with any relatively fast BASIC. From a hardware standpoint, if your CRT or printer will go to 300 baud, this program will provide excellent copy of Morse code, up to 15 or 20 words per minute. If your terminal operates up to 1200 baud, it will follow the Morse transmissions to well over 30 words per minute. Loading the Program Input the program exactly as written, even though some of the instructions may seem re-dundant. It is written this way to save operating time—a very important consideration when you are dealing with fast-acting dots and dashes. Lines 10,20, 60, 110 and 150 instruct a PEEK to location 5888 (decimal). In the KIM com-puter, this is a peripheral input address at 1700 (hex). This loca-tion reads a total of eight input ports as an eight-bit word. The AND 1 on lines 10,20,60, 110 and 150 assures that the computer is only reading the port to which the incoming Morse is connected obviously, this must be changed to fit your particular system. In addition, the program assumes that when a dot or a dash occurs, a logic 0 appears on the input port. This is in agreement with a "key down" shorting the input port to ground, and also in agreement with the hardware interface cir-cuit described later. If your hookup provides a logic 1 during a dot and a dash, then lines 11, 30, 70,120 and 160 must be changed so that all IF A = 1 statements should read IF A = 0, and vice versa. Program Description Fig. 1 is a simplified flow diagram of the program. The initialization routine (lines 1 through 6) sets the lookup table that will permit the printout of the proper character. The pro-gram then waits for a key down to occur (lines 10 and 11). The first part of the operating pro-gram (lines 20 through 80) mea-sures the length of time that the key is down and compares this with the stored value for the length of a dash. If the key is raised in less than one-half of the stored dash time, the computer writes a dot into the dot register (line 30) and goes to the second part of the operating program. If the key remains down longer than one-half of the dash time, a dash is stored in the dash register (line 50), and the value of the dash time is up-dated with a one-to-four weight-ing (line 80). This is accom-plished by multiplying the old value of the dash time by four, adding the new value, and then dividing by five. As a result, the stored value of the dash time cannot change drastically from character to character, and the copy is not susceptible to er-rors from erratic sending habits. The second part of the pro-gram (lines 100 through 190) measures the length of time the key is up. if it's up less than one-half of the dash length, the program assumes that the character is not complete and no printout is provided (see lines 100 through 130). If the key is up longer, the program jumps to line 300, the print-character subroutine. If the key is up longer than twice the dash length, the program assumes that a word is complete and a "space" is printed (lines 170 and 180). Lookup Table The heart of the program is the algorithm that counts the dots and dashes and develops a number used to look up the ac-tual character to be printed, in other words, each combination of dots and dashes in Morse code has a discrete number that commands a given character to be printed. This algorithm has three conditions as listed in Table 1. Steps 1 and 2 keep repeating until the character is complete. When the program detects a key-up period longer than one-half of a dash length, it is assumed that the character is complete and step 3 is accomplished (lines 300 to 430). The manner in which the lookup number for the letter D is formed is shown in Example 1. Interlace Hardware Fig. 2 shows a typical circuit for connecting your radio re-ceiver to the computer. The NPN transistor is an R/C coupled audio amplifier con-nected to a type 567 phase-lock loop circuit. The free-running frequency of the phase-lock loop is set by the values of the capacitor and resistor con-nected to pins 5 and 6 of the 567, and is approximately 2000 Hz. The capacitors on pins 1 and 2 of the PLL adjust the bandwidth to about 100 Hz, and the LED serves as a tuning in-dicator—that is, It will start blinking when the signal Is in the center of this narrow band-pass. This circuit is compatible with the program, as written, In that the output signal goes to a logic 0 when a dot or a dash occurs. The circuit shown is not my original idea, but has appeared in numerous publications; you may have your own favorite circuit that you would like to use. As long as you maintain the same output logic (a 0 for a dot or dash), there will be no problem. Incidentally, the circuit has another unique application. Since it is only activated by audio signals over a fairly nar-row band, it can also be used to key an audio oscillator set to any frequency desired. When Morse CW comes in amidst a jumble of other signals, the phase-lock loop picks out the signal you want and keys the audio oscillator... and that is all you hear. A full-scale outline of the circuit board is shown in Fig. 3. Adjusting the Program One of the advantages of writing this program in BASIC is the ease with which the com putatlon constants can be changed. For Instance, you may wish to experiment with different algorithms to detect whether a key-down signal is a a dot or a dash... to take care of "swlng-fisters." This can be accomplished easily by chang-ing the factor in line 40 from (.5*0) to (.2S*C or .75*C). By the same token, the constants In lines 111 and 151 can be changed to provide more lee-way for the formation of char-acters and spaces. 1. If the input signal is a dash: A. Double the values in the dot and dash registers. B. Add 1 to the dash register (see line 50). 2. If the input signal is a dot: A. Double the values in the dot and dash registers. B. Add 1 to the dot register (see line 30). 3. if the character is complete: A. Double the value in the dash register. B. Add the dash and dot registers to obtain the lookup number. C. Clear the dot and dash registers. Table 1. EXAMPLE: D = -.. initial conditions: Dot register = 0, Dash register = 0. First period: Input a dash. 2 times dash register =2x0 = 0. 2 times dot register =2x0 = 0. Add 1 to dash register =1+0 = 1. Summary: dash register = 1, dot register = 0. Second period: Input a dot. 2 times dash register =2x1 = 2. 2 times dot register =2x0 = 0. Add 1 to dot register =1+0 = 1. Summary: dash register = 2, dot register = 1. Third period: Input a dot. 2 times dash register =2x2 = 4. 2 times dot register =2x1 = 2. Add 1 to dot register =1+2 = 3. Summary: dash register = 4, dot register = 3. End of Character—-determine lookup number for D. 2 times dash register =2x4 = 8. Add dot register and dash register =8 + 3 = 11. Answer: D = 11. Example 1. BASIC Code: 1 REM MORSE CODE READER - WRITTEN BY R. KURTZ - W6PR0 2 RESTORE 3 PRINT CHR$(26) : REM CAN DELETE - PUTS CURSOR AT TOP OF PAGE 5 DIM A$(100) 6 FOR N=l TO 100 : READ A$(N) : NEXT N 10 A=PEEK(5888) AND 1 11 IF A=l THEN 10 15 B=0 20 A=PEEK(5888) AND 1:B=B+10 30 IF A=l THEN C*((5*C)+(2*B))/6:DO=2*DO:DA-2*DA:DO=DO+l:GOTO 100 40 IF B(.5*C) THEN 20 50 DO=2*DO:DA=2*DA:DA=DA+1 60 A=PEEK(5888) AND 1:B=B+10 70 IF A=0 THEN GOTO 60 80 C=((4*C)+B)/5 100 B=0 110 A-PEEK(5888) AND 1 111 B=B+10 120 IF A=0 THEN GOTO 15 130 IF B(.5*C) THEN GOTO 110 140 GOSUB 300 150 A=PEEK(5888) AND 1 151 B=B+10 160 IF A=0 THEN GOTO 15 170 IF B(2*C) THEN GOTO 150 180 PRINT " "; 190 GOTO 10 300 DA=DA*2 310 D=DA+DO 330 IF D100 THEN D=100 340 PRINT A$(D); 350 DA=0:DO-0 360 RETURN 400 DATA E,T,I,A,N,M,S,U,R,W,D,K,G,O,H,V,F,-,L,-,P,J,B,X,C 410 DATA Y,Z,Q,-,-,5,4,-,3,-,-,-,2,-,-,-,-,-,-,-,1,6,-,/,- 420 DATA -,-,-,-,7,-,-,-,8,-,9,0,-,-,-,-,-,-,-,-,-,-,-,-,? 430 DATA -,-,-,-,-,-,-,-,.,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,- The circuit for the interface is scanned and can be requested via email from oe1mww(at)qsl.net |
Remark: The interface via a LPT port is possible by PortIO or other
free add ons to access direct the LPT port in Windows. Visual Basic or Powerbasic could be used. The PEEK statement has to be replaced by the equivalent access methode from the language to the port. Please double check, could be there are some errors due to OCR conversion. 73s Wolfgang World of the Brass Pounders: Receive the Morse Code the easy way by ROBERT L KURTZ 4 SANTA BELLA RD ROLLING HILLS CA 90274 scanned from an very old paper copy by OE1MWW WOLFGANG MEISTER WENHARTGASSE 27/5 WIEN A-1210 AUSTRIA email: oe1mww(at)qsl.net (replace the (at) with an @) Original article starts he A great feature of a personal-computing hobby is that it can be used to work with other hobbies. A case In point is this little program to decode and print out Morse code. I original-ly wrote this in machine lan-guage for my KIM system, where it took up less than one page, and finally decided to try it in BASIC. Even though the program looks simple, it has some unusual surprises, such as self-adaptive adjustment for changes in code speed. In addi-tion, the influence of changes in dash or dot length is weighted so that they must occur five or six times in succession be-fore the computer decides that there has been a bona fide speed change. As a result, an occasional "bad" character will not mess up your copy; the printout is extremely stable and the copy is relatively foolproof. The program also detects the end of the word and prints out a space, if required. The program's memory needs are minor—just a little over 1K of RAM is required. The program is written in Microsoft BASIC on the KIM computer, but should operate with any relatively fast BASIC. From a hardware standpoint, if your CRT or printer will go to 300 baud, this program will provide excellent copy of Morse code, up to 15 or 20 words per minute. If your terminal operates up to 1200 baud, it will follow the Morse transmissions to well over 30 words per minute. Loading the Program Input the program exactly as written, even though some of the instructions may seem re-dundant. It is written this way to save operating time—a very important consideration when you are dealing with fast-acting dots and dashes. Lines 10,20, 60, 110 and 150 instruct a PEEK to location 5888 (decimal). In the KIM com-puter, this is a peripheral input address at 1700 (hex). This loca-tion reads a total of eight input ports as an eight-bit word. The AND 1 on lines 10,20,60, 110 and 150 assures that the computer is only reading the port to which the incoming Morse is connected obviously, this must be changed to fit your particular system. In addition, the program assumes that when a dot or a dash occurs, a logic 0 appears on the input port. This is in agreement with a "key down" shorting the input port to ground, and also in agreement with the hardware interface cir-cuit described later. If your hookup provides a logic 1 during a dot and a dash, then lines 11, 30, 70,120 and 160 must be changed so that all IF A = 1 statements should read IF A = 0, and vice versa. Program Description Fig. 1 is a simplified flow diagram of the program. The initialization routine (lines 1 through 6) sets the lookup table that will permit the printout of the proper character. The pro-gram then waits for a key down to occur (lines 10 and 11). The first part of the operating pro-gram (lines 20 through 80) mea-sures the length of time that the key is down and compares this with the stored value for the length of a dash. If the key is raised in less than one-half of the stored dash time, the computer writes a dot into the dot register (line 30) and goes to the second part of the operating program. If the key remains down longer than one-half of the dash time, a dash is stored in the dash register (line 50), and the value of the dash time is up-dated with a one-to-four weight-ing (line 80). This is accom-plished by multiplying the old value of the dash time by four, adding the new value, and then dividing by five. As a result, the stored value of the dash time cannot change drastically from character to character, and the copy is not susceptible to er-rors from erratic sending habits. The second part of the pro-gram (lines 100 through 190) measures the length of time the key is up. if it's up less than one-half of the dash length, the program assumes that the character is not complete and no printout is provided (see lines 100 through 130). If the key is up longer, the program jumps to line 300, the print-character subroutine. If the key is up longer than twice the dash length, the program assumes that a word is complete and a "space" is printed (lines 170 and 180). Lookup Table The heart of the program is the algorithm that counts the dots and dashes and develops a number used to look up the ac-tual character to be printed, in other words, each combination of dots and dashes in Morse code has a discrete number that commands a given character to be printed. This algorithm has three conditions as listed in Table 1. Steps 1 and 2 keep repeating until the character is complete. When the program detects a key-up period longer than one-half of a dash length, it is assumed that the character is complete and step 3 is accomplished (lines 300 to 430). The manner in which the lookup number for the letter D is formed is shown in Example 1. Interlace Hardware Fig. 2 shows a typical circuit for connecting your radio re-ceiver to the computer. The NPN transistor is an R/C coupled audio amplifier con-nected to a type 567 phase-lock loop circuit. The free-running frequency of the phase-lock loop is set by the values of the capacitor and resistor con-nected to pins 5 and 6 of the 567, and is approximately 2000 Hz. The capacitors on pins 1 and 2 of the PLL adjust the bandwidth to about 100 Hz, and the LED serves as a tuning in-dicator—that is, It will start blinking when the signal Is in the center of this narrow band-pass. This circuit is compatible with the program, as written, In that the output signal goes to a logic 0 when a dot or a dash occurs. The circuit shown is not my original idea, but has appeared in numerous publications; you may have your own favorite circuit that you would like to use. As long as you maintain the same output logic (a 0 for a dot or dash), there will be no problem. Incidentally, the circuit has another unique application. Since it is only activated by audio signals over a fairly nar-row band, it can also be used to key an audio oscillator set to any frequency desired. When Morse CW comes in amidst a jumble of other signals, the phase-lock loop picks out the signal you want and keys the audio oscillator... and that is all you hear. A full-scale outline of the circuit board is shown in Fig. 3. Adjusting the Program One of the advantages of writing this program in BASIC is the ease with which the com putatlon constants can be changed. For Instance, you may wish to experiment with different algorithms to detect whether a key-down signal is a a dot or a dash... to take care of "swlng-fisters." This can be accomplished easily by chang-ing the factor in line 40 from (.5*0) to (.2S*C or .75*C). By the same token, the constants In lines 111 and 151 can be changed to provide more lee-way for the formation of char-acters and spaces. 1. If the input signal is a dash: A. Double the values in the dot and dash registers. B. Add 1 to the dash register (see line 50). 2. If the input signal is a dot: A. Double the values in the dot and dash registers. B. Add 1 to the dot register (see line 30). 3. if the character is complete: A. Double the value in the dash register. B. Add the dash and dot registers to obtain the lookup number. C. Clear the dot and dash registers. Table 1. EXAMPLE: D = -.. initial conditions: Dot register = 0, Dash register = 0. First period: Input a dash. 2 times dash register =2x0 = 0. 2 times dot register =2x0 = 0. Add 1 to dash register =1+0 = 1. Summary: dash register = 1, dot register = 0. Second period: Input a dot. 2 times dash register =2x1 = 2. 2 times dot register =2x0 = 0. Add 1 to dot register =1+0 = 1. Summary: dash register = 2, dot register = 1. Third period: Input a dot. 2 times dash register =2x2 = 4. 2 times dot register =2x1 = 2. Add 1 to dot register =1+2 = 3. Summary: dash register = 4, dot register = 3. End of Character—-determine lookup number for D. 2 times dash register =2x4 = 8. Add dot register and dash register =8 + 3 = 11. Answer: D = 11. Example 1. BASIC Code: 1 REM MORSE CODE READER - WRITTEN BY R. KURTZ - W6PR0 2 RESTORE 3 PRINT CHR$(26) : REM CAN DELETE - PUTS CURSOR AT TOP OF PAGE 5 DIM A$(100) 6 FOR N=l TO 100 : READ A$(N) : NEXT N 10 A=PEEK(5888) AND 1 11 IF A=l THEN 10 15 B=0 20 A=PEEK(5888) AND 1:B=B+10 30 IF A=l THEN C*((5*C)+(2*B))/6:DO=2*DO:DA-2*DA:DO=DO+l:GOTO 100 40 IF B(.5*C) THEN 20 50 DO=2*DO:DA=2*DA:DA=DA+1 60 A=PEEK(5888) AND 1:B=B+10 70 IF A=0 THEN GOTO 60 80 C=((4*C)+B)/5 100 B=0 110 A-PEEK(5888) AND 1 111 B=B+10 120 IF A=0 THEN GOTO 15 130 IF B(.5*C) THEN GOTO 110 140 GOSUB 300 150 A=PEEK(5888) AND 1 151 B=B+10 160 IF A=0 THEN GOTO 15 170 IF B(2*C) THEN GOTO 150 180 PRINT " "; 190 GOTO 10 300 DA=DA*2 310 D=DA+DO 330 IF D100 THEN D=100 340 PRINT A$(D); 350 DA=0:DO-0 360 RETURN 400 DATA E,T,I,A,N,M,S,U,R,W,D,K,G,O,H,V,F,-,L,-,P,J,B,X,C 410 DATA Y,Z,Q,-,-,5,4,-,3,-,-,-,2,-,-,-,-,-,-,-,1,6,-,/,- 420 DATA -,-,-,-,7,-,-,-,8,-,9,0,-,-,-,-,-,-,-,-,-,-,-,-,? 430 DATA -,-,-,-,-,-,-,-,.,-,-,-,-,-,-,-,-,-,-,-,-,-,-,-,- The circuit for the interface is scanned and can be requested via email from oe1mww(at)qsl.net |
On Fri, 02 Jan 2004 14:44:02 GMT, Wolfgang K. Meister
wrote: line 350 should be 350 DA=0:DO=0 |
On Fri, 02 Jan 2004 14:44:02 GMT, Wolfgang K. Meister
wrote: line 350 should be 350 DA=0:DO=0 |
All times are GMT +1. The time now is 02:40 AM. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
RadioBanter.com