I recently inherited a key on board (KOB) telegraph that my late grandfather used to practice Morse code with when he was a kid (Figure 1). A little bit of curiosity of how it would work and a little bit of displeasure from seeing it sit and collect dust, I began a journey to resurrect the old machine and develop some software to bring it into the digital age. If you’re eager to see the final result, or just don’t want to read, skip to the end for a video demonstration.

From Telegraph Lore, a KOB set “consists of a leg style key and a telegraph sounder attached to a wooden base. The key and sounder are connected in series, and the connections to the telegraph wire are made to the two binding posts at the rear of the board. This makes for a reasonably compact portable set. Most KOBs found today are ‘practice sets’. A practice set is a relatively cheaply made KOB intended for practicing the sending and receiving of Morse. Common practice sets may be distinguished from professional sets by the three binding posts. Thus three wires connected the two sets. This allowed the use of dry cell batteries without quickly draining them as would occur with a closed circuit telegraph.”

The telegraph, along with Morse code, was invented in the early 1800s and provided the first form of rapid, long-distance communication. From a communication standpoint, Morse code is much less sensitive to poor signal conditions than voice, yet still comprehensible to humans without a decoding device. It remained popular until the mid 1900s, until other communication technologies gained appeal. The last US commercial telegraph service, operated by Western Union, was still used until 2006, and India’s state-owned telecom company, BSNL, continued its telegraph service until 2013. However, many amateur radio operators as well as aeronautical navigational aids, such as VORs and NDBs, still use Morse code.

The Cypher

Each Morse code symbol represents a character (A-Z, 0-9, symbols, and prosigns) and is represented by a unique sequence of dots and dashes (or dits and dahs) (Figures 2 and 3). The duration of a dah is three times the duration of a dit. Each dit or dah is followed by a short silence, equal to the dit duration. Characters are separated by a space equal to three dits (one dah) and words are separated by a space equal to seven dits. This entails that although a particular element can be of any duration of time, the ratio of time between elements must be consistent to be properly translated.

Deus Ex Machina

By connecting a 5-volt DC power source, I could produce those satisfying click-clack click-clacks, but it was missing something. I desired the authenticity of actually transmitting a signal over wire. So, I pulled out 400 feet of cat5 cable I had, from recent experiments with sensors and Mycodo in an artificial bat hubernacula, and recorded the first long-distance transmission this telegraph may have communicated in decades, or ever (Figure 4).

The same night, while discussing Morse code with a friend, we came upon the topic of what would be the fastest possible telegraph transmission by a human. To answer this, we first needed to know the fastest sustainable tempo a human could produce. I connected the telegraph to my Raspberry Pi and quickly wrote a Python program, beatbybeat, with the first function being a beat per minute (bpm), or tempo, detector.

Upon wiring the telegraph to the GPIO and starting the program, the first issue presented itself. Each press and release of the telegraph knob would often register as multiple presses by the program. This is what’s known as bounce. This occurs because of the physical properties of the metal contacts completing the circuit, in this case the upper contact (hammer) and the lower contact (anvil) of the telegraph. Because these two pieces of metal have mass, they have a tendency to bounce off each other when closing and opening the circuit, before coming to rest (Figure 5). There have been significant engineering advancements in button design that mechanically reduce bounce, however the telegraph was one such device deigned and built in the pre-digital era, when bounce was of little concern.

These bounces occur at fractions of a second. This is not normally an issue if the switch is powering a load, such as a light or a fan. However, as an input to a digital counter, where measurements occur at the microsecond-level or faster, this can pose a problem. The two most common solutions to prevent bounce, or debounce the signal, is through hardware and software. Usually only one method is sufficient to eliminate bounce, however certain high-precision applications may call for both.

The simplest hardware solution utilizes an RC (resistor-capacitor) circuit to swamp out the bounce (Figure 6). The slowed charging of the capacitor by resistor one, when the button is pressed, smooths out the drastic changes in voltage caused by bounce. The second resistor in an RRC circuit slowly drains the capacitor after the circuit is broken by the switch, reducing bounce when the button is let go. Multiplying the resistance value by the capacitance value will yield the RC time constant. Values of R and C are picked so the RC value is longer than the bounce time. Typical RC values are between 0.001 and 0.1 seconds (1 to 100 milliseconds), however the desired resolution and button used should be considered when designing the circuit.

The software solution employs a wait period after the first press or depress signal is detected, effectively ignoring any further signal changes until the delay period has passed (Figure 7). Just like the hardware debouncer, the software debouncer will need a value of wait time greater than the bounce time. I was able to completely remove bounce from the telegraph through software alone, with as little as 10 – 30 milliseconds of delay. Considering it was extremely difficult to tap a tempo lower than 90 milliseconds per beat, this more than acceptable for my application. For more information on bouncing and debouncing, check out The Ganssle Group’s Guide to Debouncing or HackaDay’s Debounce your Noisy Buttons.

#!/usr/bin/python
import RPi.GPIO as GPIO
import time

sleep_time = 0.001
count = 0
gpio = 26

GPIO.setmode(GPIO.BCM)
GPIO.setup(gpio, GPIO.IN, pull_up_down=GPIO.PUD_UP)

# Wait for the button to be pressed the first time while 
GPIO.input(gpio):
    time.sleep(sleep_time)

while True:
    count += 1
    print('Button Press {}!'.format(count))

    button_duration = int(round(time.time()*1000)) # Store current time in milliseconds
    # Wait while the button is pressed
    # Or while the duration of elapsed time is less than the debounce_delay
    while (GPIO.input(gpio) == False or
           int(round(time.time()*1000)) - button_duration < debounce_delay):
        time.sleep(sleep_time)

    button_duration = int(round(time.time()*1000)) # Store current time in milliseconds
    # Wait while the button is unpressed
    # Or while the duration of elapsed time is less than the debounce_delay
    while (GPIO.input(gpio) or
           int(round(time.time()*1000)) - button_duration < debounce_delay):
        time.sleep(sleep_time)

Figure 7 | A simple software debouncer from beatbybeat

Speed is the Name of the Game

From the competition that ensued, my friend and I found we could hit around 600 beats per minute (bpm), however our consistency and stamina waned the faster we went. Since Morse code uses dashes and dots, which represent different periods of time, and each letter of the alphabet represents a different combination of dashes and dots, the maximum speed at which a message can be transmitted also depends on the content of the message itself, making calculation of words per minute with Morse code a bit tricky.

One issue that both Morse code and typing share is that words of the same length may take different periods of time to communicate. With typing, this is because of the physical location of the keys on the keyboard and the distance the fingers must move, and is the reason for the the QWERTY keyboard layout- the most common letters in the English language are placed at the shortest reach. With Morse code, these common English letters were assigned the shortest Morse code sequence, comprised of the fewest elements.

This can be demonstrated by examining the two common words used to measure words per minute in Morse code, “PARIS” and “CODEX”. PARIS was chosen because it mimics a typical natural language word and incorporates letters with Morse code’s shorter code durations, while CODEX typifies a word constructed from random letters. If you can send PARIS 5 times within a minute, that would be 50 x 5 = 250 elements per minute, and 60 / 250 = 240 milliseconds per element. For CODEX, this would equate to 60 * 5 = 300 elements per minute, and 60 / 300 = 200 milliseconds per element. Therefor, one could transmit PARIS more often than CODEX, if speed remains constant.

More recent telegraphs, such as the iambic paddle (Figure 8), are used with an electronic keyer to produce high-speed Morse code. Pressing (or touching if actuated by conductance) one paddle produces a series of dits, the other paddle produces a series of dahs, and both paddles produce a series of dit-dahs. Different sequences can be produced by carefully timing the order and duration of single and double-paddle presses.

Found in Translation

There are numerous projects that document methods for sending a signal from a computer to a telegraph sounder using relays (to produce clicks), but I was surprised when I couldn’t find a single one that used a telegraph (or push-button) as an input to translate Morse code signal to text. So, I set out to create one.

The first step was to define durations- of dits, dahs, spaces between letters, and spaces between words. I allowed this to be set with a command line option, otherwise this would be calculated from a tempo that the user is prompted to tap to set the duration of a dah, with the other durations automatically calculated from this. Next, ranges of error were calculated above and below each duration of each Morse element, to account for variability of user input. From here, translation is a straightforward dictionary key lookup of the Morse string entered between letter spaces and printing the value (Figure 9). Additionally, if we reverse the dictionary, we can translate from Morse code to text, and we can also determine the amount of time it would take to transmit the message by calculating the sum of durations of all the elements (Figure 10). Finally, I’ll leave you with a demonstration of the translator in action.

Translation Demonstration

Finally, I made a quick demonstration of beatbybeat running on a remote terminal and translating Morse code to text in real-time (Figure 11). I hope you enjoyed following this vintage technology’s resurrection as much as I, and as always, feel free to start a discussion by leaving a question or comment below.

References

beatbybeat, on GitHub Crypto Museum, Morse Code Retrieved February 2016. The Ganssle Group, A Guide to Debouncing, or, How to Debounce a Contact in Two Easy Pages Retrieved February 2016. Hackaday, Embed with Elliot: Debounce your Noisy Buttons Retrieved February 2016. Wikipedia, Morse code Retrieved February 2016. Wikipedia, Electric telegraph Retrieved February 2016.

Kyle Gabriel