Quick And Simple Morse Decoder - Hackaday

Skip to content

[Rostislav Persion] wrote a simple Morse Code decoder to run on his Arduino and display the text on an LCD shield. This is probably the simplest decoder possible, and thus its logic is pretty straightforward to follow. Simplicity comes at a price — changing the speed requires changing constants in the code. We would like to see this hooked up to a proper Morse code key, and see how fast [Rostislav] could drive it before it conks out.

In an earlier era of Morse code decoders, one tough part was dealing with the idiosyncrasies of each sender. Every operator’s style, or “fist”, has subtle variations in the timings of the dots, dashes, and the pauses between these elements, the letters, and the words. In fact, trained operators can recognize each other because of this, much like we can often recognize who is speaking on the phone just by hearing their voice. The other difficulty these decoders faced was detecting the signal in low signal-to-noise ratio environments — pulling the signal out of the noise.

A Morse decoder built today is more likely to be used to decode machine-generated signals, for example, debugging information or telemetry. This would more than likely be sent at fixed, known speeds over directly connected links with very high S/N ratios (a wire, perhaps). In these situations, a simple decoder like [Rostislav]’s is completely sufficient.

We wrote about a couple of Morse code algorithms back in 2014, the MorseDetector and the Magic Morse algorithm. While Morse code operators usually rank their skills by speed — the faster the better — this Morse code project for very low power transmitters turns that notion on its head by using speeds more suitably measured in minutes per word (77 MPW for that project). Have you used Morse code in any of your projects before? Let us know in the comments below.

Post navigation Automate The Farm With AcornThis Horrifying Robot Is Here To Teach You A Lesson

14 thoughts on “Quick And Simple Morse Decoder

  1. Yep. Morse makes great error beep codes, and a single letter is easy enough to be parsable even by muggles. (like “long short short short” = “B”attery)

    Reply
    1. IIRC, we got an SGI (late 1990s) that beeped out S-O-S when it needed attention.

      Reply
  2. Local guy who I have done some rework for makes this thing. https://preppcomm.com/

    It uses Morse code to act like 2 way paging or texting…has a 3w transmitter built in and can plug into higher power stuff.

    It is a pretty neat little device.

    Reply
  3. Traditionally, you’d have an audio filter and detector, maybe some agc or limiting, external to the computer.

    Buut some added some preprocessing, hardware to differentiate between dots and dashes.

    In Ham Radio magazine in later 1971, there was a CW decoder done without a computer, I can’t remember if it used ICs. Used a strip printer for output. Such decoders existed commercially, but that’s the only project I saw before software.

    Reply
  4. Here is my CW / PSK31 / PSK63 decoder from 2010, drawing around 2mA current, doing audio filtering on a MSP430 with no HW multiplier.

    https://www.youtube.com/watch?v=hLyVI3wtlz8 https://www.youtube.com/watch?v=HcxIgqx17Vw https://www.youtube.com/watch?v=2Aydo8dUZjM

    Runs on http://www.msp430launchpad.com/

    Source code https://sourceforge.net/projects/pocketdigi/files/decoder/msp430-decoder-1.2-src.zip/download

    Reply
  5. Old ticker tape machines had *mechanical* baudot decoders, which could’ve been adapted for morse also. (Imagine a motor spinning a drum synced with the baud rate, and the incoming bits trigger what part is facing the paper, followed by the whack of the hammer when the last bit is “decoded”.) (I restored one of these recently.)

    Reply
    1. Those mechanical decoders (much like the project described in the article) require pretty close speed control, in order for the receiver to sync with the transmitter and produce mostly-accurate output. Once you have that limitation, why use Morse code at all? Why not just use Baudot or six-bit ASCII?

      Reply
      1. before the program runs….. you could use some statistics to get an average dit dat duration…

        Reply
  6. “… changing the speed requires changing constants in the code […] one tough part was dealing with the idiosyncrasies of each sender. Every operator’s style, or “fist”, has subtle variations in the timings of the dots, dashes, and the pauses between these elements, the letters, and the words” …

    https://csdb.dk/release/?id=151742

    Check this one out… at various speeds and indiosyncrasies… ;-)

    Reply
  7. CQD.. The display must read CQD..

    Just kidding! 😁SOS is fine here, because that’s what most people know and most people would be able to send.

    Reply
  8. Neat project! And just in time for the SAQ transmission on Sunday, by the way!

    https://alexander.n.se/

    Reply
  9. Great job on Persion’s simple solution! I love how neat and simple it is! As a personal challenge, I spent a month or two trying my hand at an alternative to the decoder presented by WB7FHC and others and came up with an Arduino sketch that works great at cleaner 60 WPM code as well as slower hand sent code, and it automatically adjusts for speed. It requires only a good input from a tone discriminator or just a hand key. Up to this point I’ve worked mostly on the sketch and have work to do still on the electronics. Check this out: http://www.k4icy.com/cw_decoder.html

    Reply
  10. Nice. But we need neural network driven one! I saw a few papers but no actual project so far :(

    Reply
  11. And this will turn your voice into Morse Code. https://hackaday.com/2020/07/16/speech-to-morse-code-courtesy-of-google/

    Reply

Leave a ReplyCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Search Search for: Never miss a hack Follow on facebook Follow on twitter Follow on youtube Follow on rss Contact us Subscribe If you missed it
  • Why Can’t I 3D Print With Rubber?

    40 Comments
  • How Wind Nearly Took Down Boulder NTP

    26 Comments
  • Surviving The RAM Apocalypse With Software Optimizations

    94 Comments
  • Catching Those Old Busses

    29 Comments
  • Thorium-Metal Alloys And Radioactive Jet Engines

    36 Comments
More from this category Our Columns
  • Linux Fu: Compose Yourself!

    16 Comments
  • Know Audio: Microphone Basics

    27 Comments
  • Keebin’ With Kristina: The One With The Keyboard-Mouse, Again

    7 Comments
  • Hackaday Podcast: 2025 Holiday Placeholder Edition

    3 Comments
  • Keebin’ With Kristina: The One With The Ultimate Portable Split

    8 Comments
More from this category Search Search for: Never miss a hack Follow on facebook Follow on twitter Follow on youtube Follow on rss Contact us Subscribe If you missed it
  • Why Can’t I 3D Print With Rubber?

    40 Comments
  • How Wind Nearly Took Down Boulder NTP

    26 Comments
  • Surviving The RAM Apocalypse With Software Optimizations

    94 Comments
  • Catching Those Old Busses

    29 Comments
  • Thorium-Metal Alloys And Radioactive Jet Engines

    36 Comments
More from this category CategoriesCategories Select Category 3d Printer hacks Android Hacks Arduino Hacks ARM Art Artificial Intelligence Ask Hackaday ATtiny Hacks Battery Hacks Beer Hacks Biography blackberry hacks Business car hacks Cellphone Hacks chemistry hacks classic hacks clock hacks cnc hacks computer hacks cons contests cooking hacks Crowd Funding Curated Current Events Cyberdecks digital audio hacks digital cameras hacks downloads hacks drone hacks Engine Hacks Engineering Fail of the Week Featured Fiction firefox hacks FPGA g1 hacks Games google hacks gps hacks green hacks Hackaday Columns Hackaday links Hackaday Store Hackerspaces HackIt handhelds hacks hardware High Voltage History Holiday Hacks home entertainment hacks home hacks how-to Interest internet hacks Interviews iphone hacks ipod hacks Kindle hacks Kinect hacks laptops hacks Laser Hacks LED Hacks Lifehacks Linux Hacks lockpicking hacks Mac Hacks Machine Learning Major Tom Medical Hacks Microcontrollers Misc Hacks Multitouch Hacks Musical Hacks Netbook Hacks Network Hacks News Nintendo DS Hacks Nintendo Game Boy Hacks Nintendo Hacks Nintendo Wii Hacks Nook Hacks Original Art Palm Pre Hacks Parts PCB Hacks Peripherals Hacks Phone Hacks Playstation Hacks Podcasts Portable Audio Hacks Portable Video Hacks PSP Hacks Radio Hacks Rants Raspberry Pi Repair Hacks Retrocomputing Retrotechtacular Reverse Engineering Reviews Robots Hacks Roundup Science Security Hacks Skills Slider Software Development Software Hacks Solar Hacks Space Tablet Hacks Teardown Tech Hacks The Hackaday Prize Tool Hacks Toy Hacks Transportation Hacks Uncategorized Video Hacks Virtual Reality Weapons Hacks Wearable Hacks Weekly Roundup Wireless Hacks Xbox Hacks Our Columns
  • Linux Fu: Compose Yourself!

    16 Comments
  • Know Audio: Microphone Basics

    27 Comments
  • Keebin’ With Kristina: The One With The Keyboard-Mouse, Again

    7 Comments
  • Hackaday Podcast: 2025 Holiday Placeholder Edition

    3 Comments
  • Keebin’ With Kristina: The One With The Ultimate Portable Split

    8 Comments
More from this category Recent comments
  • effgee on Why Can’t I 3D Print With Rubber?
  • Greg A on Xcc700: Self-Hosted C Compiler For The ESP32/Xtensa
  • breestephany on Metalworking Hacks Add Functionality To Snap-On Tool Chest
  • ThisGuy on Building A Steam Loco These Days Is Nothing But Hacks
  • Mr Name Required on Building A Steam Loco These Days Is Nothing But Hacks
  • Süleyman Yasin Dundar on Building A Steam Loco These Days Is Nothing But Hacks
  • Paul on Bringing A Yagi Antenna To 915MHz LoRa
  • Joshua on The Many-Sprites Interpretation Of Amiga Mechanics
  • Andrew on Building A Steam Loco These Days Is Nothing But Hacks
  • Gumnos on Linux Fu: Compose Yourself!