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.

My grandfather's telegraph connected to a Raspberry Pi

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.”

My grandfather's telegraph
Figure 1 | My grandfather’s 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.

Morse code timing
Figure 2 | Morse code timing diagram (from Crypto Museum)
Morse code alphabet
Figure 3 | Morse code alphabet (from Crypto Museum)
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).


Figure 4 | Signal transmission over 400 feet of cat5 cable

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.

Button Bounce
Figure 5 | Bounce, as observed in the milli and microsecond range

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.

Debouncing RRC Circuit
Figure 6 | An RRC debouncing 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.

Bencher paddle
Figure 8 | A Bencher iambic paddle (from Morse code)
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.

beatbybeat Morse code to text translation mode
Figure 9 | beatbybeat running in Morse code to text translation mode
beatbybeat text to Morse code translation mode
Figure 10 | beatbybeat running in text to Morse code translation mode
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.


Figure 11 | Translation of Morse code to text from a telegraph
References
  1. beatbybeat, on GitHub
  2. Crypto Museum, Morse Code
    Retrieved February 2016.
  3. The Ganssle Group, A Guide to Debouncing, or, How to Debounce a Contact in Two Easy Pages
    Retrieved February 2016.
  4. Hackaday, Embed with Elliot: Debounce your Noisy Buttons
    Retrieved February 2016.
  5. Wikipedia, Morse code
    Retrieved February 2016.
  6. Wikipedia, Electric telegraph
    Retrieved February 2016.

KyleGabriel

9 thoughts on “Bringing a Vintage Telegraph into the Digital Age

  1. Excellent read. Thank you. About 65 years ago I was a boy scout and learned Morse code but now all I remember is the SOS(… — …)😊
    I have toyed with the idea of creating a messaging app on the Raspberry using Morse but had doubts of whom I would communicate with.
    I don’t do hardware but using C I am sure I could achieve what is needed.

  2. Hello: You may be surprised to learn that there is a group of retired railroad and commercial telegraph operators and others with an interest in telegraph history throughout the United States and Canada who connect their telegraph instruments via the Internet and public switched telephone network. The instruments behave in the same manner as they did on a standard telegraph circuit.

    By the way; in North American telegraph practice, the original “American Morse Code” was used for commercial (“land-line”) telegraphy as opposed to the International Morse Code shown in your article (“Continental Code”) . If you would like more information on telegraph history, please visit: http://www.morsetelegraphclub.org. For more information on our Internet “virtual” telegraph network, please visit http://www.morsekob.org

  3. Very interesting….. I am an Ex- Royal Navy Leading Radio Operator ( G) . I trained at H.M.S. Mercury, in the wilds of the Hampshire ( England) countryside, from 1960 to 1962. I left the navy in 1972, and did not use Morse “live” again, until February 2012, when I came across a program called CWCOM by MRX Software.

    http://www.mrx.com.au/d_cwcom.htm

    This FREE program, enabled me to connect my ex-R.N . Admiralty Pattern 7681, Straight Morse key, to my laptop ( and subsequently 10 other straight keys) and send and receive morse over the internet. the program decodes sent and received morse on the screen, and operators can choose any channel that they like, in much the same way as choosing a frequency on H.F. ( Short wave) Ham Radio.

    Note… no licence, callsign or registration is required…. just the ability and interest to chat “live” using morse code… You can use your Radio Ham Callsign, or you can make one up to suit yourself…. mine is GEMS.. because they are my intials… also being in England, my call begins with the letter `G` so that also identifies the country. If you want to chat… look out for me… I am on there every day. ! ! ..

    I have communicated with many ex. P.M.G. Australian Telegraphists, who were brought up on the “sounder” and have since operated local “museum” telegraph offices in various parts of Australia, sending telegrams in the “old-fashioned” way, for tourists. I shall pass on the link to this page, for them, as I am sure they will also find it interesting.

    1. Say, Gems/Gerry, it is me MGY from Cwcom and I wanted to say that I can’t believe you commented on this website.
      Oh, and by the way, great website and quite interesting. Can’t wait to hook up my key soon to Cwcom.

  4. Thanks for the interesting material. I’m a newbie with the RasPi and was considering writing something similar to your beatbybeat translation application for a RasPi Zero. It would have taken me weeks, perhaps months, to get something working.

    One of my pet projects is single- or dual-switch keyboard and mouse emulation for those who can’t type but can use Morse Code. You might enjoy reading about Morse2Go and Jim Lubin’s experiences; see the following two links.
    http://morse2go.org/
    http://www.makoa.org/jlubin/morsecode.htm

    I hope you’ll forgive my suggesting that you amend ” . . . QWERTY keyboard layout- the most common letters in the English language are placed at the shortest reach.”? That’s true of the DVORAK keyboard, but the QWERTY layout is not arranged for shortest reach.

    Again, thanks for sharing the Morse translation code.

Leave a Reply

Your email address will not be published. Required fields are marked *