Week 8 - Journal

Starting with the software, since we’ve just begun the electronics milestone, I still relied on Tinkercad as a safe and practical way to simulate circuits before moving to real-life testing. It’s very handy for checking connections and code without the risk of burning out components 😅

Another software that we used this week was the Arduino IDE. It was introduced to us as a more advanced alternative to the Tinkercad block-based coding method. Unlike blocks, the Arduino IDE allows us to write actual code, which provides much greater flexibility and control. Since it is open-source, it offers a wide range of libraries and resources that expand the hardware’s capabilities. In addition, programming through the IDE creates a faster and more direct communication between the hardware and the code, making the system more reliable and efficient. Overall, the Arduino IDE opened the door to more complex and powerful projects compared to the limitations of block coding. 

In addition to using Arduino IDE for coding, I also worked with the Arduino Bluetooth Control app to serve as the main interface between the user and the game. This app allowed me to easily send commands from my phone to the Arduino through the Bluetooth module, making the interaction smooth and responsive. I found it to be very user-friendly, with a clean interface that made testing and controlling the game straightforward.

What impressed me the most was how seamlessly it bridged the gap between hardware and the mobile device—pressing a button on the app instantly triggered actions on my Arduino setup. This not only saved me time in designing a custom interface but also made the overall experience feel more polished and professional. It was definitely an essential tool in bringing the reaction game to life.

After deciding to build a reaction-based game, I moved into Tinkercad to begin the design and preparation process. I started by dragging and placing the necessary components:

• Arduino Uno

• Bluetooth module

• RGB LED

• Buzzer

• Resistors

• Jumper wires

• Breadboard

The RGB LED became the centerpiece of the design, as it could display multiple colors by combining different intensities of Red, Green, and Blue. To make the game more challenging and engaging, I programmed it to display not only the basic colors (Red, Green, and Blue) but also secondary colors formed by mixing them: Cyan, Yellow, and Magenta.

The Bluetooth module served as the bridge between the Arduino and the player’s phone. Using the Arduino Bluetooth Control app, the player would press the letter corresponding to the color displayed. For example:

• R → Red

• G → Green

• B → Blue

• C → Cyan

• Y → Yellow

• M → Magenta

The logic was simple but fun:

• If the player pressed the correct button within 2 seconds, the system registered a win. The buzzer would play a cheerful winning tone, and the score would increase.

• If the player pressed the wrong color or failed to react in time, the buzzer played a losing tone, signaling an incorrect response.

During this stage, Tinkercad was not only useful for testing the wiring connections but also for simulating the timing and logic flow of the game. This allowed me to confirm that the random color generation, input checking, and feedback worked as expected before moving to real hardware. Once everything ran smoothly in simulation, I was ready to proceed to the fabrication and real-world testing phase.

The code can be understood by following it step by step from top to bottom.

First, I included the necessary libraries: Wire.h for I2C communication, LiquidCrystal_I2C.h to handle the LCD display, and Keypad.h to manage input from the 4×4 keypad. The LCD was initialized at the I2C address 0x27, with 16 columns and 2 rows.

Next, the keypad was defined with its 4 rows and 4 columns, mapping all of the characters (numbers 0–9, A–D, *, and #). The Arduino pins connected to the rows and columns were also specified, which allowed me to read keypresses using the keypad library.

After setting up the keypad, I defined the core game variables. These included the pins for the buzzer and LED, the two secret codes (751324 to arm the bomb, and 0000 to defuse it), the countdown timer, and several boolean flags to track whether the bomb was armed or had exploded. Timing variables using millis() were also set up to handle countdowns and blinking without blocking delays.

Inside the setup() function, the LCD was initialized, the backlight was turned on, and the buzzer and LED pins were configured as outputs. The game then displayed the starting message “Enter Code:” on the LCD.

The main logic is handled in the loop() function. Whenever a key is pressed on the keypad, the buzzer makes a short beep for feedback. The program then checks the current state of the game:

• Arming stage: If the bomb is not armed or exploded, the user can enter digits. Pressing # confirms the input. If the input matches the arm code (751324), the bomb becomes armed, the timer is set, and the LCD displays “Bomb Armed!”. Pressing * clears the input if a mistake is made.
  
  

• Countdown stage: Once armed, the timer begins to decrease every 200 ms, shown on the LCD as “Time Left:”. As time decreases, the LED blinks faster and the buzzer beeps with each blink, creating tension. If the timer reaches zero, the bomb “explodes”: the LCD shows “BOOM!”, the buzzer emits a long tone, and the LED stays on.
  
  

• Defuse stage: While the timer is running, the user can attempt to defuse the bomb by entering digits followed by #. If the entered code matches the defuse code (0000), the bomb is disarmed, the LCD shows “Defused!”, the buzzer stops, and the LED turns off.
  
  

• Reset stage: If the bomb explodes, any key press resets the system, clearing the LCD and returning it to the initial “Enter Code:” state.
  
  

In summary, the code follows a clear flow: waiting for input → arming the bomb → countdown with escalating warnings → either explosion or successful defusal → reset. This line-by-line structure allowed me to build a responsive game loop without using blocking delays, making the system both functional and engaging.

After making sure that the circuit was working flawlessly on Tinkercad, it was finally time to move from simulation to the real world. I grabbed my electronics kit and started carefully connecting the circuit on a breadboard, step by step, following the same layout I had tested earlier. Since this week’s assignment didn’t require building an enclosure, I decided to focus on keeping the wiring neat and organized to avoid confusion and ensure stable connections.

Once everything was connected, I powered up the Arduino, uploaded the code, and tested the system. Seeing the game in the correct sequence and the bluetooth works exactly as planned was really satisfying—it felt like the virtual design had come to life successfully in the physical world.

Since this week’s work was a bit straightforward, I didn’t actively ask for much feedback on the design itself, but I did share my idea with a few peers to see what they thought. Some of them suggested that I could extend the project by adding an lcd for score showing, which is something I might build upon later. 

One of the biggest challenges I faced this week was dealing with the Bluetooth module. During the end-of-week session, we worked on building a Bluetooth-controlled robotic arm, and we constantly ran into the problem of the module turning on and off randomly, which meant we couldn’t properly control the arm.

After discussing this with the instructors, we learned that the issue was related to power management. The Arduino was struggling to power both the Bluetooth module and the servo motors at the same time, leading to instability. My first instinct was to give the Bluetooth module its own power source using a separate 5V adapter. However, that solution only made things worse. When I tried to connect to the Arduino, there was no communication at all, and I realized it was because the Arduino and the module were powered by different sources with no common ground.

This was an important “aha moment” for me. I discovered that while separate power supplies can sometimes help, they must always share the same ground in order for the communication to work correctly. Once I connected everything to a single stable power source, the Bluetooth module finally worked smoothly, and I was able to continue with my project.

👉 The main takeaway (and a pitfall others should avoid) is:

• Make sure your power supply is stable and sufficient for all components.

• If you use multiple power sources, always connect their grounds together.

• Don’t rush to separate components without considering the communication path first.

This frustration turned into one of the most valuable lessons I’ve learned so far in electronics.

This week’s experience gave me skills that will definitely carry over to my final project. First, I got to practice integrating Bluetooth communication with Arduino, which will be useful if I decide to add wireless control or monitoring features later. I also learned a lot about power management, especially the importance of using a stable power source and keeping a common ground when multiple components are involved. That knowledge will help me avoid many of the frustrating connection issues I faced this week. 

The coolest thing I learned this week was how to build and program a robotic arm. I was really interested in working on this project because it combined mechanical design, electronics, and coding in a practical way. Seeing the robotic arm respond to our inputs and perform tasks was not only exciting but also showed me how different engineering skills can come together in one system.

Another thing that I will never forget from this week is that our team became the Winner of the Hackathon. This achievement meant a lot to me because it validated the effort and creativity we put into the project. It also boosted my confidence in my ability to work in a team, solve problems under time pressure, and apply my engineering knowledge in a competitive environment