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

(FYP 1) Week 14: Blog Submission and FYP 1 Proposal Report Formatting

After getting positive results from my supervisor's plagiarism check last week, I moved on to the proposal report, formatting it according to the template this final week of the semester. The structure of this proposal report only needs to follow the formal report format or the basic structure for making a report. This format includes the front page, the content, the references, the abstract, the choice and setting of font size, line spacing, page margin, and so on. So, once the format is done, the proposal report must be converted into a PDF file and sent to my supervisor by 5 p.m. on Tuesday, January 17, 2023. After this week, my supervisor will also get this blog to grade after the FYP 1 progress proposal report for 14 weeks is done.

As this FYP 1 blog comes to a close, I'd like to say a million thanks to my supervisor, Madam Azliza, for letting me work under her supervision. Other than that, give me knowledge, suggestions for improvement, comments, and advice so that my FYP can be done well and satisfy everyone. I remember my family and comrades-in-arms for giving me moral support from behind, giving suggestions, opinions, warnings, advice, and reminders as motivation to always be confident and keep trying to do this FYP. The next semester is when the development and production of this FYP will continue. This includes the search for main components, constructing project circuits, project coding, testing, fixing problems, and making the project housing.

(FYP 1) Week 13: FYP 1 Proposal Report Final Checking

This week I prepared and gathered all the completed proposal report writing from chapter 1 to chapter 3. This report needs to be sent to my supervisor, Madam Azliza, to check the plagiarism percentage. If the percentage is low, there is no problem, but if it's high, then correction should be made. For now, only the plagiarism check is made. The proposal report format will be made as soon as the result of the review is positive and satisfactory. Before sending the report, I went through each chapter to ensure all information was noticed. 

Therefore, after I sent the proposal report to the supervisor and the inspection had been done, only the writing of chapter 2 has a relatively high percentage of plagiarism compared to the other chapters. So, I made corrections in chapter 2 regarding sentence structure and sent it again to the supervisor for a second check. This time, the percentage result is lower than before, and the supervisor is also satisfied with writing my proposal report. After this, the proposal report format process will be done next week, and the delivery of the full report will be on the due date that has been set.

(FYP 1) Week 12: Workshop 6 (Claim and Documentation) and Meeting with Supervisor

This week I attended workshop 6 sessions on Wednesday, 28 December 2022, from 2.30 to 4.30 pm, conducted online on the Microsoft Teams platform by Sir Mohamad Shaiful Bin Osman the Coordinator for the Final Year Project. It was attended by all FYP 1, FYP 2, and Diploma students. This workshop session explains important dates for submitting proposal and thesis reports, report submission procedures, and the FYP claims process. 

This week I also had a meeting and discussion with my supervisor, Madam Azliza, to share the outcomes of the input obtained from the presentation of the defence proposal last week. Also, sharing progress reports, discussion of things that need improvement, and questions and answers. At the end of this meeting, my supervisor set a deadline for submitting the proposal report for plagiarism checking, the deadline for submitting the full proposal report, and the blog for grading.