Tonewriter: Interfacing a Hammond Organ to Fldigi

(C) 2013, G. Forrest Cook

Hammond B3 and Laptop

Hammond B3 connection to Arduino

FLDIGI Showing Tonewriter Output


This was a purely experimental project. The goal was to generate a parallel sequence of audio tones that would show up as characters in a waterfall display, also known as a spectrogram. Waterfall displays are commonly used by ham radio operators to visualize the audio that is received by a radio receiver. They can help to visualize digitally encoded signals such as CW, RTTY, psk31 and Olivia, to name a few.

Normally, the digitized audio data is fed into a decoder program. The tones generated with Tonewriter can be directly read as characters in the waterfall display. The concept is not unique, ham radio operators sometimes encode a few waterfall-readable characters in the preamble of a digitally encoded message. Tonewriter just puts that functionality on an Arduino board. The idea could be further expanded by sending higher resolution fonts, pixelated images and even greyscale images.

Several varients of the Hellschreiber mode work this way. This system is essentially the same as Concurrent Multi-Tone Hellschreiber (C/MT Hell). See this article on multi-tone Hellscrhreiber for more background info.

The functioning Tonewriter experiment can be seen in a short YouTube video.

Two of the more common software applications that use waterfall displays are the open-source Fldigi (shown above) and the commercial Ham Radio Deluxe (HRD). The project was done on an older laptop running Ubuntu 10.10, so Fldigi was the appropriate software to use.

This project is far from practical, it is simply a proof of concept done in the Steampunk style. Steampunking involves mixing technologies from greatly different eras. This effort could be described as an incredible kludge. Credit should go to Terry Gilliam for his excellent movie Brazil, which features many such designs.


The project required writing several pieces of custom software and putting together some prototype hardware. Open-source tools were used and a common Arduino Uno processor was chosen as the main processor.

The first software challenge was to assemble a 5x7 character font into a format that could be used by an Arduino program. Datasheets for the ancient 2513 upper and lowercase character generator ROMs were studied, the characters maps were meticulously turned into groups of 5 hexadecimal numbers for each character. A quick Python program called was written to help visualize the characters on a computer screen. The characters were modified to make minor improvements.

The font data was transferred to the Arduino platform and incorporated into my Arduino sketch Tonewriter1.ino. Tonewriter1 just reads characters from the USB serial port and sends out a sequence of characters column by column. At this point, Tonewriter1 lacks the logic for controlling a transmitter's T/R line, but that should be fairly easy to add.

A source of audio sinewaves was needed to generate the tones used in this project. Your author happened to have a model B3 Hammond Organ handy. The organ's previous owner claims that it was used on the "Herman's Hermits" tour of the midwest and was also played by Booker T. Jones. the Hammond generates its tones with an intricate set of gears and cams (tonewheels) that drive a group of electromagnetic pickups. A group of around 90 sinewaves are continuously available from this device. Seven adjacent tones between 500 and 900 Hz were tapped into with alligator clips.

The electronics that interface the Arduino to the Hammond tone generator is quite basic, the 74HC595 tutorial was used as the basis for producing one latched byte of outupt data. Seven of the eight output bits from the 74HC595 are sent to a ULN2003 driver IC which in turn drives seven 12V SPST reed relays. One contact from each of the reed relays is connected to a single tone output from the Hammond tone generator. The other contacts from each reed relay are tied together to form the common audio signal.

The audio signal and the ground from the Hammond amp chassis are sent to the input of an external audio amplifier. The output of the audio amp was sent to a monitor speaker and also to the mic input of the laptop via an audio isolation transformer. Power to the Arduino (+5V) comes via the USB port. A 12V 3AH gell-cell was used for powering the ULN2003 and reed relays.


All of the custom electronics were built on a standard prototyping board, the connections to the Hammond and audio amp were all made with alligator clips. Finding seven adjacent notes on the tone generator was tricky. The wiring chart for the tone generator is available online, but it was easier to search for adjacent individual notes with an alligator clip fed to the amplifier's input. The project was built to be tempory, once the idea was proven to work everything was disassembled.


After everything was connected, the Fldigi software was run and the Arduino development environment's built-in serial terminal program was used for entering the text. Characters typed into the serial terminal produced groups of tones and the tones showed up on the waterfall display as characters. The device was never tried "on the air".


Now that the basic concept has been proven, this idea could be used as the basis for a practical implementation that doesn't involve an antique organ. One could generate the tones with solid-state oscillators, filters and amplifiers. A better way to generate the tones would be directly in the Fldigi or HRD software by summing mathematically produced sine waves.

The tones could be spaced much closer together, this would greatly reduce the audio bandwidth and would also improve the throughput since the displayed width (bandwidth) and length (transmission speed) are proportional. The spacing of musical notes "intervals" is non-linear, this causes the dot spacing in the letters to stretch out to the right. A linear spacing would be a better choice.

Note that this type of encoding does not lend itself to being easily decoded into digital data, and the bandwidth usage is inefficient. It should be really easy to identify and would probably be readable in the presence of moderate background noise.

Back to FC's Ham Radio Circuits page.