In the beginning we were thinking about doing a binary calculator, but after brooding over that idea for about a week we changed it to the LED cube. At first we wanted to have the LED cube attach to a different project that was developed by one of our team members, Tayce Lassiter, which is apart of her teaching assistant class. However, seeing as how long it was taking to complete the LED cube, and to program it, we decided to just leave the project to just the LED cube.
Needed to see more of our A3BU calculator? Watch this video with annotation below!
Look at your calculator:
Now back to mine:
Now back at yours. Now back to mine.
Sadly, yours isn’t mine. But if it stopped having such a small screen and switched to A3BUs instead it could look like it was mine.
Look down. Back up. Where are you?
You’re in the snake program on the calculator your calculator could look like.
What’s in your hand? Back at me. I have two buttons for scaling purposes on my calculator.
Look again. The graph just zoomed in!
Anything is possible when your calculator uses an A3BU instead of … that tiny screen.
The purpose of this project was to use the problem solving skills and the knowledge that we gained throughout the semester to create some type of interface with our A3BU. We chose to build a device that would turn a motor at different speeds depending on various colors that the device would be sensing.
The project was broken down into 3 different parts. The first part of the project was communicating with the color senor. This was accomplished by communicating via I2C (Inter-Integrated Circuit) to an Arduino Uno. I2C is a protocol intended to allow multiple slave digital integrated circuits to communicate with one or more master chips. Like SPI (Serial Peripheral Interface), it is only intended for short distance communications within a single device. However, it is also like Asynchronous Serial Interfaces (such as RS-232 or UARTs); it only requires two signal wires to exchange information. These two signals are SCL (the clock signal) and SDA (the data signal). SCL is a particular type of signal that oscillates between a high and low state and is used to coordinate the actions of a circuit. SDA is the physical transfer of data (a digital bit stream) from point-to-point. The second part of the project dealt with sending data from the Arduino to the A3BU. We chose to do this through a single line; TXD from the Arunino to RXD on the A3BU. However, in order to accomplish this we needed to create a voltage divider circuit to step down the 5V from the Arduino to 3.3V (the maximum voltage for the A3BU). The third part of this lab dealt with driving a DC motor. After the color sensor detects either a blue, red, yellow, or green card, the data is sent from the color sensor to the Arduino and then to the A3BU via TXD/RXD. We wanted to control the motor’s speed based on which color is detected. This was accomplished by using Pulse Width Modulation (PWM). In the code, when green is sensed by the color sensor, there is an 80% duty cycle of 3.3V applied to the motor circuit, which causes the motor to spin at a high speed. When yellow is sensed there is a 60% duty cycle, which causes the motor to spin at a lower speed. When red is detected, there is a 0% duty cycle, which stops the motor. Blue is used as an initialization.
At the end of the lab we were able to create a device that would turn a fan at different speeds based on what color is detected. By doing this we were able to gain a much better understanding of I2C, how to communicate amongst microcontrollers, and how to create and implement a circuit to drive a motor.
It all starts with the base! This is where our 8x8x8 LED cube will sit on so that we can keep it as neat as possible when wiring. The wooden cube was manufactured by our team member, Tayce, and allowed us to keep all of the components snug.
Starting out we had to create our individual layers. Since we created an 8x8x8 LED cube we had to create 8 layers of 64 LEDS with half an inch gape between each LED.
After we completed soldering all 8 layers we then proceeded to solder the layers on top of each other with half an inch spacing. This required 2 people to accomplish: one to hold the new layer being soldered, and the other soldering the next layer.
This is the completed 8x8x8 LED cube which resulted in 1024 solder joints, which does not include the soldering done on the board, and the wires that hook up the board to the cube. In total this build took about six weeks to accomplish.
This is the board that is hooked up to the LED cube. The ones marked with numbers are the 74HC574 which are our LED drivers, and the two in the middle are our decoders 74HC138E. The decoders basically send a clock a signal to the LED drivers which in turn control which LED will get turned on. This works by giving the programmer the ability to control the LEDS in the X, Y, and Z direction.
This is a brand new technology, one that will inevitably alter the way in which engineering students everywhere will learn how to graph mathematical functions. Team 5.2 presents to you – the graphing calculator!
Wait, that was already invented?
Well, please enjoy this teaser of how our graphing works. You’ll see a plot of the function sin(x) with an inbuilt horizontal scaling being used. Later we’ll explain more about how this works.
Once we had our housing printed and a working circuit we were ready to begin the assembly process. Then we realized we missed something, the use of the A3BU microcontroller. We were not entirely sure if the project needed to incorporate the A3BU but we decided to use it just to be safe. The sole purpose of the A3BU in this project is to act as a button.
Implementing the A3BU:
On the Saturday night before the project was due Marcus and David began the process of adding the A3BU to our project. We started by trying to write a program that would output a high voltage from a pin on the A3BU to be read by the Arduino to start the sounds and lights routine. Soon it was clear that we were not going to get this method to work without the ICE-3, which we conveniently left in the ECE lab and didn’t have with us at the First Build facility. The next option was to bypass the software of the A3BU all together.
We noticed on some of the A3BU schematics that when a 5v source was connect to the power in of the A3BU the buttons on the chip became active. In particular, there was one button that exposed its output on the back of the board. We tested this by using a multimeter with one end on the ground and the other on the TP304 (see below) plate. When the button was pressed the TP304 plate would drop to 0.0v from the steady 3.3v it was at. This means that we could use this A3BU button without any software at all.
Diagram of the A3BU button we hacked.
We soldered a wire to the back of the A3BU board and lead it to a digital input pin on the Arduino to trigger the routines we wanted. At this point we had the Arduino powered by a battery but the A3BU still needed to be connected to a computer for power. We wanted to eliminate this connection to the computer. This is where we got really fancy.
Again, we used a multimeter to check where the 5v from the power source was leaving the usb connection to the voltage regulator on the A3BU chip. We discovered the one of the legs connecting the mini-usb port to the board was carrying 5v when power was connected. We used a continuity test with that leg and the TP304 plate and discovered thats how the 5v travels to the rest of the chip. With this new knowledge we were able to solder a wire from the 5v output on the Arduino to the leg on the A3BU that distributes the power on the A3BU. We were able to successfully power both microcontrollers with a single 9v battery connected to the Arduino.
In the code we used an interrupt to set a variable to either “on” or “off” when the button on the A3BU was pressed. Essentially, we created the most complicated button of all time.
How it looks:
To make the components fit into the housing better we ditched the large bread board for a small piece of protoboard. Once we had the entire project working exactly how we wanted, we soldered the pieces to the protoboard permanently. We used the ground and the 5v source from the Arduino to create hot and ground rails on the protoboard. Once the entire circuit was contained on the protoboard we started the difficult and delicate process of stuffing the components into the housing. After a lot of concentration the below picture shows the final result of the component compartment:
The only thing hanging out of the housing is the battery supply cord so we can turn the entire project on or off easily.
When the project is first powered on it is in a standby mode. The LED array “breathes” and changes colors as time goes by. Once the button on the A3BU (which is accessed from the components compartment opening) is pressed the A3BU sends an interrupt and starts the music and lights routine. A tone will begin to play and a certain number of LEDs will light up on the array. As the knob is turned the tone changes pitch and the amount of LEDs that are lit up change. The LEDs change color as more LEDs are lit. For example the left most LED column is all green, the middle few are yellow, then orange, and the right most are red. See the video below for a short demo:
This project was an overall success. The device works exactly how we envisioned it from the start. The team was exposed to many new electrical and programatic challenges along the way but we were able to work together to overcome the obstacles. We were also introduced to the First Build community from spending so much time there, we now all feel comfortable with using their resources more ofter.
We think that the use of an Arduino allowed us to push the limits of what this project was capable of. The ease of use allowed us to rapidly prototype and trouble shoot without wasting a lot of time fighting with a more robust microcontroller. Although we did not use the A3BU extensively in this project I think we gained a new understanding for it by using its internal hardware against itself to supply us with a button without the use of software. We think that future projects in this course will benefit from using a more popular microcontroller like the Arduino Uno. This is mainly because students will not have to spend their time setting up a project and getting familiar to the complicated environment of Atmel Studio and just dive right in to reading digital input or pushing a desired voltage to external components.
We are very happy with our end result and are extremely proud of it. The 3D printed housing give the project the esthetic component we were looking for from the start.
At this stage of the project, we had an idea and a loose design. It was now time to star making our vision a reality. We started by just getting the basic circuitry on the speaker working with a variable resistor to change the tone. The image below shows our first successful circuit to generate tones based on varying resistance.
As you can see we have an 8 ohm speaker connected to variable resistor then connected to an analog read pin on the Arduino Uno. When the resistance would change the value was read in and mapped to a tone within the human audible range.
The code above shows how the value of the resistance was read from the pin analog pin A0 and then mapped to within our desired tone range. We are using a third party Arduino tone library to allow us for more customization of the tone itself along with a higher quality tone. The toneAC library allows for high frequency and faster tone switching. In the stock tone library we were experiencing a regular click when switching tones.
Soon we realized that the ECE lab was just not cutting it for us. Team DND headed over to first build to continue our work. We wanted to use the first build facilities mainly because of the quality of tools and space available to work. We wanted to use the speaker from an old pair of desktop speakers and we knew first build would have the tools to let us tear them out. One team member, David Exe, is a member of the rocket team so we had access to many tools well past the First Build regular hours. We also got to play on the 3D printer!
Tim and Bobby working hard.
In the below video and picture you can see the maker-bot beginning to print out our design from the previous blog post. We had some issues getting the printer to start our design but it was resolved when we discovered the platform it was trying to print on was not level. When the platform is not leveled the maker-bot cannot print because the printing head will drag along the surface thus jamming the extruder.
The maker-bot hard at work.
18 hours later it was completed!
When the piece was finished, right away we realized that there was something wrong. The piece was much too small. What had happened was that we edited an earlier mock up to better fit our pieces and when we went to print, we accidentally used the older version of the design and that resulted in an incorrect piece. Rather than wasting another 18 hours waiting for the printer to finish we decided to make it work.
When we first started discussing a final project idea, a lot of wild concepts were thrown around. We discussed the idea of a making a bluetooth connected scoreboard for our heated summer volleyball games. The scoreboard would be made up of several 7-segment displays and have a communication bridge via bluetooth to a fitness wearable device. The wearable device would then act as the remote to the scoreboard to increase or decrease the score wirelessly. We began to wrap our heads around the project and soon realized that unfortunately the project was too far off our budget to pull off.
The second and final idea we took of the whiteboard was to make a music box and visualizer. The idea of this project was to have a knob or tone control to change the tone and pitch of a speaker. This tone would then have a corresponding visual element that was undecided at the start of the project. We wanted a way to house the project so it had an aesthetic appeal along with impressive technical abilities. This is when the group looked to 3D printing a case.
The above image was made in a free 3D modeling software, 123D Design on a Macbook Pro. The square hole on the top was designed to house the speaker and LED array. Its width and length were designed to be 0.1mm smaller than the LED array so that it could be press fit into place. The square whole to the right of the team name was designed to house all of the microcontroller and wiring components. There is a wall separating the two square holes inside the housing with a small channel to allow wires to connect between the openings. The circular opening on the top of the design was to allow a variable resistor to stick out, giving the user control over the tone and visuals. There is also an array of square holes on the face of the design. This was originally intended to be the speaker grill to allow the audio from the speaker to travel outside the housing.
In the following blog posts, it will become clear why the words “originally intended” were used.
For our project, we decided to purchase and use a Nokia Graphic LCD display to have a bigger display. At first it seemed easy to just plug the right wires in and make the LCD to work. Here’s a graphical representation of what the LCD looks like connected to an Arduino.
We hooked up the A3BU accordingly. When it came to converting the code for Arduino to a code that’d work with A3BU, we noticed we would need to write a driver from scratch for the Philips PCD8544 display controller to work with A3BU.
We started developing a simple driver for the PCD8544 display. Upon more research we realized that the LCD protocol is 9-bit SPI verses the AVR microcontroller series only support 8-bit mode. The LCD display could work with the 8-bit AVR microcontroller but we would need to implement additional software SPI output for it. Since the project scope doesn’t allow us to spend more time on it, we decided to go back to the good old LCD display for the A3BU which it’d make things much easier since we’re familiar with ST7565R LCD controller :).
(See Fall 2015 flappy bird project for a creative workaround to using the Nokia LCD with the A3BU!)
First, the code driving it is fairly simple. The main initializes the board, the delays, and the IO ports. Then each pin that is being utilized in the project is set as either an input or output, depending on its functionality, with J1’s pins 0-2 being the input pins, J3 pins 0-2 and J2 pins 3-7 being the output pins for the LEDs. All the pins are then set to low, and the game starts. When the game starts, the input pins are enabled, and a while loop is entered:
//Waits until the player selects his option
As stated before, the pins that are referenced are the three input pins, corresponding to Rock, Paper, and Scissors respectively. This while loop stays active until one of the IO Pins are seen as being at a high logic value, and the corresponding selection is made for player 2, AKA the human player. (The first line of it where every pin is checked for being high was to combat some of the anomalies we had reached, and it was found that this did help filter some of them out.)
After the user inputs a value the pins for inputs are disabled, and the computer randomly selects a number between 1 and 3 for its selection.
After this a function is entered that lights up the selection LEDs by setting the corresponding pins as high for both the player and the computer for one second. Those pins are then set to low again, turning off the LEDs.
else if(player1selection==3 && player2selection==2)
//Set P1 P and C S
Next the code compares the computer and user selections to determine a winner, and the correct winner LED is lit up (if it is a tie then both of the red LEDs light up) for 3 seconds before turning off.
The computer’s and player’s selections are then reset to 0, all the pins being used set to low again, and finally the function that runs the game is run again, repeating the process until the power is cut to the board. (There is currently no end state for the game. Ideally we would have wanted to implement another couple selection buttons to indicate if a person wanted to stop playing, but we did not have time to implement it. So for now, you’re stuck playing. FOREVER. Or until you walk away. Or cut the power. Or unwire something. Or punch it.)