Team 6 — Deal Me In!

The world of embedded systems can be a daunting one, but not when tackled one small step at a time! Throughout the semester, students have been bombarded with new and exciting concepts like Pulse Width Modulation and serial communication. In an effort to further grasp those concepts and flex their scientific minds, Team 6 currently works to assemble a basic machine implementing those very practices. The machine itself has a simple goal — distribute playing cards to players around a table for any number of games; but the production hosts its own underlying objectives. With this automated card dealer, the team aims to advance its experiences with external sensors, servos, 3D modeling tools, as well as the coding which coincides with each of their functionalities. Continue reading Team 6 — Deal Me In!

Team 6 — Testing Piezo Elements

piezzo element

The initial plan for the automated card dealer was to utilize three vibration sensors for point triangulation. The sensors would be placed in a triangular formation, each one equidistant from the other. The necessary angle the servo would need to rotate for the card-firing mechanism to face the vibration’s origin would then been calculated accordingly.


Where Theta = arc-sin(speed of sound within medium in meters per second * time difference between first sensor to register vibration and the second sensor to register vibration) / (distance in meters between sensors 1 and 2). The third sensor would then aid the system in determining whether the cards should fire north, south-west, or south-east. Continue reading Team 6 — Testing Piezo Elements

Team 6 — Final Composition + Demo!

A3BU menu screen

After some experimentation, the most promising plan was to utilize the A3BU’s LCD screen and to introduce a menu to the system. The menu used the GFXMonochrome library for text display as well as the A3BU’s three on-board buttons and q-touch sensor to accept user input. The two sensors on the left-hand side of the screen (button in the top-left and q-touch on the bottom-left) allowed the user to scroll through menu options and increase/decrease values such as “Number of players” and “Number of cards to initially deal.” Additionally the player could select from a number of pre-programmed games like Blackjack or Go Fish which would each pre-set the number of players and initial cards. Continue reading Team 6 — Final Composition + Demo!

Team 1: Big Picture – LED Beat Tracker


In our final project, we initially set out to work with triangulation to determine relative positions using sound and microphones.  The project would resemble an attachment to a camera tripod where the camera would rest on the project, the incoming sound from the camera’s target would be inputted into the microphones, and our board would determine the relative location of the target.  This was our initial idea and have decided to do a slightly different project using the same components that we already have received. Our project that we completed is a beat tracking system which listens to patterns of recorded sounds and displays those patterns using an LED.  The project setup should act as a system to record sounds/music/etc. and display the pattern using different intensities of light from an LED.

Team 1: Code for Push Buttons

void get_key(struct keyboard_event *keybuffer)
     uint8_t key = 0;
     uint8_t pressed = 0;
     while(key == 0)
          if(gpio_pin_is_low(GPIO_PUSH_BUTTON_1) && pressed == 0)
               pressed = 1;
               keybuffer->keycode = KEYBOARD_UP;
          } else if(gpio_pin_is_high(GPIO_PUSH_BUTTON_1) && pressed == 1){
               key = 1;
          } else if(gpio_pin_is_low(GPIO_PUSH_BUTTON_2) && pressed == 0) {
               pressed = 2;
               keybuffer->keycode = KEYBOARD_DOWN;
          } else if(gpio_pin_is_high(GPIO_PUSH_BUTTON_2) && pressed == 2){
               key = 1;

One unique aspect of our project was the use of the on board push buttons. Here is the code used for the logic to incorporate these push buttons.  One aspect that was critical was to know when the button is released and not just pressed. The purpose of the “pressed” variable was to hold whether or not a button had been pressed and if it had, which one. This kept the program from spamming the action made when a button was pushed since the button had to be released. This code segment was key for control of the recording and digitizing of the sound input.


Team 1: Schematics


As we progressed through our project we kept running into issues with the voltage dropping into negative because of the alternating sine waveform inputted through the microphone.  This wave seemed to be causing problems in the displaying of the beat pattern from the LED.  To fix this issue we used another LED to smooth out our incoming voltage to just the positive input voltages.  The using of a diode to fix our voltage issue was ingenious because when voltage across a diode is negative, virtually no current flows.  Also, seeing the LED light up whenever incoming sound is being recorded shows that our sounds are being transformed into electricity and that is pretty cool.

Team 7 Flappy Bird Programming

Our project used two separate boards (The A3BU and an Arduino Uno) so we have seperate code for each device.  Our game specific code lived primarily on the Arduino, which held the code for rendering the sprites in the game and updating their position on the screen.  It was also used to communicate to the A3BU the status of the game (Active or Inactive).

The code for the A3BU was primarily the setup of an SPI Connection to the Arduino and establishing the proper setup for input detection on the pushbutton and at one point the joystick which unfortunately was unused in the final project due to hardware issues.


Big Picture – Sound Activated Fan

The objective of this final project was to make a motor run in the presence of a loud noise by using the output of a microphone. This project focused heavily on integrating two separate devices into a single working product and utilizing different capabilities of the A3BU board and peripheral hardware. We were also able to reinforce the ideas presented in previous labs such as using the ADC input and controlling a motor through the use of PWM signals.  We wanted to do something in which all members could learn and understand all parts, rather than just the parts that dealt directly with their major.

Code – Sound Activated fan

We implemented several ASF libraries, such as the libraries for ADC and PWM,  to achieve the above results. As displayed by the code below, once the program was loaded onto the A3BU, the program would essentially be put into a “sleep mode” until the board read a result on the ADC1 pin. This result would come from the output of the microphone that sends a voltage that depends on the sound level it detects. Then a callback method, adc_handler, is triggered which contains all of the essential conditional logic as mentioned above. To avoid the spinning of the fan at lower, unintentional, sound levels there’s an if statement that uses that threshold value and compares it to the result that is passed into the callback handler method.

Above is a video of the microphone’s output when a sound is made. This value was then incorporated into our code to aide with the turning on of the motor.

Schematics – Sound Activated Fan

We would begin by designing the circuit we used for Lab 4 to drive the motor. The circuit is given below. We would test the motor output with an oscilloscope to verify a signal Add Newis displayed. As this is correct, we would move on to test the microphone and the pre-amp circuit that will send an output to the A3BU board.

Below are the schematics for the microphone and motor. sfdwesdf


Below is our fully functioning circuit for both the microphone and the motor.