(FYP 2) Week 14 - Technical Paper & Draft Thesis Submission

This week, I prepared the writing of a technical paper that needed to be completed and submitted to my supervisor, Madam Azliza, by Friday at the latest. A technical paper is a written document that presents technical information or research findings on a specific topic or subject. It often provides detailed descriptions of experiments, methodologies, results, analysis, supporting data, and references. A technical paper aims to disseminate knowledge, share research findings, contribute to the existing body of knowledge, and facilitate further discussion and development in the field. Therefore, I compiled a detailed technical report documenting the project's abstract, introduction, literature review, methodology, results, and conclusion. Finally, I submitted it to my supervisor once the technical report was completed. In addition, I also submitted a draft thesis that I had been working on in the previous weeks to her for a plagiarism check. The thesis showed a plagiarism percentage result of 17%, below the maximum acceptable limit of 30%. Hence, for the next task, I will focus on correcting the format of the draft thesis, resubmitting it to my supervisor for grading, and preparing the hardcover documentation of my FYP at the end of the semester.

(FYP 2) Week 13 - Demonstration Day Presentation

This week, I went through the presentation of my FYP during the demonstration day held at Gemilang Hall from 9 AM to 2:30 PM. All FYP 2 and Diploma FYP students presented and demonstrated their respective projects on this day. My FYP presentation was evaluated by two assessors, Dr Sir Mohd Zaki Ayob and Sir Ahmad Basri. Overall, my presentation went smoothly as I showcased my project through the displayed poster, and the FYP prototype functioned well, allowing me to demonstrate it to both assessors without any issues. During the presentation, I received constructive criticism, suggestions, and improvements from the assessors. I welcomed their feedback as valuable input for further enhancing the project in the future.

(FYP 2) Week 12 - Final Project Testing & Troubleshooting for Demonstration Day Presentation, & Workshop 5 (Claim and Documentation)

This week, I conducted final testing on my FYP to ensure its functionality and readiness for the upcoming presentation and demonstration day. During the testing phase, I encountered an issue where the system would hang or freeze when testing the MQ135 sensor, notably when the air quality readings exceeded the set threshold. This problem didn't occur consistently upon system reset, indicating instability in the sensor's testing operation. Determined to find a solution, I meticulously examined the circuit connections and verified that the MQ135 sensor was correctly wired to the microcontroller. I also ensured the power supply remained stable and within the sensor's operating voltage range. Despite everything being set up correctly, I needed clarification about the underlying cause of the malfunction.

As I delved deeper into the issue, my suspicion turned toward the sensor. To isolate the problem, I conducted a separate test on the MQ135 sensor. Using a multimeter, I measured the voltage outputs from the sensor's pins and discovered inconsistent and erratic fluctuations. This finding strongly suggested that the sensor might be faulty. To confirm my suspicion, I replaced the malfunctioning MQ135 sensor with a spare one I had available. I repeated the test with the new sensor in place, hoping for a different outcome. As a result, the system no longer experienced hang-ups or freezes during the sensor readings. It became evident that the faulty sensor was the issue's root cause.

Feeling more confident, I integrated the newly replaced MQ135 sensor into the central system and conducted comprehensive testing. During subsequent tests, the project performed flawlessly. The MQ135 sensor provided reliable air quality data without disruptions, and the system no longer encountered hang or freeze issues. This breakthrough was significant and brought the project back on track. Finally, the project is ready to be presented, showcased, and demonstrated during the upcoming presentation and demonstration day. Additionally, I attended the final workshop session, Workshop 5, via Microsoft Teams this week. The workshop aimed to provide guidance on student budget claims for project development and the documentation that needs to be submitted at the end of the semester.

(FYP 2) Week 11 - Preparing FYP Poster for Demonstration Day Presentation & Workshop 4 (Technical Paper Preparation)

This week, I created my FYP poster for the upcoming presentation and demonstration day. The required size for the poster was A0. I created the poster using Canva, a web-based graphic design platform. Canva offers a user-friendly interface, pre-designed templates, and customizable elements, making it suitable for individuals with no design experience. The content of the FYP poster followed the guidelines provided by UniKL. It included an introduction, problem statement, objectives, methodology (including block diagrams and flowcharts), results, conclusion, and references. Once the poster was completed, my supervisor, Madam Azliza, reviewed it to ensure it was ready for printing and display during the presentation and demonstration day. After receiving approval from my supervisor, I proceeded to have the poster printed at Ali King Studio in Gombak. The printing process took only a few hours to complete. Additionally, on Wednesday of this week, I attended an online workshop 4 sessions via Microsoft Teams, which was organized explicitly for FYP 2 students. The workshop aimed to guide the writing of technical papers for the FYP. 

(FYP 2) Week 10 - Chapter 1 and 3 Modification, Chapter 4 (Result & Discussion) and 5 (Conclusion & Recommendation) Thesis Writing

This week, I shifted my focus to writing my FYP thesis after completing the project's stability testing and analyzing the results from the previous week. Significant changes and revisions were made to Chapter 1 and Chapter 3 due to modifications and additions made during the project development process. In Chapter 1, the changes included updating the project background, refining the problem statement, and addressing the project's limitations. In Chapter 3, revisions were made to the block diagram, flow chart, circuit diagram, hardware and software details, and the costing budget. Furthermore, I continued writing Chapter 4 and Chapter 5, in which Chapter 4 covers the project construction and development processes, including component procurement, coding development, circuit assembly, and housing construction. The results of the project's functionality testing and stability analysis were also included in Chapter 4. Chapter 5 focuses on the conclusion and recommendations. The current stage of thesis writing also includes the front page, table of contents, abstract, list of figures and tables, references, and appendices. Completing the thesis writing process will require some time and effort. Any necessary changes and formatting adjustments will be made after the plagiarism check conducted by my supervisor, Madam Azliza.

(FYP 2) Week 9 - Project Stability Test

This week, I conducted stability testing for the project in real-life conditions, aiming to assess its continued functionality over an extended period. The testing took place at two different locations: a home kitchen and a school laboratory. The duration of the testing was from 8 a.m. to 12 midnight, with measurements taken every two hours. The objective of the testing was to evaluate the air quality, noise level, temperature, and humidity in the respective environments. By monitoring these parameters, I aimed to determine whether the project could effectively provide accurate readings and detect pollution in real-world scenarios.

Based on the stability testing conducted at both locations, all parameter readings remained within normal ranges throughout the testing period. The sensors detected no sudden increases in readings or pollution. Therefore, I cannot see the effectiveness and functionality of the project output when the readings of both sensors were within the set threshold. However, this outcome suggests that even though the selected locations may have the potential for poor air quality or unfavourable temperature and humidity levels, the project successfully informs individuals about the current conditions, allowing them to determine if the environment is safe and comfortable. There was a slight increase in parameter readings during specific activities such as cooking in the kitchen and a laboratory experiment session. However, these increases were minimal and well within acceptable limits.

In conclusion, this week's stability testing represents an initial step toward implementing the project in an industrial setting. The results demonstrate the project's ability to provide reliable and accurate information regarding air quality, noise level, temperature, and humidity in real-life environments, ensuring the safety and comfort of individuals occupying those spaces.

(FYP 2) Week 8 - Project Functionality Operation Test & Housing Construction for Project Prototype

This week, the project's functionality was tested after modifying and testing the code and completing the overall circuit assembly last week. During the initial testing phase, I encountered an issue where missed calls and SMS messages were consistently delayed or not sent. After conducting a thorough investigation, I identified that the problem originated from the serial communication between the GSM module and the microcontroller.

I double-checked the baud rate settings on the GSM module and the microcontroller to resolve this issue. I discovered a mismatch between the baud rates, leading to communication errors and data loss. By ensuring that the baud rates were matched correctly and configured to the same value, I successfully resolved the communication inconsistency and enhanced the reliability of data transmission. After implementing these adjustments, I conducted extensive testing to validate the improvements. I sent multiple SMS messages and initiated missed calls, carefully monitoring the transmission time and confirming their successful delivery. I was pleased to observe that the missed call and SMS messages were consistently sent without delays and promptly received by the intended recipients, indicating that the issue with serial communication had been successfully resolved. The detected pollution information was also effectively conveyed to the user's phone.

Alongside successfully resolving the GSM module issue, other project components such as the OLED display, LED indicators, buzzer, DC fan, and sensor data transmission to the Blynk IoT Cloud were functioning well. The OLED display accurately displayed parameter readings and provided air quality and sound level statuses. The LED indicators indicated the air quality and sound levels for each sensor. The buzzer was triggered when pollution was detected, and the DC fan could be activated via the relay module when air quality readings exceeded the set threshold. The Blynk IoT Cloud displayed parameter readings and sent warning notifications upon pollution detection. In conclusion, the project operated effectively and performed well as a whole.

The development process continued with the construction of the project's housing. Acrylic perspex boards were used for this purpose, as they are commonly employed in electronic project construction. The housing design consisted of two compartments: one for accommodating the project's circuitry and another for the operational air purifier system. The compartment housing the project's circuitry was covered with black spray to maintain a clean appearance and conceal the circuitry, a common practice in electronic and electrical devices. Components such as sensors, LED indicators, OLED displays, and DC fans with air filters were positioned outside of the project's housing. Space for connecting the power supply to the project circuitry is also provided. Once the housing construction is complete, the testing process for the project's stability will be continued in the following week.

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

(FYP 2) Week 4 - Workshop 2 (Thesis Briefing) & Coding Testing for Components that Interface with Microcontroller

This week, the project development continued with basic coding tests for each component that interfaces with the microcontroller, including input sensors and output components such as the OLED display, LED, buzzer, GSM, and DC fan for the air purifier system. For the sensor components, calibration was necessary to ensure accurate data readings. Reference coding was explored from examples within the Arduino IDE and through web browsing to determine how to obtain the correct values for each sensor used. After conducting several tests, only a few components functioned properly. However, components such as the OLED display, GSM module, MQ135 air quality sensor, and LM393 sound sensor experienced some issues with their outputs.

Regarding the GSM module, the test to send an SMS message to a specified number in the code was unsuccessful, despite the GSM signal integrated with the microcontroller indicating that the SMS was being sent. However, it still needs to be received by the specified number. As for the OLED display problem, initially, I used a 1.3-inch I2C OLED display, but it didn't display as expected. However, I identified that the OLED display version used a different driver than the commonly known and widely used SSD1306-driven OLED displays. The 1.3-inch OLED display used the SH1106 driver, while the opposite version used the SSD1306 driver and had a size of 0.96 inches. Therefore, I searched for the library for that particular OLED display version online since it wasn't available in the Arduino IDE. After obtaining the library and testing the example code for that OLED display version, the output still couldn't be displayed. Consequently, I switched to the slightly smaller 0.96-inch version, and the output from this version was successfully displayed as expected.

For the MQ135 and LM393 tests, output components such as LEDs and the OLED display were used to visualize the readings and status measured by the sensors. The test results showed that the readings from both sensors were unstable, inaccurate, and somewhat sensitive to the surrounding environment, even though the potentiometer on both sensors was set to be less sensitive. The main issue with the LM393 was its inability to indicate specific sound strength values it measured. At the same time, the MQ135 couldn't identify the type of gas being measured since it can detect various hazardous gases. After researching these problems, I found that the MQ135 sensor needs to be preheated for 24 to 48 hours in a clean-air environment before use because it's crucial to stabilize the temperature and establish reliable guidelines, resulting in more accurate and consistent gas detection. As for the LM393, obtaining good strength values can still be achieved even though the sensor cannot. Here, coding plays a role, as the analog output measured by the sensor is read by the microcontroller, and the threshold needs to be manually set according to the project's requirements. The output will display good values as programmed, although the readings may need to be more precise.

Also, this week, a workshop 2 sessions was conducted online via Microsoft Teams on Wednesday at 2:30 PM. The session was held to provide briefing and guidance on thesis writing from Chapter 1 to Chapter 3.

(FYP 2) Week 3 - Meeting with Supervisor and Library Searching

This week, the development process of my FYP continued with the search for libraries in the Arduino IDE for certain project components. Finding libraries may seem easy, as they are usually available in the library manager of the Arduino IDE. However, the Arduino IDE only has some libraries required for some types of components worldwide. Some components only require a little effort to find their libraries in Arduino. In contrast, others can still be used even if no library is available. Some components do not have libraries in the library manager and must be manually downloaded through a web browser. Most of this project's components require libraries to ensure the effectiveness of their coding according to their respective libraries. Some components may not have libraries, but their coding only requires specifying the pin numbers connected to the microcontroller, with a few modifications in the code to ensure the component operates as programmed. Therefore, searching for libraries for certain project components was successfully carried out.

This week, I also met with my supervisor, Madam Azliza. I had a meeting to share the current progress update on my FYP. During the meeting, I provided the latest information on the development process of my FYP, as discussed in the previous meeting. I also shared the plans and suggestions for the upcoming week, and I mentioned that a new feature, an air purifier system, has been added to my FYP. This addition will keep the title of my FYP as it does not disrupt most of the project development process. 

(FYP 2) Week 2 - Workshop 1 (FYP Briefing) & Microcontroller Testing on Arduino IDE

This week, I started developing my FYP after the purchases were made last week. As a starting point, I attempted to connect the chosen microcontroller, the TTGO T-Call ESP32, with the Arduino IDE software to test its compatibility. During several attempts, the microcontroller failed to synchronise with the Arduino IDE. However, after researching, trying different board options in the Arduino IDE, and experimenting with basic coding, I eventually established a connection between the microcontroller and the Arduino IDE. The type of microcontroller also plays a role in determining the compatible version of the Arduino IDE, as some microcontrollers can synchronise with Arduino IDE 2.0 but not with Arduino IDE 1.8. Other than that, there is also a session on Wednesday from 2:30 to 4:30 this week. It was the first-semester workshop, and all students working on final-year projects were given a general briefing. During the workshop, the instructor discussed the procedure and all of the tasks that must be completed throughout this semester.

(FYP 2) Week 1 - Finding and Purchasing FYP Hardware Components

In the first week of this semester, I began the initial steps to develop my FYP (Final Year Project) by searching for components based on the design outlined in the proposal from the previous semester. I chose to make my purchases from an online electronic store. Therefore, I conducted a survey to identify which store had the most available components for my FYP. Based on the survey results, Cytron Technologies emerged as the online store with the most available components I needed, compared to other online electronic component stores. However, the NodeMCU ESP32 microcontroller was out of stock, so I had to choose its alternative, the TTGO T-Call ESP32 microcontroller with a built-in SIM800L GSM module. I purchased all the components, and they took three days to arrive at my home.