MorseMode is a hardware translator between (a subset of) ascii and international Morse code. It is mostly a "just for fun" project, but might have some limited practical application. A zipped copy of the current version of the project source code is available in the Files area of this project.

The challenge can be stated as follows. Using low power, inexpensive hardware, create a means by which data be sent over a open channel (radio, sound through the air, infrared light etc ) in a form that is accessible to both computers and minimally augmented human beings. A data rate slow enough for a person to read in real time is assumed, say 5 to 40 'words' ( groups of five characters each) per minute.

This data rate is no challenge at all for computer-only data transfers. The 'challenge' is that I am also requiring that the transmitted information be accessible to humans without computer assistance. There are old stories (possibly apocryphal, a google search turned up nothing) of phreakers who could read teletype-era modem tones by ear, but even if the stories are true this skill is likely difficult to learn. Alternatively, it might be possible to use voice recognition software on the receiving-end computer. This idea solves the human access problem, but is unlikely to be a practical, general solution in 2017 on "low power inexpensive hardware".

Morse code may be a useful protocol to address the problem as stated. Use of Morse is a skill that can be learned by most people who choose to do so (When I earned a ham license, I went from zero to adequate copy at 20 words per minute in less than six months without extraordinary effort or talent). The characters of Morse code are arrangements of the "Presence" or "Absence" of a signal; it is an intrinsically digital protocol which should be easy to read and write by machine.

Some people may be surprised to learn that Morse is still a 'living' medium. Until 2007 Morse proficiency was a requirement for at least some Amateur Radio licenses and it remains a favored mode of many amateurs. In 2017 there is still one class of FCC Commercial Radio Operator License that requires demonstration of Morse proficiency https://www.fcc.gov/wireless/bureau-divisions/mobility-division/commercial-radio-operator-license-program/examinations

The test hardware is based on some Arduino clones pulled out of my 'old projects' pile uh... resource archive. At one end is an UNO R3 and the other is a 5V 16 MHz pro-mini clone with an FTDI usb-to-serial converter. Computers on the "sending" and "receiving" ends of the conversation simply read from and write to their respective serial ports. The computers have and need no knowledge of Morse. An human participant in the conversation should need only the minimum hardware required to access the chosen physical transport medium, with data processing handled by the brain.

This project is still a work in progress; although most commonly-used ascii characters have direct Morse equivalents, some do not. For now, if ascii characters are sent that have no direct Morse equivalent, they are replaced by underscore characters. No notification of an unrecognised character is presently returned to the sender; also, extensions to Morse code that address languages other than English have not been implemented.

Currently the MorseMode hardware works quite well when the two units are connected by wire. The next step is to add an analog front-end to allow convenient interface with e.g. acoustic, radio or optical links. Sound-through-air is my initial choice of physical transport medium This will allow a convenient way to experiment in a “real” noisy, multipath environment. It is also consistent with the basic concept of allowing an unaugmented human being to directly access the data stream. A human can receive by ear. To transmit, a person would need a switchable sound source of suitable frequency. Mouth-whistling probably won’t work, though a Captain Crunch ‘2600’ whistle might. I think the analog section can be done with about US$5.00 worth of parts, and happily, I jut downloaded a new version of LTSpice that I want to try out .

Description of Operation

Transmit

A 100 character input buffer is provided for data from the serial port. When an ascii character is read from the input buffer, its is compared to a list of control characters. If the character is found, processing is handed off to a set of control routines, these allow the user to set such parameters as transmit data rate, or to print a help/usage screen to the serial port. Please see the the functions "void AdjustSysParms()" and "void ShowHelp()" in the //Housekeeping/Utility section of the source code for more information.

Characters that are not control characters are processed in the following manner: If a character is lower case, it is converted to upper case. The character is then compared to a table of supported ascii characters. If the character is found in the table of supported characters, the index into the table is saved. If the input character is not in the table of supported characters, the last index value in the table is saved as a default placeholder (the character "_"). The saved index value is used to query a second table which contains representations of Morse characters as c-language strings of '0' (dot, called 'DIT' or 'DI' by amateur (Ham) radio convention) and '1' (dash - Hams say "DAH"). Thus, the ascii letter 'q' is converted to 'Q'; 'Q' is found at index 16 into table of supported characters. The table of Morse characters is queried at index 16, returning the string "1101", or "DAH DAH DI DAH"

The elements of the string (“1101”) are fed one-by-one to a set of subroutines that send DITS and DAHS to output pins. Since there are plenty of pins available , I provide inverted and non-inverted Morse stream outputs, a pulsed audio tone and also flash the 'standard' arduino pin 13 led.

Support is provided to add characters to the input buffer via the I2C interface in parallel with the input path from the serial port.

Receive

Morse data is input on a pin that is monitored by an interrupt handler. At each rising or falling logic edge the state of a millisecond timer is captured in a variable called NOW. The stored value of the previous edge-time value is retrieved from a second variable called WAS. The time in WAS is subtracted from the time in NOW. The logic state of the input pin is read. If the logic state is LOW, the transition was from a HIGH state, so the difference between times NOW and WAS describes the duration of a high or "Mark" state (DIT or DAH). Times between Mark states are called "Space" states. Space states are represented as negative numbers. The positive Mark times are stored in two locations. First, into a 32-cell buffer called RING. RING is only loaded with Mark times. Secondly into a 64-cell buffer called FIFO. FIFO is loaded with both positive Mark and negative Space values in their received order. Note that in the source code comments, stored Mark and Space intervals are referred-to as 'Mark Particles' and 'Space Particles'. The value in NOW is saved as the new value in variable WAS.

Processing of incoming Morse data is suspended until 32 Mark values have accumulated in the RING buffer. The contents of RING (32 positive numbers) are then sorted by size. The five smallest values are averaged. A value equal to an empirically determined 7/8 of the average is defined as the characteristic duration of a minimum "DIT Time" which is saved in a variable called "MinDit". The value in MinDit is used as the basis for defining current durations for the Mark (DIT and DAH) and the Space intervals within and between Morse characters and words. All calculation are done with integer math. Each time a new Mark value comes in it is added to RING and FIFO, and the sort-average-and-scale operation is repeated. The least-interesting datum 'falls off the edge' of RING with each update. If the values change relatively slowly, the receive program will adapt and receive will proceed without loss of data. Large, rapid changes will cause data loss until corrected values are calculated. Although this is a fairly unsophisticated algorithm, it seems to work quite well in early testing.

The relationships among the various Mark and Space timing definitions are described in the function "void Particles(int MinDit)" in the //Receive section of the source code.

Interpretation of Marks and Spaces stored in FIFO is performed by the function "void InterpretMorseStream()". For details, please see the source code, but briefly, as each Mark is interpreted as a DIT or DAH, a '0' or '1' is added to a C-language string in a character array that is was pre initialized with '\0' characters. A Space interval longer than two times MinDit defines the end of a Morse character. When the end of a Morse character is found, the built-up string is compared with the table of Morse sequences described above in the Transmit section. When a match is found, the value of the index into the Morse sequence table is used to retrieve the corresponding value from the ascii table, reversing the process described in the Transmit section (above). The retrieved ascii value is sent to the serial port and also saved in a 320 character received-history buffer. The received-history buffer is arranged so that new data overwrites the oldest data in the buffer.

Provision is made to support access to the receive-history buffer via the I2C interface.

Analog Front end

To allow Morsemode to be used without a direct wired connection, access to an alternate physical medium must be provided. I have chosen to use audible sound through air. This is consistent with the requirement for easy access by unaided human persons, but can also potentially simplify access to electronic communication channels (let MorseMode use the same mic and speaker that a person would; no plugs, no wires! ).

Please see the Build Logs below for more information.

Text Copyright © 2017 R.Grigg

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.

MorseMode Analog Front End Hardware Design Copyright © 2017 R.Grigg

This is a free hardware design: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This design is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.