Final Lab Project
Description of Project
​
For my lab partner and I's final radio enhancement project, we had a few ideas on what to do. One of the first ideas that we had was to create a circuit that would separate the audio signal depending on the frequency in order to drive a sub-woofer or something of that sort. Another idea that we had was to create a live audio delay that would allow a sports broadcast on the radio to be synced with the TV. We started brainstorming some solutions to these ideas and decided that the live audio delay would be a fun and interesting project to do. We also liked that it was fairly unique and that other groups would probably not do this project. So, with the project decided, we had to start designing the circuit that would accomplish this goal.
​
Both of us had some experience using Arduino and most models have an ADC that would allow us to sample the audio signal. We could save the signal in an array and then play it back at the designated delay. From here we would need a few low pass filters, some amplifiers and a way to convert the digital signal that the Arduino sampled back into an analog signal. After some googling we came across a resistor ladder circuit that takes the parallel digital signal and weights and sums the different bits. This circuit was initially interesting because it was so simple. All that you needed to create the circuit were a few resistors. As for the amplifiers and filters we would just use op amps and RC filters.
Now we needed to decide some details about how we would sample the signal. We thought that if we sampled at telephone quality, it would be high enough quality to be able to comprehend the speech. This gave us a sample rate of 8 kHz and a resolution per sample of 8 bits. This means that we would need 8 kB of memory per a second of audio delay. With all of this information we were able to create a block diagram of the project. Figure 1 is the final block diagram of our project.
​
We learned later that the Arduino UNO did not have sufficient memory to accomplish an audio delay. Because of this we changed the board that we were going to use to the Arduino Due. This board has a built in DAC to the resistor ladder was not needed.
Figure 1: Block Diagram of Project
Description of Performance
​
Below is a video of the final project working.
​
As you can see, the project was a success. For the sake of the video, we delayed the audio by 5 seconds but with the memory of the Due we could delay up to 12 seconds. The audio quality was about that of a telephone. The speech was able to be comprehended. A major way that we could have improved the project would be to make the output louder. Another thing we could have done to make it more practical is to make the output an AUX output which would allow you to plug the sound into a stereo system.
My Channel
Conclusion and Reflection
​
In conclusion, we were able to successfully meet all of our goals. Our design was able to successfully delay an audio signal by up to 12 seconds, and the audio that was produced was able to be comprehended. The project took a lot longer than we initially anticipated, but we were able to complete within the time constraints.
​
One of the most important things that we learned with this project was how non-linear our progress was. Every new module that we would try to test would give us unforeseen issues. Many of the details of our final design were created by overcoming issues that we encountered. At times it seemed like we wouldn't be able to succeed at the project. Even up to the Thursday before our presentation we spent five hours trying to complete our project and get every aspect of it working. When we finally got it working, we were ecstatic.
For a lot of my life I have made little DIY projects. From making a circuit that blinks LEDS to music, or a 'Smart Mirror' that tells you the weather for the day, this project was the most time consuming and difficult to complete. I think that the main factor that made this project more difficult was that no one else had done exactly what we did before. Or at least if they did, they didn't put it on the internet. Our designs had not been proven to work (and they didn't work most of the time). So most of our time was spent troubleshooting and hitting our heads against the wall trying to receive some divination on what was wrong.
​
I think that with more knowledge and experience we could cut down on the errors that we made in the initial design and maybe have more foresight to potential issues that might arise. But I don't think troubleshooting and even hitting your head against a wall is completely avoidable. Although, it might be with extremely strict design procedures, but in my humble opinion that takes out all of the fun in the design process.