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.
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.
“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!
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.
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.
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.
why using morse if exist crc and binary transmition (for example ax25 or mesh, aprs etc)
how send image trought morse code, camman , wake up, XXI decade
Why attempt to send an image thru morse?
Right tool for the right job.
Morse code is the only binary code that can be received and sent by the human senses. Without devices powered by the necessary electricity. Now imagine a major geological disaster, a giant tsunami, or a national power grid failure. Where are your aprs or ax25? They are simply waiting for electricity, and power generators have no more fuel.
I once put a pic in a qwerty keyboard and had it send morse code in real time.
I wonder how viable a mechanical version of that would have been their the technology available back then.
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.
Why doesn’t there seem to be an automated decoding program for qrss with upload to a central server as in WSPR? Perhaps there is software that I am unaware of. I can’t find any. With the easy availability of qrss tx kits such as the Hans Summer’s Ultimate 3 / 3s which sends QRSS if you want to, and an automated package which detects the signals and tabulates them, we could do away with the inconvenient screen grabber idea and easily see where we are being heard. I forsee really cheap stations based on a tiny automated beacon like the Ultimate 3/3s and a cheap Raspberry Pi plus RLT-SDR dongle with as yet uninvented software to decode the signals
Just an idea.
G0bzb – Op – Tony