Huffman-coded Audio

This project utilizes a magnetic reed switch, a NerdKit, and a set of computer speakers to startle unsuspecting visitors at the door. In constructing this project, various engineering concepts are explored, including digital audio, data compression using Huffman codes, and audio output via PWM with analog filtering. To determine whether the door is opened or closed, a magnetic reed switch is employed, similar to those used in wired alarm systems. One component contains a magnet and is mounted on the moving door or window, while the other contains a magnetic-field-sensitive switch with three screw terminals for the switch contacts. The switch is wired with the "COM" common terminal connected to ground on the breadboard and the "NC" normally closed terminal connected to the microcontroller pin PC5 (ATmega328P pin #28). This configuration ensures that the switch remains closed when the magnet is in proximity.

The microcontroller's built-in pull-up resistors facilitate reading from the switch or button without the need for additional components. For variable-length codes, a binary tree is generated that corresponds to a sequence of bits, with each "leaf" of the tree representing a symbol output from the decoder. This tree structure inherently prevents any complete code for a symbol from being a prefix of another symbol's code. Huffman coding is utilized to generate this tree optimally, minimizing the expected number of bits required to transmit a symbol based on the known probability distribution of the various symbols in the information stream. If the actual probability distribution deviates significantly from expectations, the Huffman code may underperform compared to fixed-length encodings such as ASCII. It is important to note that while this project involves "coding" rather than "compression," it effectively reduces the number of bits needed to represent symbols. Other algorithms, such as LZW, leverage the interdependence of adjacent symbols to achieve greater compression.

Python scripts are employed to convert a sound file into a C header file for integration into the program. These scripts also create a C function that implements the decoder for the Huffman tree. A specific sound sample, the "evil laugh" recording, is examined in detail, with an emphasis on using human-readable intermediate formats to facilitate understanding.

The circuit design begins with the magnetic reed switch, which is pivotal for detecting door status. The switch's two components are strategically positioned: one on the door and the other on the door frame. When the door is closed, the magnet keeps the switch closed, allowing the microcontroller to read a low signal on pin PC5. Upon opening the door, the magnet moves away, causing the switch to open and the microcontroller to receive a high signal. This change in state can trigger an audio playback sequence.

The microcontroller, specifically the ATmega328P, is programmed to manage the audio output through pulse-width modulation (PWM). The audio data, processed and compressed using Huffman coding, is stored in the microcontroller's memory. The PWM signal is filtered using an analog low-pass filter to smooth the output, ensuring clear audio playback through the connected computer speakers.

In summary, this project not only demonstrates the practical application of a magnetic reed switch for detecting door status but also integrates advanced concepts in digital audio processing and data compression. The combination of hardware and software elements creates an engaging and educational experience in electronics engineering.This project uses a magnetic reed switch, a NerdKit, and set of computer speakers to frighten unsuspecting visitors at the door. In covering constructing this project, we get a chance to go over some pretty neat engineering concepts: digital audio, data compression using Huffman codes, and outputing audio via PWM with analog filtering.

To detect whether the door was opened or closed, we used a magnetic reed switch, like the kind used in wired alarm systems. This one from Amazon illustrates the basic concept. One part has a magnet, and would be mounted on the moving door or window. The other part has a magnetic-field-sensitive switch, and this one has three screw terminals for the switch contacts. For the switch we purchased, we wired the "COM" common terminal to ground on our breadboard, and connected the "NC" normally closed terminal to our microcontroller pin PC5 (ATmega328P pin #28).

For our part, this meant that the switch was closed (connected) when the magnet was nearby. As we discussed in our Digital Calipers DRO video, we can use the microcontroller`s built-in pull-up resistors to easily read from a switch or button with no extra components. As explained in the video, for variable-length codes, we generate a tree of binary ones and zeros corresponding to a sequence of bits, and each "leaf" of the tree corresponds to a symbol being output from the decoder.

By visualizing this as a tree, we automatically enforce the constraint that no complete code for a symbol is the contained within the beginning of the code for a different symbol. Huffman coding is the specific way to generate this tree in an optimal way. By optimal, we mean that if we know ahead of time the probability distribution of all of the different symbols occuring in our information stream (and assume them to be independent), we construct the code that minimizes the expected number of bits needed to transmit a symbol.

Of course, if our probability distribution ends up being far from what we expected, our Huffman code will not perform well, and in fact may even be worse than just assuming equal probabilities of all signals (which is essentially what ASCII and other fixed-length encodings do). (Side note: as we mentioned, Huffman coding doesn`t do anything to "compress" the fact that adjacent symbols might have probability distributions that depend on each other.

For example, in English, the letter "q" is almost always followed by "u", so if we saw a "q", the probablility of the next symbol being "u" is extremely high. Technically speaking, what we are doing in this project is considered "coding" - not "compression" - but it does have the effect of squeezing more symbols into less bits.

Other algorithms, like LZW, take advantage of the probabilities of adjacent symbols *not* being independent to achieve great compression, and LZW for example is a key part of many file formats. ) For more on this topic, and how Huffman trees are actually generated, we refer you to the excellent MIT 6.

050 Information & Entropy course notes (4. 4MB PDF). Pages 66-68 of thid document specifically talk about "Efficient Source Codes" and the Huffman Code in particular. However, chapters 2, 3, and 4 will also likely be of interest to those curious about this topic. The video lectures from this course may also be of interest. Using a series of Python scripts, we transform a sound file into a C header file for inclusion in our program.

These scripts also build a C function that implements the decoder for our Huffman tree. You can grab the source code in our "Source Code" section below, but for now, we`re just going to provide a high level overview of the process. We`ll look at one particular sound sample - the "evil laugh" recording. We intentionally used verbose, human-readable intermediate formats to help 🔗 External reference