Musical Interference

This article first appeared in the EMC society newsletter in 2002, as part of Dr. Johnson's continuing conversations with his friends in the world of electromagnetic compatibility.

I will always remember the sight and sound of my first real computer. It was an old IBM 1620, buried in the basement of the local state university. After one of my buddies in high school found out the machine was available for public use, we dove down into that basement every chance we got to punch out stacks of Fortran code. It was exhilarating to sit at the big console, feed in a deck of fresh cards, flip the "start program" switch, and watch the lights dance across the panels.

It wasn't long before we began to recognize certain repetitive patterns in the lights. The flashing patterns in the top few bits of the memory address bus, for example, showed when the processor was flipping between "user" memory and "system" memory. This revelation was eclipsed when a more experienced user, who I'll call Bob, taught us to listen to the computer.

It turns out that the electromagnetic interference from this machine (and indeed from the entire building) was so severe that radios were rendered useless for ordinary purposes. If, however, you wanted to hear the machine itself, an AM radio could be quite handy. The AM radio picked up an obnoxious blast of interference every time the computer did anything, with the magnitude of the burst varying in proportion to the type of activity (i.e., number of bus bits changed, or area of memory accessed, etc.). Bob had learned to recognize distinct patterns of interference associated with the program job loader, the card-punch driver, etc., which explained his seemingly prescient ability to walk over to the card-punch precisely in time to receive the output from a long-running calculation.

We were thunderstruck, but only more so when he presented a program that could actually play music through the AM radio. The patterns of interference he had learned to control were tuned to specific rates of repetition, creating a primitive musical scale. For weeks the lab resounded with buzzy, monotonic, haunting melodies.

The computer industry has progressed a long way since the days of the IBM 1620, but the physical principles haven't—computers still interfere with wireless services. If not for the stringent implementation of EMC regulations, we would all be enveloped in an overwhelming bath of emissions. In such a world no wireless services would be feasible. No cell phones, pagers, FM, AM, or TV services (except for cable) would function. No radio-dispatched taxis, no emergency services, and no garage-door openers would be possible. Life as we know it in technological society would be radically different.

Everyone benefits from EMC regulations, and everyone benefits from manufacturers of computer equipment that comply. Unfortunately, some digital engineers lack a clear understanding of the need for emissions regulations. I find it difficult to reason with such people about the impact of non-compliant equipment on modern society. They offer various excuses such as "We'll worry about emissions after we get the product working", or "Nobody is going to check", or "It probably won't be as bad as you think". If you find yourself confronting such an attitude, let me suggest something (besides finding another job) that might help break the logjam.

You will need the support of your software department to make this work. To begin, rip the cover off of a PC (or off of you own equipment) and find a pattern of activity that generates copious quantities of interference in the AM band. Good high-interference activities usually involve lots of memory accesses. For example, in a processor with a 100-MHz memory bus, you could pre-load one area of memory with a repeating pattern of 50 words of all zeroes followed by 50 words of all ones. Repeatedly reading or writing that pattern should generate lots of interference at 1 MHz. You'll need to research the operation of your CPU's internal cache to make sure the program code stays resident in cache, while fetching the memory accesses from real external memory, in order to obtain the best effect. Toggling I/O bits works as well as memory accesses and may not involve the same difficulties with caching.

After you've found a pattern that generates some good interference you can proceed to the next phase, which is the modulation of that pattern at audio frequencies. Have your software guru use the system timer (or a loop counter) to interleave bursts of high activity with periods of relative quiet. The most efficient pattern would be a 50% duty cycle, but the duty cycle doesn't have to be accurate. What matters most is the repetition rate of your bursts. When the bursts are working you can observe the AM modulation on your spectrum analyzer quite easily. A handheld AM radio should be able to tune into the interference pattern and demodulate the interference into a constant, buzzy-sounding tone.

The third and final phase of this projects wraps your code with an overall algorithm that plays specific notes with specific timing. The notes of the Western musical scale (half-tones) occur at the specific frequencies geometrically spaced above and below 440 Hz, where the ratio between successive half-tones equals the twelfth root of two. Given that knowledge, you can play any tune.

When you can walk up to your equipment and make it play Dixie on an AM radio, you will have captured the attention of your digital engineers. Perhaps then you can begin a conversation about the importance of complying with EMC regulations.