The code behind our project is fairly simple. Based on the voltage received from the distance sensor, we adjust the pitch of the buzzer. This allows one to move their hand up and down above the sensor and play ‘notes’.
The sensor uses sudden bursts of current, and this generates noise in the input voltage to the board. However, using a “simulated capacitor” in the code, we’re able to filter the noise out! Here’s the single line of code that does this:
The filteredVoltage is the voltage we output to the buzzer. The way this works is that the filtered voltage is ramped up (like a capacitor) to the input voltage. Small spikes in the input voltage do not affect the output because of this.
If you notice something familiar about our setup, its because we are using a similar schematic from lab 4! Currently our sound output is basically using the same buzzer output from the A3BU only with an infrared distance sensor (pictured below) controlling what sort of pitch is coming out!
It may be a little hard to see, but we have included several capacitors in our design in order to stabilize current and voltage being fed to the device!
In our project we are creating a makeshift Thereman device, which sounds like vid related >>> https://www.youtube.com/watch?v=w5qf9O6c20o
We decided to create one of these because we knew we wanted to work with input modulation and sound, so naturally we thought of the crazy electronic sounds of the Theremen device!
Input modulation is very interesting to us because of how much you can do with it; your imagination is the only thing that limits you. Our association with music in our project is a byproduct of our collective backgrounds with it since we all know how to play a musical instrument!
Here we are troubleshooting our Theremin project! Currently at the time of this post we are having the most problems with sound clarity and getting a sweet spot for our voltage running through the circuit! Further information is in the pipes!
The idea for the Wireless Motion Sensor projects was to display an alert on the A3BU controller when a distant motion sensor was tripped. In order to achieve this, we used Xbee wireless modules to communicate between two A3BU controllers. The first controller would simply detect when the motion sensor was being tripped. The second A3BU controller would display an alert message on its LCD when the first controller detected movement. There were four distinct parts to this project. The first was to get an A3BU to communicate with the motion sensor. The second was to set up the Xbee modules to allow communication between the two A3BUs. The third was to use the communication from the receiving Xbee in order to make the second A3BU display an alert message. Then the last part was to create a couple of mobile power sources for the two A3BU controllers.
This project is a calculator made with two series of LEDs (a yellow series representing input, and a red series representing output); a blue LED for feedback; a potentiometer, used for input; and the A3BU. Interrupts receive input from the pot, and are also tied to a pushbutton switch on the A3BU; the pushbutton is utilized to ‘advance’ the program logic to subsequent operations. It’s a fine example of a project where there’s some hardware, but most of the focus is on software. This addition-only calculator has the user turn a knob to cycle through a series of integers in binary (1-7 in decimal). When the desired number is reached, a push-button is pressed, the A3BU stores the current addend, and the potentiometer knob is again rotated. Once the second addend is reached, the push-button is again pressed, the A3BU sums the two addends, and then outputs the generated value to the red row of LEDs. When the push-button is pressed a third time, the values are cleared from memory, and the program is ready to start over. It’s important for the program to ‘know where it is’ within its flow of execution; otherwise, it executes operations out-of-sequence, leading to unexpected behavior. To this end, a series of flags are used. These flags prevent the program from advancing to its next state until the user indicates (by pressing the push-button) that he or she is ready to advance.
See the Simon game being played. Not only do the lights function as controls and indicators, but you will see the team put Simon in “Display High Score” mode by a button press sequence. There’s the ICE-3 debugger sticking out of the base.
Here’s the circuit schematics for the Simon game’s input/output. We put four LEDs as output, and each LED was wired as an input as illustrated above. Transistors were used here for two reasons: we might have all four LEDs on at once, and transistors can handle all that current while the A3BU might not. Also, the LEDs from Adafruit ran on 12V, and the A3BU’s 3.3V would not light them. (We discovered that these LEDs have an integrated resistor, that’s why 12V doesn’t blow them up). The transistor can be connected to the ground side, and will switch fully on at 3.3V, completing the circuit through the LED to ground.
The goal of this project was to combine transistors, interrupts, and LEDs with the Atmel A3BU microcontroller. It’s a simple push-button Simon Says game. The user watches a developing LED sequence, and then has to repeat it correctly to move onto a more difficult sequence that’s faster with more steps! The project combines the knowledge of embedded systems with circuit and programming skills we have learned throughout the semester. The code determines the sequence of lamps to light, and reads the user input, deciding what to do next. Events are interrupt-driven: user inputs trigger an interrupt handler that makes the next move. The hardware side of the project consists of interfacing the a3bu board with arcade-style push-button lights. The output portion of the circuit must raise the voltage level for the lamps, and the input circuit must provide voltage to the board input when a button is pressed. Ultimately, a working Simon game must have both the hardware and software components working perfectly.
This final project was an 8 bit music player using the Atmel A3BU Xplained board. A small piezo buzzer played one of four different songs; this project was more heavily tilted toward software than hardware. If you want to learn interrupts, this is the project for you! Interrupts were used to respond to buttons for selecting, playing, and pausing songs. Pulse Width Modulation was used to control the pitch. This project demonstrates good programming practices by creating functions for common tasks. A playNote() function was created which played a note based on given octave and length. The delay_ms() function was used to set the note length. The octave notes of each song were stored in an array, then passed on to the playNote() function, leading to a very compact file. When a song is played, the song title, number, and song status is displayed on the LCD screen.