Alejandra, David, Tirza, and Tristan’s Documentation

For the midterm, our class was divided into 5 groups, with each group having to make a ‘section’ of Rube Goldberg machine that talks to another group’s ‘section’. Our group decided to make a car that reads NFC cards along a designated track and then sends a character to the next group when it reads the last NFC card.

Our group didn’t decide to make the car right away. Initially, we wanted to make a lift that carries a teddy bear with an NFC reader mounted on it. However, we figured that it would’ve taken more time than we actually had. We then pivoted to making the reader goes horizontal instead of vertical.

That’s how we decided to make a car that would basically have the same function as the lift as it would also have an NFC reader mounted on it and read tags as it went along its way. Building the car was fairly straightforward. We used two sets of motor wheels and taped them to an Arduino. We then mounted an Xbee shield and a NFC reader to it

We didn’t run into any meaningful problem until we had to figure out how to power the car. We originally wanted to power it with a 5-volt battery. However, we figured that 1) there wasn’t any 5-v battery (or the combination of it), 2) we couldn’t figure out how to use the voltage regulator that we could’ve used with the 9-v battery, 3) the battery that we could’ve used to power the car was too heavy for the car. We eventually resorted to powering the car through the USB cable. However, as we approached the final show, we realised that the power wasn’t enough for the car. The NFC reader turned out to be more power-consuming than we had anticipated. To solve this, we connected the NFC reader to the other group’s arduino that’s connected to the socket.

17548892_10212527007480841_417538099_o (1)

Shout out to those cables who *stuck through* the good and bad times!

Another problem we ran into while building our section of the Rube Goldberg Machine was that the NFC reader needed to be really close to the cards we had. In order to solve this issue, we built a track for our car. However, this didn’t solve the problem completely. We had to try different configurations of the cards along the track so that the car with the NFC reader could read them properly.  Taping the cards to the inside part of our cardboard track in a horizontal line is what worked best.

Finally, another *classic* problem that kept on showing up was the loose cables. The cable got off the board a couple of *few* times. Looking back, we should probably have soldered the wires. However, for a project where we constantly try to figure out which wire goes where, the breadboard was actually a good option. This surely caused us to have to constantly check on the cables, but we had the flexibility of removing and adding cables.


Our track and the RFID cards.


The rainbowduino was used in the project to display a countdown of numbers, going from 3 to 0, as the car went along its track. The rainbowduino, when paired to the super bright 8×8 led dot matrix display, has no digital pins available for an Xbee to plug into, only the serial communication ports and I2C ports. Because of this, we used another Arduino Mega paired with an Xbee to communicate with the rainbowduino via one of its many serial ports. The Mega was perfect for this as it could communicate with the Xbee via the original RX,TX ports, and also communicate with the rainbowduino as well. The Mega’s purpose at this point was to simply relay information from the other Xbee on the car to the rainbowduino.

In order to connect to the next group, group 3, we chose to use an I2C connection from the rainbowduino to the next group’s arduino. Doing this was easy, as we just had to connect two wires and make sure we had common ground, and then add a snippet into the code to instantiate and use the I2C wire connection send a 1 over to the next Arduino, activating the next step.

Week 7: Midterm Project (Fitzgerald)

Partners: Elaine, Tisa, Diana

For this project me, Elaine and Diana decided to focus on three main parts – starting with the on-screen animation in Processing, having a physical part which would cut a string and final part which was inspired by the Newton’s cradle.

I have created the Processing part of the ball which jumps from the left side of the screen towards the right side of the screen. The opening of the Processing sketch is triggered by the previous group’s data being sent over via Bluetooth. We have decided to play with the processing sketch after the initial ball was made and Elaine added the smiley face on the ball.

After the ball has touched the very right part of the screen, the structure which Elaine worked on was triggered – the knife which would cut the string, onto which a bag of coins was attached on. The knife would initially be in the horizontal position, but then it would pop up on the 90 degrees and cut the red sewing string. On the string, a bag of 5 coins was attached, which made the bag itself heavier, thus once the string was cut, the force of the string swing would be great enough to trigger our next structure. Initially, we have had some issues with this structure, because we have places the string underneath the knife, so the knife was not able to cut the string. Another problem that we came across was that knife is very hard to manipulate, especially because it is very dangerous, so the instances when we needed to fix it were quite tricky. After we have had the knife working for the first time, the knife would not work when we tried it in class, because the gears that the knife was attached to had trouble working. However, after playing with the gears, we were able to make them work!

Below is how our construct looked like.


The third part of the construct was the part that Diana worked on which included the NFC chip RFID reader and reading the data when the two connect. As the baggie with coins swung from above after the knife itself has cut it, the baggie hit the small structure made out of foam, which had an NFC chip attached to it. Diana has decided to additionally print out a human like a picture in order to add to the atmosphere of the construction  – the little human is afraid of being hit by the big bag of coins, and that is why he is making a scary face and leaning away. The piece of foam onto which the little human was attached had a red pen going through it and another piece of a bigger foam construct onto which it was attached, so the smaller piece of foam could move, more specifically turn around from being in the 90 degrees position, to 0 degrees position, which meant touching the RFID reader with the chip. During working on this part we had some trouble with NFC chip and RFID reader working, however, after putting it in the position in which it was easier to read it, we were able to make it function in the way in which we wanted to!

Here is the picture of how the construction looked like up close.

File_000 (1)












Although we had some trouble with making our project work during the midterm class itself, we had it working both before and after the class, and here is our final video where it is showed how our project worked. All three of us were very happy with how our project worked and we have learned a lot on how to use different types of communication technologies, such as RFID, bluetooth, and the physical parts while doing it!

Sidra Manzoor, Nicholas Sanchez & Jingyi Sun Week 7: Rube Goldberg Pt.2

for previous documentation : CLICK THIS LINK

See video above for the entire thing, and for much excitement from Sidra and I.

Quick recap of last week’s progress:

When beginning this exercise, we only had the ideas of using marbles and a slide. The brainstorming process began with this initial facet, which was then expanded upon. However, the final product was not fully conceived during this part, as the physical construction of our Rube Goldberg segment was partially improvised during construction. Trial and error helped us finesse the design and turn it into something feasible and working.

Before construction began, our team went to several small hardware stores and looked at the raw building materials these stores sold. This was in part to get inspiration, and in part to see what was available to us. We bought some supplies, like toy cars, a ramp, a clear hose, and  toilet plunger, jus to test out ideas and star constructing something. In addition, we borrowed the frame from another IMA project and used it a structure to design our segment.

We decided on ordering marbles and placing them within the suction cup of the plunger. We drilled a hole in the plunger so that it would act like a funnel and basin to hold the marbled. Then, after drilling a hole atop the frame, we attached the plunger head to top of the frame above this hole. We then used fishing wire to painstakingly suspend the clear hose from the frame’s top hold and spiral it down. The idea was that marbles may drop from the plunger down through the hose. Unfortunately, the marbles we ordered were too large and often got stuck somewhere in the hole. So, we had to order new marbles.

This week:

After last time, we started out by testing our cars on the ramp along with the dominos. At this point our marbles finally arrived so we could test them to see how many we would need to push the topmost car down the ramp (this was roughly 6-7 marbles).

The main problems during testing:

  • There was an opening around the sides of the top servo motor which was big enough to let marbles through and so every time our motor rotated, we had some marbles flying off in random directions instead of going through the pipe. Due to this sometimes the flyaway marbles would knock down some dominos and break the chain even before the cars reached the bottom. This prevented the handshake from happening. In order to solve this problem, we put tape around the top servo to prevent the marbles from falling down. Surprisingly, this worked!
  • Another problem we had was that our cars did not go down the ramp in a straight path. Due to this, sometimes they would completely miss the domino chain at the bottom. To prevent this, we simply cut a new ramp and adjusted the heights of the steps using bamboo columns, boxes and tape rolls.
  • Sometimes when the dominos fell, the last one would not connect the circuit, so we increased the conductive area, and tested repeatedly how and where the dominos would fall.

The communication part with the x-bees, once we tested with the other groups and got it to work, worked very reliably. No complaints there.

Writing the code was also fairly straightforward, we struggled a bit because simply writing if (inByte = ‘N’) {do things} was not giving the motor enough time to turn on, so in the end we used a lot of booleans to create states to activate motors.

Our end output:

We receive data from Group 4 (N to initiate, S to start), which starts the motor on top. The motor lets the marbles go through the tunnel, and after the marbles would descend to the base, the idea was for them to knock a toy car down a ramp, which would then knock down another car, and then another. We used a plastic, seven foot bracket to make this ramp, with a resting space for each car to make contact with the next. Once the final car had fallen, it would then knock over a few dominoes. The last domino is coated with conductive tape, and when it falls, it closes the pullup switch circuit attached to pin 6. This then sends a signal to Scott’s xbee (A), and when his xbee sends an “r” back, which activates the flag attached to the bottom arduino, and we send an Z, thus triggering the final grading machine.

Midterm project, Rube Goldberg machine’s first part, Robert, Olesia and Mel

To begin, I guess I should say how happy I am right now that everything worked for everyone! In the beginning, I am always anxious as to what will be the outcome. I also tend to be not super ambitious.

Since we were the first group, our task was to receive a signal from Scott via Bluetooth which will trigger the gate’s opening and the ball’s movement. At the end, we send the signal via xbee to the second group. Having said that, let me now explain the working process. First, we improvised and built a tramp, a gate, and a box. Our first step was to hook up 2 servos with the cardboard construction we had made. One servo controls the opening of the gate while the second controls the angle of the cardboard tramp. We didn’t have any problems with that part since the code is super simple and pretty straightforward. Our next step was to connect the Bluetooth modem to the board in order to receive signals from Scott. Honestly, this took me the longest to figure out. God bless Robert for helping me with Bluetooth modem. Because of my karma, I changed around 3 Bluetooth modems because none of them would work properly. It happened to me when before when I was working on our first Bluetooth assignment; something would not work all the time. So I guess I have this Bluetooth curse. Once we found a proper modem everything worked fine. Next step was to connect the xbee modem to the second group’s one. It was ok because we had been working on xbee right before the midterm projects so there was no need to refresh our memory. I’d say the xbee part worked the best. Finally, since were done with all the key parts pretty soon, we decided to add some spark to the project. The literal spark. We found a metal ring, glued paper to it and taped motor with a lighter attached to it. To make the motor move in the right direction, we had to go through some trial and error. Unfortunately, we didn’t get a permission to light the ring of fire indoors but we are hoping to implement this idea in our further projects. Nonetheless, the motor and the lighter work, if needed, they will light up the ring of fire. It works the following way: we receive a “G” from Scott, this signal opens the gate, the tramp adjusts the angles, the ball goes down, jumps onto another tramp, goes through the ring of fire and then falls down into a box with a vibration sensor that triggers xbee to send the code to the next group. It is all simple but effective.

To be honest, we didn’t have any major hindrances since we all worked as a team and tried to help each other with whatever problems we had. Everything went smoothly and no cats were burnt throughout the process of preparation. Just kidding. One was burnt.

Overall, I enjoyed the process a lot and recalled many things we learned in class while working on this fun project. And since this website wouldn’t let me upload files bigger than 100 mb, I am posting a link to my google drive with the complete video of the machine’s craziness.

Rube Goldberg Machine Project (Gabriela, Peter, Angelica)

The part we built is consist of two tracks, three gates and a ball. The system takes a signal via I2C from the previous group, and triggers the first gate to open to let the ball roll down. After that, the ball will pass two other gates and hit the bottom of the second track. When the sensor at the bottom of the track senses the compact, a signal will be sent to the next group via bluetooth.


  1. I2C

The way of connection we use to communicate with the previous group is through I2C. To be specific, we connect the GND, SDA, and SDL pins of the two Arduino UNOs together. Then, we use the Wire library to pass and accept data. Our Arduino is set as the receiver (i.e. the slave Arduino), and waits for a “1” to trigger the whole system. The idea of I2C is raised by the previous group, and we thought that this is a very good idea since I2C is very convenient to handle. For this part, we had some problem with reaching a consensus on the data. The idea of the previous group is that, the “1” that will trigger us would be only sent once, and all the other data would be 0. However, initially our group was expecting for “all ones” after we are triggered. Eventually, we revised our code so that our system would ignore whatever is sent from the other group once we are triggered.

2. Bluetooth

As usual, bluetooth is troublesome. This time, we were able to connect bluetooth smoothly when testing. However, when we are about to show on the second class, something weird happened. The next group was continuously printing out “0”. We thought that this indicates that the connection is successful, and the problem might be in our code. However, it finally turns out that, no matter whether the connection is successful, the next group would always print out “0”. Luckily, we were able to find out where the problem is in class. We forgot to plug in the TX and RX pin! What a silly mistake. Therefore, there are two main take-aways we got from this. First, we should alway set parameters for detecting all the states, for instance the state of connection failure should have been detected in this case. Second, a check-list should be made when there are too many things going on. For example, the TX and RX are disconnected for the convenience of uploading code, but it causes serious problems when you forgot to plug it back in when running the system.


  1. Piezo disk vibration sensor.

We used three disk vibration sensor to sense the arrival of the ball. The first two sensors controls the gates to open when the ball arrives, and the third sensor triggers the command data to be sent to the next group when the ball hits the bottom of the track. At the beginning, we were worried that the piezo disk vibration sensor might not be sensitive enough to sense the ball, and then we found out that this is not a problem as long as the ball is heavy enough. The true problem we then met was entirely the opposite, the sensors are way more sensitive then we had expected. Sometimes, a gate opens will the ball has not even arrived. To solve this problem, we built a correlation between the gates, that is, the next gate is not allowed to open in any cases as long as the immediate previous gate has not been opened.

2. Servo

The firmware we used for controlling the gate is servo (5V – 7.4V, 5kg). We chose this kind of servo since it is strong and fair in size. They worked very well for the most part however, the batteries went out on the second class when we are about to show the system. It was not until then that we had realised how much power servos consumes. Fortunately, we fixed this problem simply by using new batteries.


We have improved our Goldberg Machine Component significantly as we redesigned it from scratch. Now the tracks are laser cut and neat. Wiring is less messy as well. In class we checked whether Xbee and Bluetooth communication between our device and other groups’ devices works, so this part is done. The concept changed a bit too, because the first gate does not need a vibration sensor as it opens once we receive data from the preceding group. We are going to send “1” via Bluetooth to another group once the ball reaches the end of the track where the 3rd vibration sensor is located. Here is the end result of our work:

Screen Shot 2017-03-24 at 11.35.42

In addition, it is worth mentioning that we tried making our machines as nice-looking as possible, because Rube Goldberg is all about the unusual and interesting looks.

In this video we are testing (to be sure everything works as intended) whether servos and vibration sensors function properly:


In this video we are testing if gates open properly when data is incoming and whether data is being sent once the ball reaches the last vibration sensor; test passed, everything works:

Finally, our code as written yesterday can be seen below (we also added sound when gates open).

/*Network Everything midterm
  Three servos controlled by three piezo disk vibration sensors.
  Each time when one of the sensors gets hit by the ball, it would
  activate the servo it corresponds to, and opens a gate to let the
  bal move forward.
  @author: Xincheng Huang (Peter)
  Date: Mar 18th, 2017
  Credit to Piezo sample code from DFRduino, and arduino sample code
  from Servo library

#include <Servo.h>
#include <Wire.h>
#include "pitches.h"

//switch to true on the previous group's signal
boolean trigger = false;
boolean play1 = true;
boolean play2 = true;
boolean play3 = true;

//The incoming Byte. No data: -1; Standing by: other data; Triggered: 1.
int start = -1;

//The Byte to send
String send_msg = "0";

//servo ports
int servoPort1 = 9;  //waits for the command from the previous group
int servoPort2 = 10; //piezo1
int servoPort3 = 11; //piezo2

//piezo ports
int piezoPort1 = 0; //servo2
int piezoPort2 = 1; //servo3
int piezoPort3 = 2; //send command to the subsequent group

//piezo values
int piezoValue1 = 0;
int piezoValue2 = 0;
int piezoValue3 = 0;

//gate state control
boolean gate1 = false;
boolean gate2 = false;
boolean gate3 = false;

//Servo value
int servoValue1 = 90;
int servoValue2 = 90;
int servoValue3 = 0;

//Music notes
int melody1[] = {

int noteDurations1[] = {
  4, 4, 4, 2

int melody2[] = {

int noteDurations2[] = {
  8, 4, 8, 4, 4

int melody3[] = {

int noteDurations3[] = {
  8, 4, 8, 4, 4

Servo servo1;
Servo servo2;
Servo servo3;

void setup() {
  pinMode(12, OUTPUT);

void loop() {
  //  if (trigger == false) {
  //Serial.println("standing by...");
  //  } else if (trigger == true) {
  piezoValue1 = analogRead(piezoPort1);
  piezoValue2 = analogRead(piezoPort2);
  piezoValue3 = analogRead(piezoPort3);
  //  Serial.print(piezoValue1, DEC);
  //  Serial.print(" ");
  //  Serial.print(piezoValue2, DEC);
  //  Serial.print(" ");
  //  Serial.println(piezoValue3, DEC);
  //    Serial.println(servoValue1, DEC);

void servoInitiate() {
  //  servo4.write(0);

void gatesStates() {
  //sensor value pending revision
  if (trigger == true) {
    if (play1 == true) {
      play1 = false;
    gate1 = true;
  if (piezoValue1 > 50 && gate1 == true) {
    if (play2 == true) {
      play2 = false;
    gate2 = true;
  if (piezoValue2 > 50 && gate2 == true) {
    if (play3 == true) {
      play3 = false;
    gate3 = true;

void gatesOpen() {
  if (gate1 == true) {
    if (servoValue1 > 0) {
  if (gate2 == true) {
    if (servoValue2 > 0) {
  if (gate3 == true) {
    if (servoValue3 < 90) {

void receiveEvent(int howMany) {
  if (Wire.available() > 0) { // loop through all but the last
    start =;
  if (start == 1) {
    trigger = true;

void sender() {
  if (piezoValue3 > 50 && gate3 == true) {
    send_msg = "1";
//  Serial.println(send_msg);
  if (send_msg == "1") {
    digitalWrite(12, HIGH);

void music(int i) {
  if (i == 1) {
    for (int thisNote = 0; thisNote < 4; thisNote++) {

      // to calculate the note duration, take one seco
      // divided by the note type.
      //e.g. quarter note = 1000 / 4, eighth note = 1000/8, etc.
      int noteDuration = 1000 / noteDurations1[thisNote];
      tone(8, melody1[thisNote], noteDuration);

      // to distinguish the notes, set a minimum time between them.
      // the note's duration + 30% seems to work well:
      int pauseBetweenNotes = noteDuration * 1.30;
      // stop the tone playing:
  if (i == 2) {
    for (int thisNote = 0; thisNote < 6; thisNote++) {

      // to calculate the note duration, take one seco
      // divided by the note type.
      //e.g. quarter note = 1000 / 4, eighth note = 1000/8, etc.
      int noteDuration = 1000 / noteDurations2[thisNote];
      tone(8, melody2[thisNote], noteDuration);

      // to distinguish the notes, set a minimum time between them.
      // the note's duration + 30% seems to work well:
      int pauseBetweenNotes = noteDuration * 1.30;
      // stop the tone playing:
  if (i == 3) {
    for (int thisNote = 0; thisNote < 6; thisNote++) {

      // to calculate the note duration, take one seco
      // divided by the note type.
      //e.g. quarter note = 1000 / 4, eighth note = 1000/8, etc.
      int noteDuration = 1000 / noteDurations3[thisNote];
      tone(8, melody3[thisNote], noteDuration);

      // to distinguish the notes, set a minimum time between them.
      // the note's duration + 30% seems to work well:
      int pauseBetweenNotes = noteDuration * 1.30;
      // stop the tone playing:

Midterm Preparation Gabriela, Peter, Angelica

For this project we used 3 servos and 3 vibration sensors. Initially, we’ve head some problems as vibration sensors were too sensitive, but eventually, we coped with this issue and everything worked as intended and the end result is shown in the last video. For this prototype, we used mostly cardboard.

Photo 1: Creating the track.


Photo 2: Adding another track. WechatIMG2

Photo 3: Tracks are set up and read to use. WechatIMG5 WechatIMG6Photo 4: Ready to attach servos (they can bear up to 5 kg each). 

Photo 5: Gates added to servos (we used transparent tape). WechatIMG9

Photo 6: First servo added. WechatIMG10

Photo 7: Enthusiastic group selfie. WechatIMG13

Video 1: First servo works well.

Video 2: Servo test 2.

Video 3: All servos working.

Video 4: Servo working well, close-up,.


Sidra Manzoor, Nicholas Sanchez & Jingyi Sun Week 6: Rube Goldberg Pt.1

What’s working: toiler plunger (NEW!!!) as a funnel, motor stopper to let the marbles down, marbles (well, skittles/clay balls for now) going down the tube, cars hitting one another down the pvc track, flag attached to second motor.

What is arriving soon: marbles, dominos.

What needs to be done: test out marbles to see if force is strong enough to push car, test out car’s ability to push dominos, attaching top motor to arduino #1 to receive data via bluetooth/xbee and move motor, attaching bottom motor to arduino #2 to raise small flag once dominos hit piezo sensor, and send data out via bluetooth/xbee.

Process for getting to where we are right now:

We bought most of the stuff from our friendly neighborhood hardware store, and started building today. We recycled (with permission) a wooden frame some of our fellow IMA classmates built for their Interactive Installation project last semester. We spent a solid hour and a half enlarging the hole at the top of the frame to let the funnel through. Meanwhile, we prototyped and laser cut a motor stopper at the top, and cut a hole at the bottom of the toilet plunger (NEW!!!). We spent some more time taping the clear tubing to the frame, and failing miserably. We ended up using fishing wire to hold it up instead. We set up the pvc track and propped it up using cardboard and another extra tube Nicholas had for his capstone, and connected it to a clear acrylic tube at the bottom.

We did not take any photos during the process, but hopefully the video above is sufficient.


Update March 22nd:

We bought smaller marbles, made everything a bit more secure, tested out cars and dominos.

What needs to be done: attaching top motor to arduino to receive data via xbee and move motor, attaching bottom motor to arduino to raise small flag once dominos hit piezo sensor, and send data out via xbee.

NFC Tag Week

For this week’s lab, we were to explore communications with NFC tags. Gabriela and I decided to write links on the NFC tags, which was done through our mobile application ( NFC Tools). On the card, we wrote a link to a travel guide website and a link that will open Google Maps, showing us how to get to Hong Kong. The process itself was rather simple. We used NFC Tools to read and write onto our NFC tag. 



We also tried writing onto our laundry card (and metro card!), but as expected, it wasn’t exactly successful.

Another thing that we tried to do was making the NFC card control our previous game. We first tried to make the example code read our NFC tag (and therefore make our NFC tag trigger an action on Processing). We first tried to make Arduino to read the first bit of our card’s UID and communicated it serially to Processing. This part, we got it right. However, we couldn’t make Processing trigger the function we want to run with the UID value. 

During our presentation in class, I figured that it has something to do with the SerialEvent() function on Processing. The example code would be triggered if there was more than 13 digits of the UID value. However, since ours was just 3 digits, the function won’t be called.

In conclusion, I personally really enjoy this week’s assignment. As I figured out why my processing code wasn’t working, I got to learn

RFID Assignment

Team: Angelica, Tristan & Sidra

This week our project was inspired by the card game “Yu-Gi-Oh”. Just like the game, we wanted to make the monsters appear if a card was used. In order to do that, we used mifare cards to start different videos on processing which would then make the monsters appear onto a hologram projector.

In order to make the hologram projector, we laser cut four triangular parts and taped them together. The most important part for the projection was to maintain a 45 degree angle with the computer that had the processing sketch with the video playing on it. Initially, we were using a phone screen to project the videos but that did not work since the screen was too small relative to the projector and thus the projected images were too small to see. Afterwards, we tested it with a computer screen and it worked!


Here’s a video of us testing out the different cards and showing the different holograms:


Here’s the projector that we made:

IMG_7962 (1)

NFC Tags, Olesia and Mel

17349457_1276686142421912_2132433355_oMel and I thought for a long time on what we wanted to do. First, we wanted to trigger some music in processing but later we changed our mind. I realised that my Samsung tablet has NFC, so we figured we could play with it and do something cool. So, we found an app called NFC tools which allows you to assign values to NFC chips. I downloaded it and everything worked perfectly fine. We were able to trigger my youtube channel when the chip touches my tablet. However, due to my karma, my tablet died yesterday and I have to take it to get it fixed. Thank God Gabriela let me use her phone to do documentation because otherwise we would be devastated. Turns out, she did the same thing with her partner which is really cool! The screenshot shows the new value stored on the NFC chip.


As for Arduino, we just managed to read the tag values in Processing. Moreover, since the app allowed us to assign values to the NFC chip, Arduino’s serial monitor shows the new values of the chip.

Overall, this assignment was really fun. Unfortunately, we will not be able to show the final outcome since the phone doesn’t belong to us. So watch the video and enjoy!