Monday, February 10, 2014

DTMF Tones, Fourier Transforms, and Spectral Analysis

I just recently completed a year working with a team to develop a satellite communications product for business aviation. My participation in that project culminated with us flight testing the system on an executive jet. I spent most of those flight tests sitting in a luxurious leather chair plusher than the recliner in my living room. Flying coach on a commercial airline will never again seem adequate.



That product was mostly Session Initiation Protocol (SIP) and Real-Time Protocol (RTP) based, just like your typical Voice over Internet Protocol (VoIP) phone. But it also supported an older analog technology commonly used in aviation which brought back memories of my Bell Labs days. Early in the development of this product I was debugging software I had written to do tone dialing over the audio path in the analog hardware. Just the other day I got to thinking "Boy, it sure would have been useful to have had a spectrum analyzer to have figured that out." It was a head slapping moment as I realized that my Velleman PCSU1000 PC-based digital storage oscilloscope (DSO), as seen in Brass Tacks, had that very capability. I had just never used it. But how hard could it be? There was only one thing to do: learn how to use the tools I already owned by doing some spectrum analysis.


(Western Electric Model 20AL Candlestick Phone circa 1915, Chip Overclock Collection.)

The mechanisms used to dial a phone have evolved since Alexander Graham Bell patented the telephone in 1876. At first, connecting up a phone call was a strictly manual process: just like you may have seen in the old movies, you picked up the receiver and waited for your local telephone operator to answer. You told her who you wanted to talk to, and she (it was almost inevitably a she) either connected you up directly by plugging in a patch cord to the line of the person you were calling, or she patched her way to another operator (and perhaps to another, and another) until the call was completed end to end.


(Nevada's first telephone switchboard, Mark Twain Museum, Virginia City, Nevada.)

The patch cord had a plug with dual concentric conductors that was polarized such that the inner conductor, or the tip, was positive, and the outer conductor, or the ring, was negative. (There was also a third outer-most conductor, the sleeve, that when it was hooked up at all was connected to ground.) Tip and ring style connectors are still in common use today, albeit in much smaller form factors: check out the headphone jack on your smartphone.


(Quarter-inch phone plugs similar what the switchboard operators used.)

Automation arrived in 1891 with the patent for pulse dialing. Your rotary dial phone used an electromechanical mechanism to make and break the current loop with the telephone company equipment in your central office, encoding your dialed digits in up to ten consecutive pulses of about a tenth of a second apiece. This was electrically equivalent to rapidly pressing and releasing the switch hook, the button that was depressed when you hung up the receiver. In fact, if you worked at a frugal company that put locks on the rotary dials to keep people from making phone calls, and if you were perhaps a college student who was fleet of finger, you could trivially make calls without using the rotary dial at all. Dialing zero (ten pulses) was a bit of a challenge, but I assure you from personal experience that it was completely doable. And lest you think that pulse dialing was never used in the computer age, as recently as the year 2000 I wrote software for a commercial product to dial calls by making and breaking the current loop on an analog trunk with exquisitely careful timing. And I wrote that software in Java.


(Western Electric Model 500 Rotary Dial Phone circa 1962, Chip Overclock Collection)

Pulse dialing had one big draw back: it was slow. It could take many seconds to dial a long phone number, time that would have been better spent accruing long distance charges and hence generating revenue. So in 1963, with the advent of reasonably inexpensive technology to do signal processing, the Bell System introduced tone dialing. Your Touch-Tone phone had a keypad that generated tones over the audio path to equipment in the central office that performed digit collection as you dialed your phone. This was referred to as dual-tone multi-frequency (DTMF) signaling, and is still in common use today for dialing on non-VoIP land lines and other analog technologies.


(Western Electric Model 2500 Touch-Tone Phone circa 1980, Chip Overclock Collection)

DTMF found its way in to all kinds of equipment, including FAX machines and modems. It was so effective that it was not only used for dialing, but it was adopted to control a variety of devices that you might put on your telephone line, like answering machines. That's because besides having become ubiquitous, DTMF was specifically designed [1] to be reliably transported over even poor quality analog phone lines, and [2] to not be likely to be generated by a human voice.

Each button on the Touch-Tone keypad generates a pair of frequencies that uniquely identifies it, much like an [X,Y] coordinate. Here is what the 4x4 Touch-Tone matrix looks like.

      1209Hz 1336Hz 1477Hz 1633Hz
697Hz   1      2      3      A
770Hz   4      5      6      B
852Hz   7      8      9      C
941Hz   *      0      #      D

Yes, the DTMF standard includes tones for buttons labelled A, B, C, and D, as well as the ten digits, the asterisk, and the octothorpe. And no, even for all my time spent in telephony and telecommunications, I have never seen a phone with the A, B, C, or D buttons. But I am assured that at least at one time, phones deep within the Department of Defense had them, for purposes of prioritizing calls. Maybe inside Cheyenne Mountain (although I've been inside Cheyenne Mountain and I didn't notice any).

Note that everything I've described applies to only dialing a phone (a.k.a. station or terminal); the trunks that connected central offices together had their own signaling mechanisms. And because a telephone company (sometimes not the same one) controlled both ends of the trunk, and there are a lot fewer trunks than phones, trunk signaling could be automated much more quickly. For all I know there may still be rotary dial (and hence pulse dialing) phones in daily use in the U.S.

DTMF was so popular that at one time you could walk into any Radio Shack and buy a pocket tone dialer, a hand-held device that was little more than a Touch-Tone keypad on one side



and a speaker on the other side.



These little devices were especially handy, in the dark ages, should you find yourself needing to control your answering machine from a rotary dial phone. Alas, these are almost impossible to find nowadays. Although there are smartphone apps that implement the same functionality (and I have such an app on my iPhone), I find that the old tone dialers still work better. That recent satcom project sent a couple of us old guys scrambling through our basements, where I was relieved to find I still owned a couple of tone dialers.  Crack one open and you will find that they are nothing more than a keypad, a chip, a few discrete components, a speaker, and some batteries.



I attached my oscilloscope to the yellow speaker wires.



I took a look at the waveform produced by DTMF 0, a tone that is the sum of the frequencies 941Hz and 1336Hz. The oscilloscope represents time on the horizontal (X) axis, and voltage (amplitude) on the vertical (Y) axis.



Clearly from this screenshot you can see that there is some sort of regular pattern being expressed. But good luck teasing apart what it might be just from inspection. Fortunately, the Fourier Theorem says that any reasonably continuous repeating signal can be decomposed into the sum of several regular sinusoidal signals, each of which would be a single frequency. The Fourier Transform is a mathematical algorithm that does just that. If you then map those individual sinusoidal signals from the time domain into the frequency domain, what you get is a graph that shows you what frequencies are prevalent in your original signal.

As luck would have it, my oscilloscope can do all of that with little more than a mouse click on my part.  It implements the Fourier Transform in software on the laptop to which it is connected. This is spectrum analysis, a display of the use of the frequency spectrum within a signal. The spectrum analyzer represents frequency on the horizontal (X) axis, and decibel Volts (relative change in voltage) on the vertical (Y) axis.



The PSCU1000 tells me that DTMF 0 on my pocket tone dialer is approximately composed of 950Hz and 1330Hz signals, plus a lot of noise at much lower amplitudes. The peaks of those two frequencies really stand out.

Exact? No. Close enough? Sure. The frequencies selected for DTMF were chosen with enough gap between them so that they could be easily distinguished from one another without ambiguity even if the frequencies weren't spot on.

Had I thought to use my oscilloscope (which at the time was sitting in the trunk of my car just steps away from the lab where I was working), I could have characterized the DTMF tones our product was generating and gotten a useful clue as to where the problem I was debugging might have been.

This article is my penance for that senior moment. Maybe next time, I'll remember.

(If you'd like to see the complete set of screenshots and photographs I did for this little exercise, you can find them on Flickr.)

Monday, February 03, 2014

Many Digital Aggregates Projects Are Now Available on GitHub

I've used a lot of different source code management systems over the years: SCCS, RCS, CVS, ClearCase, Subversion, Perforce, and Git, as well as some pre-UNIX solutions, depending on what my employer or client of the moment preferred or what was available. Since 1995, Digital Aggregates' own SCM server has migrated from RCS to CVS to Subversion. As part of a gradual shift to Git, I've started hosting some of Company's open source projects in the cloud on GitHub.

This is still very much a work in progress. But since some of my projects licensed here under the GPL (3.0), the LGPL (2.1), or the Apache license (2.0) have found their way into a variety of commercial products and other projects, I thought the use of GitHub might make my and other folks' lives easier.

The tarballs of the projects listed below are still available on the Digital Aggregates web site.

Amigo: FreeRTOS-based C++ system for AVR ATmega Arduino-compatible boards.
http://www.diag.com/navigation/downloads/Amigo.html
https://github.com/coverclock/com-diag-amigo

Biscuit: mechanism for encrypted Linux system maintenance scripts automated via hot plug.
http://www.diag.com/navigation/downloads/Biscuit.html
https://github.com/coverclock/com-diag-biscuit

Buckaroo: Java traffic shaping classes and instant managed beans (recently updated and unit tested).
http://www.diag.com/navigation/downloads/Buckaroo.html
https://github.com/coverclock/com-diag-buckaroo

Concha: examples of object oriented design in C.
http://www.diag.com/navigation/downloads/Concha.html
https://github.com/coverclock/com-diag-concha

Desperadito: useful embedded patterns in C++.
http://www.diag.com/navigation/downloads/Desperadito.html
https://github.com/coverclock/com-diag-desperadito

Diminuto: Linux systems programming library in C (recently updated and unit tested).
http://www.diag.com/navigation/downloads/Diminuto.html
https://github.com/coverclock/com-diag-diminuto

Hayloft: multithreaded C++ framework for AWS Simple Storage Service.
http://www.diag.com/navigation/downloads/Hayloft.html
https://github.com/coverclock/com-diag-hayloft

Lariat: thin C++ layer over Google Test for use in automated unit testing.
http://www.diag.com/navigation/downloads/Lariat.html
https://github.com/coverclock/com-diag-lariat

Telegraph: collection of C functions useful in non-Linux systems (recently updated and unit tested).
http://www.diag.com/navigation/downloads/Telegraph.html
https://github.com/coverclock/com-diag-telegraph

Feedback welcome.

Saturday, February 01, 2014

Be a Product Developer

From time to time I am asked what I do for a living. People in my line of work know that this isn't always an easy question to answer.

I could legitimately say that I am a "computer scientist". I have two degrees in computer science from an accredited program at a brick-and-mortar university. I've done research, published papers, filed patents, and worked at a national lab sponsored by the National Science Foundation. I'm a believer in the scientific method and being evidence-based. And anyone who has worked with me has got to believe that I like to teach. But being a scientist is not really what I do for a living.

Back in the 1970s I was called a "systems programmer". I have always liked that title and the distinction it draws with an “application programmer”. But alas that nomenclature has fallen out of favor.

I don't like the term "software engineer" because although much of what I do is engineering, to use the term "engineer" in a title has legal and certification requirements in many states (although not where I live, in the great state of Colorado).

I could use "software developer". For sure I write a lot of code. But I don't feel that term really describes the set of skills that I bring to the table.  But there's a better reason that I don't like it: for a software developer to consider themselves successful, they have to develop working software. While developing working software is a hard enough job indeed, it's a far cry from shipping a product.

So I choose to call myself a "product developer". This implies a broad range of skills and capabilities ranging from product definition, process, architecture, design, implementation, testing, maintenance, field support, decommissioning, and even occasionally management; soup to nuts, across the entire lifecycle of a product, that's what I do.

But more importantly: for a product developer to be successful, they have to ship a working product.

No matter what you may do day to day -- sales, product owner, project management, systems engineering, quality assurance testing, hardware or software development, lab support, field support, what have you -- I would encourage you to think of yourself as a product developer. All of those activities are necessary to ship a working product, but none are sufficient. Although perhaps you contribute to one or two of those activities, for you to be successful as product developer, all of them have to be done.

All successful product development projects are team efforts, because it takes a team of product developers -- diverse in skills, culture, and experience -- working together to make it happen.