Machine Decoding of Morse Code is an Unsolved Problem (

[@constantmachine]

Dave, I wanted to let you know that I'm currently working on a machine learning-based Morse code decoder. The primary tests have shown promising results. When it comes to decoding Morse code, context is everything, and leveraging machine learning really helps with that. The project will be open source, and I plan to share it with the community after the alpha phase.

[@presidentspilot]

Dave, you are TRULY a National Treasure! Where else would find such an ability to provide the historical evolution of Morse code in such a concise manner, than what you presented in this video!!! I am PROUD to be a Patreon of your site!! You certainly DESERVE it!! Best regards, Dave!! es TNX! Ron, K6PAM

[@bertsmith5569]

Dave you nailed it with “context” humans can comprehend words that are basically gibberish and can pull out the missing or corrupt letters from their “wetware” computers just scratch their proverbial heads. As a new CW op I appreciate the thoroughness of CW history you shared.

[@TomHammond-c4s]

Hi Dave, I am new to amateur radio and im the deep dive of learning the various forms of communication used including CW - your method of communicating the content is incredible. Thankyou for making my evening of research incredibly satisfying. For context, I am a 29 year old guy who has an incredibly busy life, and the delivery of this knowledge slowed time right down. Cheers. Happy New Years

[@VirtualLunacy]

Well, this is a topic close to my heart. I spent 15 years in the Navy (83-98) as a manual Morse intercept operator. Now, truth be told, The navy and air force (I was always at a joint location) were ALWAYS trying to find a way to get a machine to do our job. Alas, it never came to pass (during my time). To be fair, I only spent the first few years actively copying code for a living but the Navy kept trying to use machines to copy code. I think, at one point, they stood up system to replace humans but I don't know what became of that project. We (the seasoned ops) could identify a sender by his fist without hearing his callsign. I'm sure they could have developed a computer to do that but, as far as I know, they never did.

[@psychicspy]

Did you ever use PIM? Pilot Intercept Morse. I was a Navy CTT and loved to copy code. Caught a lot of frequency changes that way.

[@submarineradioman5535]

Thank you Dave - is your thesis available online or other source?

[@tiporari]

You have to treat it like language recognition just as we do with cloud computed speech recognition. Not as difficult. Just need a training data set with accurate translations, and train it to recognize.

[@sammiller6631]

How do you have a training data set of the empty spaces that vary from human to human?

[@RobertResearchRadios]

@@sammiller6631 in aggregate humans are predictable. Train on enough humans and it will work so long as you don't over fit.

[@sammiller6631]

@@RobertResearchRadios How do you solve the overfit problem?

[@RobertResearchRadios]

@@sammiller6631 Diverse training set and don't train too long/aggressively. That is the art part of what AI/ML Engineers do. But heck I'm an RF guy who can code, not someone with a deep background in AI, so take that with a grain of salt.

[@jamescollier3]

I've see ham radios that do this

[@osculant]

Glad you brought up AI, I was thinking the whole time this is the perfect application. I wonder, is there somewhere an existing archive of hand sent code with an accompanying text of what was intended to be sent? You would need some source material to train with. I also wonder how one might tackle being able to decode in real time. I imagine some context is required to increase the accuracy, maybe it starts by analyzing a small sample first? Certainly decoding it after the message is complete wouldn’t be too hard, relatively speaking.

[@peterdambier]

Learning prolog and lisp to play AI, I have seen a program called ELIZA that you can talk to. It looks like understanding you and giving meaningful replies. Sometimes 5 years old humans can get you answers that make you think twice, so does ELIZA. I have been thinking about morse input and output for ELIZA. I have been sending to computers. An electronic keyer is a big help. Chhers Peter DL2FBA

[@gahvno]

Good morning, Dave! Speaking as a corporate Radio Shack salesman and manager from 1981 to 1989 and very familiar with the TRS 80 Model 1 (I have several models of the Radio shack computers in a storage bin in my garage to this day ) I can agree that back at that time the ability to decode Morse either mechanically or remotely would indeed be challenging and certainly something of interest in a master's thesis...for that day. There's the term that's important here. Today, decoding and transcribing CW is terrifically and surprisingly accurate using something as simple as a free app that you can put on your Android phone. I'm working on my CW right now and will test for my Extra soon and I have two different apps on my phone that I use all the time to test myself as well as to simply satisfy my curiosity about the shorthand and what people are saying. There's no need to purchase anything for 150 bucks from MFJ when your phone and even affordable Chinese multi-band HF radios can do this task quite well. 73 de KK6BDW

[@k4adz]

Reference to the app you use?

[@jamescollier3]

yeah. I've see ham radios do this

[@gahvno]

Sure! I use two of them and one will sometimes work a little better than the other, - they're not identical in their accuracy - but they do good enough. One of them is called simply: Morse Code Reader and the other is: Morse Expert. Both of them are free and Morse Expert has the usual ads at the bottom that you can make go away for a couple of bucks. I just tune down to the CW part of the band, often 17 m, and tell the app to run and the text will show up on the screen. It does help if you have the ability to control your filters so the sound is nice and clean but it doesn't have to be perfect at all - It's often pretty faint - but In my case they work surprisingly well. I'm using these with a 7300. I have a little Xiegu G90 hooked up also and it has a built-in Morse code reader, but it is much more picky and you've really got to be tuned in and clean for it to work effectively, but it does work even with a person sending. There are other apps out there too. Just experiment until you find the one that works best for you,. But I use it almost entirely for human-sent CW and it's a lot of fun. Addendum: I'm running these apps with a Pixel 4 XL running the latest Android build. I've also tried them on my wife's Pixel 6 Pro and the apps work fine with their processor power. That being said, if you are running an old Motorola 5 with Android 8 or something similar, your mileage will probably vary.

[@thomasmaughan4798]

I've been working on a decoder. I'm okay at hearing Morse Code but a bit slow and rusty; I like to have a back-up copy machine in case I blank out momentarily trying to remember something. I am mindful of the amazing power of the human brain at this task, how you can choose one signal out of many because of its pitch and follow it. The machine equivalent is *correlation* which is a lot like a DFT (Discrete Fourier Transform) and starts out that way. Windows offers me 100 samples per second, that is to say, 1/100th of a second of the actual sample rate , so in that sample will be 6 cycles of 600 Hz, but more or fewer cycles of other Hz and they might even be stronger. So what you do is have a digitized sine wave in memory and you multiply each sample of the sine wave in memory with the incoming digitized audio. Because 1 times 1 is 1, and -1 times -1 is also 1, if there's a 600 Hz audio in the stream of data, and it is in phase, you'll get a pronounced peak energy for that 1/100th second window. Other audio frequencies will sometimes be in phase and sometimes not, and so will often completely cancel. How tight you can filter depends on the window size of 1/100th second or 10 milliseconds. It works out to about 100 Hz bandwidth. Obviously if you extend the window size you can narrow the bandwidth. So what this does is FILTER the stream and turn it into a new stream of sometimes stronger when 600 Hz is present, and sometimes weaker when it isn't. So you develop a running threshold that dynamically adjusts. Samples above that are a "1" and samples below that are a "0" and purified to make it so. Now you have a stream of simple 1's and 0's. The next task is to discover the "bit time". Look for a RUN of consecutive 1's and measure the length, that might be a dit and might be a dah, store in both. When you find a run that is longer, it becomes the new dah; and if shorter, it becomes the dit. Meanwhile, convert the stream of 100 Hz bits, into a stream of silent, dit and dah symbols. As soon as an intercharacter space comes along, the accumulated dit-dah register feeds into a binary tree decoder; if it starts "dit" then this branch and assume "E:, if "dah" then that branch and assume "T". If the second symbol is "dit" after dit, "I", if "dah" after dit, "A". Notice that we don't yet know or care if we hit the end of the symbol; we are building up a tree. When we have exhausted the symbols, whatever is in the character register is the decode. It is VERY fast and efficient. Quite a challenge to develop the code-tree. Having Windows chop the audio into blocks at 100 Hz rate isn't ideal, there are some things I would do; and to mimic human hearing, use the correlation idea but with *entire characters* rather than dits and dahs. You'd still have to figure out dot spacing, AND you'd need a flag for iambic precision or hand-sent Morse code. If Iambic then you can be a lot more precise in the correlator. What you would do in that scenario is the same as GPS decodes; all 24 or so GPS satellites transmit on the same exact frequency! But a correlator compares a pattern in memory with the data stream, and when it is in phase with that GPS signal, there will be an energy peak. So what you do is correlate longest symbol first; if you look just for "dit" you are going to see thousands of them. Look for dah-dah-di-di-dah-dah and if it matches, bingo! You know what it is. Not only that, but the longer correlation makes a much finer bandwidth, maybe 20 Hz. The challenge there is that your character size must be exact, so your dot spacing calculation must be exact and this is going to work only for iambic code most likely. But it would pull code out of a LOT of noise. Since CQ is easily recognized, the initialzation process would look for CQ at many different sizes (milliseconds for the while thing) and on recognizing it, population the dot and dash spacing and build the correlations for all of the characters. Existing decoders probably use FFT but that's not ideal and not very well nuanced. FFT has the advantage of being able to simultaneously decode MANY stations but its window size is very much a complicating factor; a wide window allows for precise separation of stations BUT you lose fine-grained dot spacing.

[@dakire]

I’m confident a speech to text model would be able to do it well given a good enough data set. If they can put subtitles on any KZbin video automatically, this problem can be solved as well.

[@naetuir]

As a long term programmer, I have often found myself wondering if machine learning could be used to train up a model. I haven't spent much time figuring out how to do machine learning, so it would be an interesting thing to take on as a little project... Maybe one day.

[@michaelweitzner9874]

My TS-590SG and KX3 can both decode Morse. Sometimes they are accurate. But even when that is the case there is a long delay in showing the output. So reading the output interferes with listening and aural recognition.

[@gmrjinx27]

I mentioned part of this on another post. In 1982 I exclusively used cw being I was a novice. The guy I talked to for 2.5 hours was using a keyboard and reader. He had no problem copying me. He was in his 80s. Don't remember his call. Just for curiosity I had him to gradually speed up. He said my normal speed I was sending was 11 wpm. He sped up to 25 wpm. I was able to copy most of it. Fir me, that was fast. N4IA

[@BartAnderson_writer]

Fascinating! It should be possible with pattern recognition software. Handwriting can be decoded, and faces and fingerprints recognized. CW should be much easier. As Dave said, the issue is whether there's a demand for such software. I could see an important use if normal communications are not possible, and only CW is viable (because of its simplicity).

[@peterdambier]

There are humans without eyes and ears. They can do cw. Russians have successfully used cw on their robot satellites. Cheers Peter DL2FBA

[@stargazer7644]

CW is often required on weak signal contacts due to its superior signal to noise ratio. It’s used a lot on ham microwave ops.

[@gumbykevbo]

Hey Dave. My dad was working for a Railroad (Denver & Rio Grande) in the signal department some time after when Morse communications were being decommissioned. I ended up with a couple of sounders. Actually had a line between me and the neighbor kid at one point. The neighbor never learned code, but he would try to send me messages off of a cheat sheet. I didn't know about American Morse back then, so we were attempting to use International code per my boyscout handbook. One minor error in you description of landline telegraphy is that a sounder makes a "click" when it pulls down, and sort of a "Clack" when the magnets release....sort of like the "tick" vs the "tock" the two pallets on in a clock escapement alternately engage the escape wheel. Another interesting detail is that a dispatcher in a railroad office would often have more than one line to monitor. They would take and mangle tobacco tins in various ways and attach them to the sounders giving each one a unique voice, so they didn't have to look to know which line they were hearing. My dad said they could typically copy while carrying on an in person conversation, and some could even copy two lines at once....kind of how a DXer can often pull multiple calls from a pileup. Typically the main line (the one train orders came in on) sounder would be mounted on an extenable arm (like a podcaster's microphone) so that it could be positioned close to the ear while typing the train orders on a "mill"....a "mill" was a type writer with caps only, and a sort of dot-matrix font that would still be readable with lots of carbon copies.

[@davidc5027]

I have been very happy with a program known as CWTY. It has its issues, but is the best I have tried so far.

[@cornbread-KO5RN]

Amazing how somethings that are so simple maybe altered but are never replaced

[@ClaudeJollet]

Dave! You have convinced me that decoding CW sent by humans is impossible with software, especially when one takes noise into account. Only "wetware" will eventually succeed with training. I was just about ready to pop for a MMX ZERO bundle for my IC-705 or my KX2 but decided to do my due diligence one last time. I found your video just in time to prevent me from making that mistake. I will have to keep my appetite for gadgets at bay.... until, as you say, someone comes up with an AI-assisted solution! Thank you!

[@thomasr.jackson2940]

An article by W4BQF (silent key) recommends a reader for high speed (>55wpm) Morse. He claims that while the readings are imperfect it still helps the brain decode correctly. I am still working on slow speed Morse, so I can’t say. Of possible interest, the last episode of the ARRL podcast Eclectic Tech featured David Kazdan, AD8Y talking about coherent CW. However, this is machine to machine code.

[@miketaylor6700]

I actually asked ChatGPT (Artificial Intelligence) this question: Morse Code is sent by humans, so there is variation in spacing. A human can pick up on the different spacing and understand the message, but typically computers have a hard time with Morse Code. What are your thoughts? This was the reply: You are correct that Morse code, as a communication system, relies on variations in spacing between dots, dashes, and gaps to convey information. Humans can often interpret these variations and understand the message, but computers, especially those with basic algorithms, may struggle to handle the nuances of Morse code. Traditional computers are typically designed to process digital data in a binary format, where timing and spacing variations are not easily discernible. Morse code, on the other hand, is an analog communication method that relies on variations in timing. This poses a challenge for computers to accurately interpret Morse code without proper algorithms or specialized hardware. However, with the advancement of technology and the development of specialized algorithms and software, computers can now analyze and decode Morse code more effectively. Signal processing techniques can be used to detect and differentiate between dots, dashes, and gaps, allowing computers to accurately interpret Morse code messages. There are also specific devices and software designed to facilitate Morse code communication with computers. For example, Morse code keyboards or input devices can be used to translate Morse code into digital text that computers can understand. Similarly, there are software programs that can decode Morse code signals captured from audio or visual inputs. In summary, while Morse code may pose challenges for traditional computers without the appropriate algorithms or hardware, advancements in technology have enabled computers to better handle Morse code and facilitate communication using this system.

[@permartin5819]

I wrote a morse decoder for my Commodore 64 long ago. It automatically adjusted speed based on what it was receiving. Detecting spaces versus letters within words might not be accurate, but all of the letters were present. It was not hooked up to a radio and therefore did not have to pull a signal out of the weeds or deal with fading. But basically it could follow someone's keying as long as they had some difference between dits and dahs. I really want to read your thesis to see what I am missing. The conditions you were tackling were probably a lot harder than what I was doing.

[@jamescollier3]

yeah I've see ham radios do this

[@Obeeewaan]

I find Morse Expert on my cell phone works pretty good at decoding lots of code while listening to nets while trying to improve my own code... and that's a free app on a medium grade cell phone.. It far surpasses anything from decades old hardware... just my two cents .🤔😎

[@DAVIDGREGORYKERR]

Can you use a tone decoder which will lock onto the tone from the speaker port and drive a SBC running an 8086 CPU.

[@reggiehodges6784]

I'm learning cw. I recently worked the 13 Colonies on cw .I used a decoding app on my phone , mainly to verify the station I was listening to. While not perfect it would work . Once I knew the station , I could handle the rest.

[@DAVIDGREGORYKERR]

What about decoding it in 8086 assembly language will be very fast (code will be found on the Rosetta Stone) website.

[@mattstosh6960]

Well said. In y opinion, most decoders on the market decode about 50% correctly. I've purchased and used most of them. CWGet is about the best in my opinion. I've also used the skimmers to decode on the waterfall and they seem to do a pretty good job. Not sure what software skimmers use. all this being said - I'm simply amazed at the capability of the human ear/ brain handshaking that goes on.

[@chrismeade]

David, We have a small group of folks who are bringing alive an authentic 1900's railway more code system. We have three railway stations set up with original keys, relays and sounders and they are doing demonstrations for visitors at Heritage Park in Calgary Alberta, Canada. Visitors find it quite facinating. We have no computers in sight.

[@davecasler]

Are you using "American Morse" (railroad Morse) or the Continental system we hams use on the air?

[@chrismeade]

@@davecasler American, we are emulating a 1900’s railway office.

[@davecasler]

@@chrismeade Super!

[@dysfunctional_vet]

i wondered where you were going with this, as i was exposed to automatic morse in the navy. i don't remember the speed, but it was fast, using adulator tape with india ink pens.

[@davecasler]

Actually, using pens to mark the signal goes back to the way S.F.B. Morse originally conceived of Morse code. Others would record the reception and play it back at a lower speed.

[@dysfunctional_vet]

@@davecasler the auto morse i remember was very fast, so they would have to play it back at about 40 or so to keep up with it. i used to be able to copy 15 with a stick and did okay, but i am rusty now.

[@edwardlittle9362]

Maybe a combo approach. A flexible model of dits and dahs that could generate one or more candidate interpretations (those four dits might've been an H or an ES) followed by a natural language processor trained on the vocabulary of amateur radio CW QSOs to choose from context the most probable interpretation. Which is kinda how the human mind does it.

[@bacca71]

I enjoyed that presentation of machine decoding CW very much.

[@orangetuono38]

Hi David, Lots of implementations pop up when searching. Are you saying they are all unusable or just based upon your greatly dated attempt? DSP and ML have come a very long way since days of Z80 Assembly Coding. Any thoughts on which of the implementations out there suck the least?

[@stargazer7644]

I would love to find a decoder that works on rainscatter CW contacts. Every one I’ve tried requires a tone to decode, where rainscatter is more of an amplitude varying hiss due to the doppler spreading on the signal.

[@davecasler]

Sounds interesting. I've not heard of rain scatter. You have a chance if the code is sent by machine, even more so if it's synchronized to UTC (dit boundaries all have well-known starting times).

[@grd4381]

Love your video and information 😊

[@tylersutcliffe871]

Cw skimmer works very well. Not perfect, but very good

[@BreakingPintMedia]

Great historical background on the challenges of machine-based morse code decoding. Context is the key (pun intended) to solving the problem and leveraging deep-learning can get us there. As it stands today, simple software can do a fairly good job so a motivated developer could likely write a reliable algorithm to interpolate a message's context. 73!

[@alainmichaud8992]

My remark is about the use of a "bug". Most CW operators today, including me, are still. in the learning process. Well this is a nice phrase, but what I relay mean is what you hear on the air is sometimes really really awful... People either send fast with a straight key or send slow with a mechanical "bug". In any case none the machine nor the brain can decode any of that stuff. Those shiny bugs are nice, but they can not be adjusted for slow speed. Their place is in the display case. Not to mention the problem of mechanical glitches. I propose the use of an electronic keyer (paddles) set for a moderate speed with longer spacing between characters. This way the beginners (we all are) have a chance to step in. The problem is in sending the code as well as reading it!

[@davecasler]

Ah, wait until you see my review. It turns out Vibroplex has a slow-speed attachment.

[@kennyking6325]

Hi Friends, I have an app on my phone called “Morse” I have sent and received with it, but the received was probably out of a machine coder. Thank you

[@BobDarlington]

This is an age old problem, even for the NSA. cwget is good unless it's a human using a straight key or bug. Even good CW ops sound drunk with a bug.

[@MrSparks54]

I've never used software to decode CW which is especially useless in weak signal conditions and like you say less than perfect character formation. I enjoy copying it in my head.

[@mrtechie6810]

Considering there are now weak signal modes that are machine decodable way down into the background noise, maybe solving this problem doesn't really matter much any more?

[@theroguetomato5362]

Assuming if even the spacing between characters is not exact, if the spacing between dots and dashs IS exact due to electronic keyers (even if the ratio isn't the same as what you normally use), it SHOULD be possible to create a reliable decoder. You shouldn't even have to adjust the speed. The software should be able to detect the speed and ratio of dots to dashes very quickly. It's a matter of just a little AI. Now, autodecoding hand keying is another story.

[@procerpat9223]

People in CW contests use keyers to send at 30wpm and you can use software to copy most of it

[@stevewilson5546]

Your Master's Thesis was a long time ago. Software and computer technology has advance considerably since then. Free morse decoders are available on the web. AI promises to do a much better job than any human. You need to revisit your conclusion in light of today's technology.

[@kenwilliams563]

My first attempt at decoding Morse was with a Commodore PET, I easily wrote software for decoding and sending RTTY, but struggled and gave up with Morse coded

[@timothyhall861]

It's NICE that there's something a machine can't do better!

[@AC3HT]

Thanks Dave. Great topic. 73, AC3HT

[@SpinStar1956]

Dave, thanks for helping Royce get his Ham Radio Ticket 🤣😂🤣

[@markojankovics7308]

David, Can't see your argument. CW is a binary code. Very suitable for software. Sure there can be problems with partly weak signals and inconsistency in code speed. The software I tested where not great in the job indeed. In my opinion real good developed software should work better than the human ear and brain and should be able to interact on the speed en signal strength issues I mentioned. Take QRSS, it decodes signals not distinguishable from the noise floor by human ears. MRP40 is on my to do list to try out. Anyone to reflect on me or correct me in case I'm very wrong??

[@markstevens933]

I think AEA PK 232 did Morse?

[@psychicspy]

Have you tried CHAT GPT? It's an AI program that can assist you in solving problems. Treat each character individually instead of trying to determine keying speed. And use AI to see if the characters make sense and then generate a corrected output if they dont.

[@andreschapero3615]

LOVED this video ! QSL from Santiago, Chile . 73

[@glenmartin2437]

Thank you, David. I struggle with Morse code. I am dyslexic and visually convert the dits to dashes and vice versa. When I realized that, I quit CW. I am starting again and will PERSEVERE. N0QFT

[@andrewd4890]

Dave, very interesting to hear your history of morse. I have read that the code invented by Morse or his employees used three element lengths rather than the two we now use. Is that right? I’ve been using tone based morse since about 1962. I have a kx3 and sometimes out of curiosity I set the menu to display the morse but it isn’t accurate enough with weak signals i can copy better by ear. The voltage level on my battery is more important on a hilltop so thats where the info display sits most of the time. Btw i copied a bit of the signal off your 7300, commenting on the heat. 73 VK1DA

[@opticalman1jeffkeokro741]

Hi Dave, great video. I keep promising myself that I will learn code. I was thinking as you were doing your video. That I wondered during world war 2 if you knew what the success rate was for students in the signal core where in learning the code. I imagine that they took a great deal of recruits and put them in code class that most likely had no interest in learning the code. In Sioux Falls, SD where I am from, there was a radio school base that during world was 2 is said to have trained most of the radio operators that were on the B-17's and B-24 during the war. i still find learning the code difficult and I want to learn it.

[@peterdambier]

How have you learned reading and writing your homework at school? Handwriting without looking at the text until it is finished was never a good idea. "Programming" cw in midi on a music synthesizer lmms and trying different speeds and musical instruments did help me a lot and is fun. Cheers Peter DL2FBA

[@raulcrudele1]

Radio Shack TRS80 Model I, my first computer 42 years ago!

[@cadiscase]

The key to decoding CW is to decode for words, words in context to other words before and after.

[@davecasler]

When you get that far in CW, it becomes a truly enjoyable passtime.

[@tunnelrabbit2625]

This is all the more reason we need to learn code.

[@markojankovics7308]

In addition whit my comment below; Computers are increasingly capable of working with complex audio input. Look how good spoken word is processed to control your computer or other hardware. You can order your phone by spoken word to send a mail to your mother with the message you give it.. I can talk to my phone in my own language en it will translate and speak even out the translation. Why would good designated software be incapable of handling a binary audio code pretty well?

[@georgemann9370]

Don't know how much bug or key code is sent today. I encourage new hams to try using electronic code methods. Many newbies get their start doing this.

[@greggweber9967]

Will the FCC ban hand made code so that people can't truly send? Imagine if the US Coast Guard was to ban small sail boats. What reason would they give for that?

[@ElectricityTaster]

Touchscreen qwerty keyboards use context and learn the operator to auto-correct. This can be done for morse code, there just is not much need for it.

[@sv1201]

Yaesu FTDX10 has a pretty good built-in CW decoder.

[@lyfandeth]

Betcha the cryptologists at the NSA could give you a working solution even accomodating and identifying the operator's hand. Just for the fun of the challenge. And assuming it hasn't been officially done and classified.

[@VirtualLunacy]

they could not do so reliably during my time. maybe they can now?

[@sarbog1]

Thank you, timing is important with stable clocks. Maybe some day AI trained on every CW sender can solve this problem.

[@peterdambier]

Does CW need to sound the way it does? I tried to send CW on a MIDI synthesizer (lmms). I had to use different instruments for different speeds. Looking at the audio file with audacity or a scope the sound I could hear best was unintelligible on the display. Cheeers Peter DL2FBA

[@qrplife]

Silly to spend more energy and bandwidth to sample the CW audio, ship it off to the “cloud”, and decode with “AI” than it took to send and receive the analog code in the first place. CW is for people, not machines.

[@super66craig]

If we only used QST or other materials for evaluating new technology for fitness of merchantability we would all still be pounding out code on old tube radios. The Europeans, especially the Germans take innovation and progress much farther than we have. Its gotten so bad with progress here that only a handful of innovations such as Joe Taylor has made can be credited for milestones. We are so backwards in this regard that we haven't even kept up with the Arab hams. They put up Es'hail 2 Q0 100 for that half of the globe's hams to stream 4k video to each with homebrew rigs and parabola while we natter on about making SSTV on HF as the pinnacle of technical prowess. So when I have questions about new gear or technology in Ham Radio the QST and the crusty old hams like me are the last people I would ask about state of the art. As a handicapped person I look forward to getting my own DARCA tested machine language coding CW device from MIMO. Not only does automated CW exist, it doesn't require an AI to work.

[@Blake-jl8lh]

This does not seem like that hard of a problem, all things considered. Yes I could send absolutely terrible code and it wouldn't get it because it's just wrong. But we have speech recognition software that accounts for pitch and speed changes as well as even accents. It's not easy but as compared to some of the current software solutions being made it seems very doable

[@sammiller6631]

speech recognition software is still _horrible_ with accents

[@Blake-jl8lh]

@@sammiller6631 with very heavy accents maybe but even as someone who has speech issue Alexa/Google understand me just fine

[@robbie.robertson]

Great video. After I retired I started coding Android apps, and after creating a morse trainer I wanted to see if I could also create a matching decoder... My first attempts at decoding where based on timings, but as you quite rightly state, there is always timing variations with 'manual morse' (ignoring signal variations for a moment). My solution was to base the decoding on comparisons between current and previous 'events', be that a 'digit' or space. This works pretty well, and pretty quick at adjusting for WPM changes. But it will always need a reasonable signal to noise ratio to perform 100%.

[@ARSSEUSA]

Respectfully disagree. FLDigi running on Linux decodes CW beautifully! Sometimes even signals too weak for the ear. Using the above in conjunction with "working" the radio has netted 7 continents for me on a tech ticket. Filtering is key :)

[@gahvno]

I agree with you completely. I think Dave is basing his answer on his experience from 40 years ago and things have, indeed, changed the lot since then.

[@BartVanAllen]

Yes - I find CWGet is maybe a wee bit better (so close) and the best is MRP40 from my own experience. I use them to try it improve my wet computer's decoding but the older I get the harder it is to do, my speed seems to be descending not ascending. Sending is even worse for me, the fingers do not react well anymore. I also agree that "working the radio" is the key - too many do not know how to zero in on the signal and then filter out all of the other noises.* Once that is done, decoding is fantastic even with sloppy hand keyed code. Even on my FT450D i can bring in very weak signals (under the noise floor without 'working the radio') and MRP40 will decode as well as CWGet/FLDigi often will But I want to get back to where I can use CW as a conversational tool like back when I was a Novice and Tech. * - funny how many do not know how to use the RF gain to benefit noise reduction and signal above noise floor optimizations - usually works better than what most on YT vids seem to do -

[@peterfournia3929]

Dave is correct but I am impressed at how well FLDIGI decodes hand sent Morse Code. Of course it must be sent from a good fist using paddles with a keyer. Operators using a bug tend to slaughter the spacing. There are many who do a good job with a straight key.

[@ARSSEUSA]

@@peterfournia3929 no..... he isn't and that's my point. I only hope the guy who submitted the question reads the comment section. 25 plus WPM bug ops decode FB on FLDigi/Linux just fine.

[@joefunk4552]

Not really, I wrote code in basic on a radio shack color computer in 1984 to read Morse code….worked great handled the various speeds automatically

[@stargazer7644]

But did it decode hand sent code? That’s his point. He’s not talking about various speeds of code. He’s talking about code with variable timing. Any decoder will work with perfect machine sent code, even old ones.

[@nfsusna]

The usdx chinese radios are absolutely terrible sounding, but their decoding is better than any computer or stand alone I've used bar none

[@smittyplusplus]

Shouldn't this be fairly-easily solvable with modern deep learning techniques? (edit: Oh, I see he mentions/acknowledges this near the end 👍)

[@Frankh77]

Alexa can probably do it? She understands all sorts of accents in different languages.

[@airborne63]

Yeah, it's called the human brain. I'm old, so I can only copy about 40 wpm, using my keyboard to automatically decode it.....with my touch-typing fingers, typing being a skill that I learned in High School, because I couldn't write fast enough to keep up with the received code. (also because the class was mainly cute girls 😁)

[@patrickpowers5995]

This is supposed to be routinely done by security services

[@donschneider7252]

Great ,,Dave appreciate the history. Ki7RJS

[@EricFullwood]

Why not just learn CW?

[@compsmith007]

I don't get it. Machine vision makes decoding cw look like child's play. Priorities? Profit? AOI in electronics manufacturing does incredible things (AOI operators, however...). Then again, that's the rub. And the solution. AI? Isn't that a bit overkill? Broaden focus and have the ability to re-evaluate.

[@robj1646]

Dear Dave. I appreciate and value your experience, technical knowledge and wisdom, but on this one you seem to be a bit outdated. Machine-decoding human-sent morse code is not a problem with current fast processing machines running appropriate software. It has only not been made available at a price that the average ham would want to pay. Self-learning software that adapts to the sender's handwriting, has been around for many years. I find that MRP40 does a reasonable job, though not perfect, but it is absurdly priced (USD 60). 73 de HA7RJA

[@davecasler]

Rob, many thanks for the information. I'll get it and report on it. 73

[@El_Porcho]

No doubt a machine learning algorithm could solve this problem; someone just needs to put the effort into it. But unlikely anyone will; why bother. BTW would you mind putting your camera on a stable mount? The moving around is unprofessional and makes me sea sick watching your videos. Thanks.

[@RobertResearchRadios]

Open Source CW Skimmer with AI/ML will definitely happen

[@clarksonjones6474]

This would be a great project for a grad student in a computer science program using artificial intelligence. AI would be very intuitive if trained on continuous CW skimmer for several months, possible even shorter. Love your videos Dave ! KO4VFS