(FYP 2) Week 7 - Coding Modification for New Component Replacement, Retest The New Coding on Component that Integrate with The Microcontroller and Reconstruct New Circuit Installation

This week, I resumed my FYP development after purchasing replacement and support components last week. The first task was modifying the code to accommodate the new components. This time, I divided the project's code into two parts since two microcontrollers were being used. The first code, designed for the Arduino Nano, controls the overall project operation, except for the GSM module. The second code, designed for the Arduino Uno R3, focuses on controlling the GSM module exclusively. Additionally, I modified the code for the Wi-Fi module and GSM module in the Arduino IDE.

After making the necessary code modifications, I retested the basic code for each component connected to the microcontroller to ensure their proper functionality before proceeding to the coding testing phase of the project. Finally, all the components worked well, including the previously problematic sections. With that, I proceeded to the next step by reinstalling the entire circuitry of the project using the new components. Each component was carefully connected to avoid any loose or incorrect connections. Once the entire project circuitry was installed, I conducted functional testing by running the modified code on the project.

(FYP 2) Week 6 - Troubleshooting The Problem from The Intregration of Overall Component & Component Changes

This week, I focused on troubleshooting the issues I encountered in my FYP to ensure that it operates and functions as intended. I took several steps to address the problems. Firstly, I checked all the circuit connections in my project and retested the functionality of each sensor. This time, I tested them with all the components assembled together.

I also made some modifications through trial and error, fixing the problematic sections of the code related to the components having a problem. After going through the troubleshooting process and retesting, I found that the readings from the MQ135 sensor remained unstable and were beyond the measurable range of the sensor. However, when I disconnected the DC fan, which works with the MQ135 to activate the air purifier system when the readings exceeded a certain threshold, the MQ135 sensor readings became slightly more stable.

Additionally, I encountered issues with the GSM module, as it still failed to send SMS messages to the specified phone number in the code, even when using basic coding. Overall, most of the components in my project worked well. Still, a few crucial parts didn't function as expected, despite not being faulty. As a result, the functional result of this project is still not successful according to the plan from the proposal through the circuit diagram and flow chart.

Upon observing these problems and seeking input from friends and experts, I decided to make some changes. I replaced some of the main components in my project with new ones and added a few support components. Specifically, I switched from using the ESP32 microcontroller to the Arduino Nano and Arduino Uno R3. These microcontrollers are responsible for controlling the overall operation of the project. Additionally, I included the Arduino Uno R3 as a switching microcontroller specifically for controlling the GSM module when pollution is detected.

The main reason for these changes is that the previous microcontroller, ESP32, had limited power supply capacity, which could be insufficient for powering numerous components simultaneously. Each part draws a certain amount of current. If the combined current exceeds the microcontroller's limits, it can lead to instability, malfunctions, or even damage to the microcontroller. This insufficient power supply can cause voltage fluctuations or drops, resulting in reduced performance, erratic behaviour, incorrect readings, or even complete failure of the components.

By switching to the Arduino Nano and Arduino Uno R3, I aimed to ensure that the connected components receive the required power supply and that the microcontroller can provide sufficient power to all the components. I also added Wi-Fi and GSM modules to support this setup since the microcontroller was changed. Furthermore, I included a DC-to-DC buck converter to ensure that the GSM module and DC fan receive stable and adequate power. So, I went to a local electronic components store in Jalan Pasar to implement these changes and purchased the necessary components.

(FYP 2) Week 5 - Workshop 3 (Presentation and Demonstration/Defense Proposal), Integration All Component Based on Circuit Diagram & Blynk Setup

This week, the development process of my FYP continued by assembling all the input components, microcontroller, and output components into a complete system according to the circuit diagram that was created, despite some changes and additions to the components. The coding for each input and output component was integrated, organized, and managed according to the designed operation flow chart. I also worked on setting up Blynk IoT Cloud for my website and application. This involved creating web and mobile dashboards, configuring data streams, and setting up events for notifications. I changed from Arduino IoT Cloud to Blynk IoT Cloud because the coding is simpler, the setup is easier, and it has a notification feature.

After uploading the code to the microcontroller, several errors occurred frequently. I investigated the error issues to identify their causes, which were resolved by correcting the faulty parts of the code. Eventually, there were no more error problems, and the system could be activated. However, after conducting multiple functional tests of the project, numerous issues arose when the system was powered on. For example, the sensor parameter readings became increasingly unstable, resulting in incorrect functionality or unstable operations. For instance, the readings from either the MQ135 or LM393 sensors would constantly exceed the set threshold with instability, even though the testing for air and sound pollution on the sensors had not been conducted. Returning to normal levels would remain challenging when the reading value sometimes exceeds the set threshold. Additionally, the GSM module still couldn't send SMS messages to the phone number specified in the code. 

The components may not receive the required voltage levels or stable power supply, resulting in reduced performance, unpredictable behaviour, and inaccurate readings. However, the unstable sensor data was still successfully sent to the Blynk IoT Cloud through the built-in Wi-Fi module in the microcontroller. This enabled me to remotely monitor and control my device or system through the web and mobile interfaces. This preparation provided real-time data visualization, allowing me to make informed decisions and receive notifications when specific events occur. On Wednesday of this week, a workshop session was conducted, presented by my supervisor, Madam Azliza. The session aimed to provide information and explanations about the presentation and demonstration/defense proposal.