CNC Plotter/Engraver – Atari Joystick Control Port Schematic


Our project revolved around the input from a user. In order to transfer user input to our plotter we needed a familiar physical object that could tell our device how to move on an X and Y axis grid. In this case we chose a joystick from an Atari game system. We then found this input schematic and soldered an adapter from the joystick to our breadboard where we then tested it out using LED’s. This joystick would then be hardwired into our A3BU to tell it when to send a voltage to the different motors.

Hammerheads-Smart Drink Dispenser- The Big Picture

Protect the Brew. After a bad experience with collecting money for a Beer Olympics I came up with the idea for our project, a smart beverage dispenser. One that would limit access to the delicious golden ale inside. Despite my original intentions this project can also be implemented to prevent underage drinking and to keep track of how much people drink. So don’t tell me you had 6 beers when you only drank 4.

The key aspect to this project is the fingerprint scanner. It provides the security we wanted for the project at an affordable price. With two microcontrollers, a Homebrew Draft System, the fingerprint scanner and a solenoid valve the project began. The system is designed so the beverage will only dispense after your fingerprint is verified. We used an Arduino to communicate between the scanner and the A3BU which controlled the other functions. The system will identify who accessed the system and display it on the A3BU LCD. It will also activate one of the LED’s that indicate the status of the fingerprint, red if denied and green if approved. Assuming the approval signal is received by the A3BU it will send a signal that activates a solenoid motor through a transistor circuit. The System will then dispense the beverage for 20 seconds which at 15 psi will fill up a cup.


Mouse Trap: Schematic

The schematic for the mouse trap used a serial interface with the A3BU in the form of a MAX232 IC. This was the same configuration used in a previous lab. The part we had to design and figure out was the four photoresistors that were set in the mouse trap. We accomplished this by hooking a 10K ohm resistor in series with two of the photoresistors and a 1 micro farad capacitor. This way when the photoresistors are blocked (meaning no light getting to them) the RC constant was about a second for the capacitor to fully charge. This then allowed us to code the correct trip times for the servo to trigger releasing the bar on the mouse trap. The servo was hooked up from a ground source, a 3.3V power source, and the SCL pin on the J1 header of the A3BU. This gave us our PWM that was needed to move the servo in the correct manner. Lastly we had a wire soldered to the mouse trap as well as one wrapping around the front of the mouse trap. These wires were then connected to a 220 Ohm resistor and a LED. When the circuit was complete the LED would light up indicating that nothing was caught and the trap needed to be reset.


mousetrap circuit

Sous Vide: Code Snippet

Writing code for the temperature sensor to work with our A3BU proved to be too difficult to be completed in the time allotted. However, code was written, using an empty read temperature function, to show how the sensor would be implemented in our design. Essentially, the user inputs a set temperature and the program uses the set temperature to approximate the power needed to reach that temperature. The sensor then reads a temperature in every second until the water is within two degrees of the set point. If the water temperature does not reach that interval within thirty minutes the power is increased. If the water temperature is greater than the interval the power will be decreased every five minutes until the set point is reached.

(Instructor note: this was a 1-Wire temp sensor. For high temperatures an analog thermocouple reader chip could be used with an ADC. The AD595 chip is user-friendly but it eats a large part of a $25 project budget)

//Decrements duty cycle if temperature is greater than two degrees of set point
d_c=d_c-1;//Increments duty cycle
s_flag=0;//Sets seconds flag to 0

//Enters loop while water temperature is greater than input temperature
temperature=ds18b20_gettemp();//Gets temperature
snprintf(prompt, OUTPUT_STR_SIZE, "Temperature: %4d",temperature);
gfx_mono_draw_string(prompt, 0, 12, &sysfont);//Display temperature
s_flag++;//Increments a seconds flag

m_flag++;//Increment minute flag
s_flag=0;//Sets seconds flag to 0

//Wait 5 minutes if water temperature is to high or temperature falls below set point
//Resets timers and breaks while loop
if(m_flag==5 || temperature<=(i_temp+2)){
s_flag=0;//Set seconds flag to 0
m_flag=0;//Set minute flag to 0

CNC Plotter/Engraver: The Big Picture


For our final project in the embedded systems class we decided to take on creating a laser engraver controlled by user input through a joystick. To do this we first decided what would be needed to hold all of the equipment required to make the engraver work. We decided to create a wooden structure with a dual rail system. This rail system would then allow us to move our laser on the X and Y axis. We then attached a 3 stage stepper motor to the sliding board that would hold our workspace and a band to a stepper motor on the top rail which would guide the laser back and forth.

Skittles Sorter: Technical Details

  1. An amazing video of our project (includes excellent music)

2. Schematic actionSkittles_Schematic

3.  How it all works

Hardware for the skittles sorter included two 180° servos, one 360° servo, a TCS34725 RGB sensor from Adafruit, an RGB LED, an Arduino Uno, and the Atmel A3BU board. The Arduino sent PWM signals to the two 180° servos, which corresponded to angle values between 0° and 180°. The continuous servo also received a PWM value but translated this value to a speed and direction.  The Arduino was incapable of supplying power all components, so the A3BU served as an additional power source.

The star of the show, the RGB sensor (TCS3472), utilized a photodiode array composed of red, green, blue filtered and clear photodiodes, an analog to digital (ADC) converter that converted the photodiode currents to 16 bit values.  The sensor communicated with the Arduino via I2C communication protocol. The Adafruit TCS3472 package also incorporated 3.3V regulator and an onboard LED used to illuminate the target (the skittle). The TCS3472 interfaced with the Arduino by connecting the I2C Clock on the sensor to the SCL (serial clock line) input on the Arduino and the I2C Data on the sensor to the SDA (serial data line) on the Arduino. Adafruit also provided a tutorial and sample code for using the TCS3472.

We planned on using an RGB LED as an indicator light.  We intended for the LED to change color based on the input received from the RGB sensor.  However, mid-project the LED broke and its replacement was not fully functional. Due to time constraints this issue was not investigated further.

The plan for the A3BU was to display a running tab of the number of skittles sorted on its LCD.  We intended to send a digital signal from the Arduino to the A3BU, use this signal to update a variable on the A3BU and display this value on the LCD.  Unfortunately, due to time constraints this sub-project was abandoned. Ultimately, the A3BU was used as an additional power source and to display a simple text phrase on an illuminated LCD.


Mastermind: Schematics

Once the coding was completed for our Mastermind game we just needed to create two circuits: one for the serial communication between TeraTerm and the A3BU, and one to power the LEDs. The communication circuit was the same MAX232 circuit that was used in previous labs, and can be seen on the left side of the breadboard in the picture below. The circuit to power the LEDs we designed ourselves, and can be seen on the right side of the breadboard.


The LED circuit required several components for each LED leg, including a 1K resistor to moderate the current, and a transistor to provide ground.


In our circuit, the LED leg went to the collector of the transistor, and the emitter of the transistor went to ground. Then the outputs from the A3BU (labeled as inputs in the diagram below because we were viewing them as inputs to the transistor, but they are still output pins) would go to the base of the transistor in order to power the leg of the LED and turn it a certain color.


Mastermind: Code

Rather than jumping head first into coding our Mastermind game in Atmel (see “Smoketown USA – The Big Picture” blog post for overview of the game), we thought it would be a better idea for us to get a version of the game working with just code written in C – using the Dev-C++ Bloodshed Software – and then move forward from there. We started by having the program generate four random numbers between 1 and 6. This would be stored in an array and act as the master code. Then the program would prompt the user to enter four numbers ranging from 1 to 6, and store that in a second array. We could then compare each individual element of the input array with all elements of the master array and then tell the user the necessary information about their guess.

Once we had a solid program that worked just from running it in the terminal, we then moved on to begin integrating it into Atmel with our other components. The first component we decided to tackle was setting up the information for the output pins to drive the LEDs. To do this, we used the IOPORT_CREATE_PIN( ) function in order to define a name for each output pin, as shown below:Code_1

Once each output pin was assigned an LED and a color, we could then move on to writing the logic that would turn on each output. To do this, we basically stored a truth table inside a 2D 15×15 array. Each row of the truth table is made up of five groups of three numbers, as shown in the image below. The first number of a group indicates red, the second number of a group indicates green, and the third indicates blue. The first group of three numbers in each row indicate how many of each color LED there: for example, in the first row it shows 4 red LEDs. The next four groups of three indicate the color that each of the four LEDs need to be. So in the first row, all four groups of three have a one in the first position to indicate that all four of the LEDs should be red.


The truth table was mainly used for comparing with the information gathered from the user’s input. Once we calculated the number of digits that were exact (correct digit and correct location) and the number of digits that were close (correct digit and incorrect location) we could then search through the truth table using a few for-loops and if-statements in order to set each of the output pins for the correct LED and color.


Mastermind: The Big Picture

For our final project, we wanted to try to incorporate several concepts from previous projects in order to show what we’ve learned. There were countless possibilities of what we could accomplish, but in the end we decided that we would create our own version of the game Mastermind. This would allow us to build and program everything ourselves to get it working exactly the way we wanted.

The original Mastermind was a board game involving two players: the codemaker and the codebreaker. The code maker would create a pattern of four pegs, with each peg having a variety of possible colors. The code is covered from the second play by a small shield, and then their job is to guess the code. For each guess, there is a spot at the end of the row for four smaller pegs to indicate whether each peg was either: in the correct location and the correct color, a color in the code but in the wrong location, or a color that isn’t in the code.


We decided to make a few changes to the game in order to make it friendlier to use with the A3BU. Rather than trying to figure out how we could use color coded pegs, we decided to switch from a code of colored pegs to a code of digits. The program would randomly generate a four digit code, with the range of digits specified in the code (we used 1-6 most often), and then the user could enter their guess from TeraTerm. Then we wired up each of the three legs from each LED to the output pins on the A3BU, and these LEDs served as the indicator pegs that showed the player information about their guess. If their guess contained a correct number in the correct location, one of the LEDs would turn green. If their guess contained a correct number in an incorrect location, then one of the LEDs would turn blue. If any of the numbers guessed weren’t in the master code at all then that number of LEDs would turn red.

Here is a sample of our finished product: