Raspberry Pi Learns Slow Morse Code

It wasn’t long ago that you needed to know Morse code to be a ham radio operator. That requirement has gone in most places, but code is still useful and many hams use it, especially hams that like to hack. Now, hams are using the Raspberry Pi to receive highly readable Morse code using very low power. The software is QrssPiG and it can process audio or use a cheap SDR dongle.

There are a few reasons code performs better than voice and many other modes. First, building transmitters for Morse is very simple. In addition, Morse code is highly readable, even under poor conditions. This is partly because it is extremely narrow bandwidth and partly because your brain is an amazing signal processor.

Like most communication methods, the slower you go the easier it is to get a signal through. In ham radio parlance, QRS means “send slower”, so QRSS has come to mean mean “send very slowly”. So hams are using very slow code, and listening for it using computerized methods. Because the data rate is so slow, the computer has time to do extreme methods to recover the signal — essentially, it can employ an extremely narrow filter. Having a QRSS signal detected around the world from a transmitter running much less than a watt is quite common. You can see a video introduction to the mode from [K6BFA] and [KI4WKZ], below.

So how slow is slow? The [VA3LK] beacon, for example, sends an element — not a word or a character — every 90 seconds!  That’s about .013 words per minute and supports a filter bandwidth of about .033 Hz. This is much more narrow than even the sharpest filter you’d use for regular Morse code operation.

A common practice is to employ frequency shift keying (FSK) for QRSS. In this scheme, a dot and a dash are the same lengths, but on slightly different frequencies. One would not listen to these signals as they are frustratingly slow. They can be sped up in software (after you receive them, of course), but most people read it visually from the screen or use software to decode it.

We’ve looked at QRSS before using PCs. Having a receiver on a headless Raspberry Pi will make it easier to build automated receivers or other non-user applications. We’ve also seen Raspberry Pi’s send QRSS before.

9 thoughts on “Raspberry Pi Learns Slow Morse Code

  1. A minor correction: FSK does not involve sending dots and dashes at different frequencies; it involves sending marks and spaces at different frequencies, with the “mark” corresponding to the times when the key is down, and “space” when the key is up. The dots and dashes are both marks, but of different lengths. This can be seen in the first part of the video shown.

    Having said that, it IS possible to use three frequencies, one for dot, a second for dash, and a third for space. The third state is necessary to separate characters from each other. I haven’t heard of this being done, but that of course doesn’t mean it isn’t being done; that’s just not what we’re seeing in the video.

    1. “it IS possible to use three frequencies, one for dot, a second for dash, and a third for space. The third state is necessary to separate characters from each other. I haven’t heard of this being done”

      I think it’s been tried once or twice years ago but nothing was gained from it as far as FSK is concerned. However, this (and higher orders) are common in QPSK and QAM. As a direct example, 8-PSK or 8-QAM encode 8 states as 3 bits (000-111).

      In addition, as a non-radio example, you should check out “Tri-nary” and the Trinary Computer: as the name states, it uses 3 states (-1,0,+1) on each line rather than only two. Several were built in the earlier days of computers but the complexity wasn’t considered worth it in the end. A direct descendant in programming is Octal Notation (0,1,2,3,4,5,6,7,10…).

      Hope this helps!

  2. Wonder how it copes with hand sent morse, that was the main challenge I faced back in the early 90’s when I wrote software for the amiga in m68k which did the same. I spent most of my effort coding in ways to cope with different timing errors introduced by human operators, and it sent morse also with the odd timing error deliberately introduced that some old school operators told me made it sound like a fist, not a computer, which they liked a lot.
    Its also pretty similar hardware to coping with any digital signals once they are rendered into tones, so not a big jump to decoding rtty and fsk etc with a suitable set feeding it the signals.

    1. RTTY would be easier to reliably decode, since the bit times are consistent. But I think it would take longer to send complete messages since at the minimum, RTTY using a 5-bit code such as Baudot requires seven bit times – one for start bit, then five data bits, then one stop bit.

      In the example shown, “K6BFA” in Morse code requires 52 dot periods, but this could be reduced to 43 dot periods if the code was relaxed to using two bit periods for a dash or an inter-character space, whereas this would take 35 elements in Baudot. So never mind – RTTY (FSK using Baudot) is actually more efficient than Morse, since it doesn’t require spaces between each of the elements. If it took five minutes to transmit “K6BFA” in strict Morse, that’s 300 seconds / 52 dot periods = 5.7 seconds per element. The same element rate in Baudot would get the message sent in 202 seconds, or about 3-1/2 minutes. So if Morse code isn’t dead, maybe it should be.

      Based on this, I think that the only application for Morse code would be where it absolutely has to be sent by hand, i.e., for some reason microprocessors were not available.

      I’ll throw this in, though: originally, Baudot was sent using a set of five buttons, and the operators had to know the 5-bit codes for each character. There were no “keyboards”. However, from the start, Baudot receivers printed on a paper strip, so nobody ever had to be able to “read” Baudot. Just the same, with some basic TTL logic, the original Baudot button boards could be implemented, along with five lamps on the receiver side, so this could “easily” be done without even microprocessors.

      1. The answer lies in the reason QRSS exists in the first place: ultra-narrow bandwidth which means minimum detectable signal can also be very low. QRSS was invented just before the ultra-narrow FSK modes that dominate that sector of ham radio today. *ALL* of them rely on what you said at the very beginning about bit times: both transmitter and receiver need to be synchronized to less than a second (way more sloppy than, say, HAVEQUICK, but doable with NTP and without GNSS / LORAN / etc) so that the transition times are known in advance to the receiver.

        OTOH, as you say, the biggest reason to know Morse is that it is human readable (with training) and can be sent and received with just about anything, anywhere.

    1. I can think of a system where firm keypresses would have worked it. By having something like 2 telephone dials, one was 5 dots the other 5 dashes, and the key levered each to the right position and tipped a detent so one played after the other. So each letter would push the dials back the right number of dots or dashes, then either dots or dashes would go first, according to detent, and when it had “unwound” all the way it would let the other one go.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s