Week 7 - 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. 

As for the materials, the assignment required us to use cardboard as a low-fidelity building material. This kept things simple, inexpensive, and easy to prototype. Because of that, no heavy machinery was needed—just basic tools like a cutter knife and scissors were enough to bring the design to life. ✂️📦

The design and preparation process of my assignment started with exploring the main functions of the bomb in the game that I wanted to mimic. I identified that I would need three main interactions: the ability to enter a code, display it on an LCD, and provide audiovisual effects such as blinking LEDs and buzzer sounds. From this, I concluded that the following components would be required:

• LCD with I2C module

• Buzzer

• LED

• Keypad (numpad)

• Arduino Uno

• 9V adapter

• Jumper wires

• Small breadboard

• Resistors

• Push button

Once the hardware list was finalized, I moved to KiCad, where I created the schematic by adding and connecting the components. This step helped me visualize the wiring before physical implementation. After completing the schematic, I shifted my focus to coding.

I began coding in Arduino IDE by first identifying and testing the simplest outputs: the LED and buzzer. Once I confirmed they worked correctly, I moved on to the LCD. Although it was slightly more complex than the LED and buzzer, it was still straightforward compared to the keypad. The keypad was the most challenging part, since it does not use a standard VCC and GND connection but instead works as a matrix of rows and columns. I had to research and experiment to understand its behavior and implement it properly.

After I had a good grasp of the keypad, I started building the code functions step by step:

1. Library inclusion & initialization

   • I included the necessary libraries: Wire.h, LiquidCrystal_I2C.h, and Keypad.h to handle the LCD and keypad.

   • Then, I initialized the LCD to work with the I2C module and set up the keypad layout by defining rows, columns, and pins.

2. Hardware pin setup

   • Assigned pin numbers for the buzzer and LED and set them as outputs in setup().

   • Initialized the LCD and displayed the first prompt: “Enter Code:”.

3. Code logic for different modes

   • Idle Mode: Waits for the user to input the correct "arm code." Once entered, the bomb arms itself, and a countdown begins.

   • Armed Mode: The countdown timer is displayed on the LCD. The LED blinks and the buzzer beeps with increasing urgency as the timer decreases. If the timer reaches zero, the bomb “explodes.”

   • Defuse Function: While armed, the system listens for the defuse code. If entered correctly, the countdown stops, the bomb is defused, and the display shows “Defused!”

   • Explosion Mode: If the timer reaches zero, the system locks in the “exploded” state, the buzzer sounds continuously, and the LED stays on until a reset key is pressed.

4. Keypad interaction

   • For every key pressed, I added a short beep for feedback.

   • Special keys:

     • # is used to submit the entered code.

     • * is used to clear/reset the input.

5. Countdown management

   • I used millis() instead of delay() for accurate timing and to keep the program responsive while counting down.

   • The countdown interval was adjusted so that each “second” passed faster than real time, creating a more dramatic effect

6. LED blinking and buzzer urgency

   • As time decreases, the blinking interval of the LED and the buzzer frequency change dynamically using the map() function, simulating the tension of a real bomb scenario.

By following these steps, the final code successfully replicated the game-like bomb system with arming, countdown, defuse, and explosion states. Each component worked together through the Arduino IDE, which provided much greater flexibility and faster interaction with the hardware than block-based coding tools.

Fortunately, I already had a pre-assembled cardboard box lying around, and its size and proportions turned out to be a perfect match for the project. I began by arranging the components on top of the box to visualize their placement. Once I compared this layout to reference images of the in-game C4, I finalized the shape and arrangement of each part.

One challenge I faced was with the keypad. Its slim design did not look close to the original in-game model, where the keypad appears as part of a larger circuit board. To solve this, I decided to mimic the look of a PCB by cutting and layering cardboard beneath the keypad to add thickness and give it a more authentic appearance. I also reinforced the back of the keypad with an extra cardboard support, since pressing the keys directly on thin cardboard made the surface bend and lose stability.

After securing all the components, I closed the box and performed another round of testing to make sure the system worked properly inside the enclosure. Once everything functioned as expected, I moved on to the finishing touches. I painted the cardboard and added textures to replicate the rugged look of the original C4 bomb design, giving the project a much more realistic and polished appearance.

For this week, I was unfortunately absent from the offline session, which meant I missed out on a lot of valuable face-to-face learning and direct peer interaction. That was definitely a drawback, as these sessions are usually where we exchange ideas, provide feedback, and learn from each other’s approaches.

However, I made sure to compensate for this gap by turning to online resources. I relied heavily on YouTube tutorials and online articles, which were extremely helpful in guiding me through the parts I found challenging—especially the keypad (numpad). Since this was something completely new to me, I needed to pause and do some extra research to understand how to wire it properly, how it communicates with the Arduino, and how to integrate it into my project. Thankfully, the internet didn’t let me down, and I was able to move forward confidently.

Although I didn’t have direct peer input this week, the process taught me how to be more resourceful and independent. In a way, I built upon the collective knowledge shared by others online—people who had faced similar issues and posted their solutions. That became my form of "peer learning" this week.

One of the main challenges I faced this week—aside from learning how to use the numpad—was the simulation process. The issue came up when I tried to test my code in Tinkercad. Since my program required external libraries, the simulation wouldn’t run properly. This was frustrating because I usually prefer testing things in software first before moving to real-life implementation—it’s faster, safer, and helps avoid unnecessary mistakes with the hardware.

After getting stuck for a while, I paused and researched how libraries are handled. That’s when I realized that while the Arduino IDE allows you to easily install and manage external libraries, Tinkercad doesn’t support them in the same way. Once I understood that limitation, I switched my focus entirely to the IDE, installed the required libraries there, and everything worked much more smoothly.

The takeaway here is that if someone else were doing this assignment, they should not rely solely on Tinkercad for testing if their code involves external libraries. Instead, it’s better to move directly to the Arduino IDE, which offers more flexibility and control. This will save time, reduce confusion, and prevent them from going in circles trying to make something work on Tinkercad when it simply won’t.

The skills and knowledge I acquired this week will be a huge addition to my final project, because this assignment felt almost like a mini-final project on its own. It included working with a microcontroller, handling both input and output devices, and designing an enclosure to house everything. On top of that, I had to think about space management, cable routing, and component mounting inside the box, which are all very practical skills for any real-world fabrication process.

These experiences will directly transfer to my final project, as I’ll need to carefully plan not only the electronic connections but also the physical arrangement of components to make the system reliable and user-friendly. The practice I got this week in combining electronics, coding, and enclosure design will make the development of my final project smoother, more organized, and more professional.

The coolest thing I learned this week was realizing how a microcontroller and coding can bring something from a game into real life. Taking an object that I was used to seeing on a screen and actually building it physically—holding it in my hands, interacting with it, and watching it work—was an unforgettable experience. It showed me how powerful this combination of hardware and software can be in turning imagination into reality. This is definitely something I will never forget from this week.