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

(FYP 1) Week 11: Chapter 3 (Methodology) Progress and Defence Proposal Presentation

This week, I resumed writing to complete chapter 3 after 4 subtopics were completed last week. The rest of the subtopic explains the hardware and software used, a Gantt chart for the entire FYP 1 and FYP 2 planning, the costing budget for the main components, and a chapter summary. All excess subtopics for chapter 3 have been completed this week. 

This week as well, although I am currently completing the writing of chapter 3, I have gone through the online defense proposal presentation on Wednesday, 21 December 2022, from 2.30 to 5.30 pm. This presentation was conducted by 6 presenters, including me, on the Microsoft Teams platform, which was assessed by 2 assessors, namely Sir Ahmad Basri and Sir Aswadi.

(FYP 1) Week 10: Chapter 3 (Methodology) Writing and Defense Proposal Presentation Preparation

This week, I started writing for chapter 3, methodology. This chapter has nine subtopics which I have listed below:-

3.1    Introduction

3.2    Block diagram

3.3    Flow chart

3.4    Circuit diagram

3.5    Hardware

3.6    Software

3.7    Gantt chart

3.8    Costing Budget

3.9    Chapter summary

Throughout my research to find suitable components for my FYP, I have used 3 types of sensors as input: the MQ135 air quality sensor, LM393 sound sensor, and DHT11 temperature and humidity sensor. NodeMCU ESP35 has a built-in Wi-Fi module as a microcontroller. 4 outputs, and 2 of them are based on the warning system, namely the warning light and warning alarm siren. The rest is an OLED display and SIM800L GSM/GPRS module. For the software part, I will use Arduino IoT Cloud as a Cloud server to store data for monitoring and analysis purposes. It also comes with an application on the mobile phone named Arduino IoT Cloud Remote App for users' convenience anywhere. In addition, since NodeMCU ESP32 is compatible with Arduino IDE, this software will also be used to program this project. This week, I only managed to do 4 out of 9 subtopics. The rest will be continued next week.

Also, this week, I have started preparing slides for the defense proposal presentation that will take place next week after attending workshop 4 sessions on the presentation and defense proposal. Based on what has been learned from the session is to prepare presentation slides estimated at 15 to 25 slides, and the presentation duration is at most 15 minutes, including the question and answer session. Completing the writing of chapter 3 and the defense proposal presentation slide will be done simultaneously until next week.

(FYP 1) Week 9: Chapter 2 (Literature Review) Progress

I resumed writing to complete chapter 2 for this week. Last week, two out of four journals or previous projects were summarized. Furthermore, the chapter summary is also made based on input, ideas, differences, and information obtained from the outline of the 4 journals. As a result, the writing of chapter 2 was completed this week. After chapter 2 was finished, I spent this week searching for, identifying, and selecting the input, process, and output components for my FYP that will be employed based on the references from the four journals. In addition, the sort of data storage and collection software required for monitoring and analysis must be identified. This stage marks the beginning of preparation for the methodology chapter 3 writing process.

(FYP 1) Week 8: Workshop 4 (Presentation and Defense Proposal) and Chapter 2 (Literature Review) Writing

This week I attended workshop 4 sessions on Wednesday, 30 November 2022, from 2.30 to 4.30 pm, conducted online on the Microsoft Teams platform by Madam Hajah Azliza Binti Mohamad Arshad who is my supervisor. It was attended by all FYP 1, FYP 2, and Diploma students. This workshop session explains about the preparation slide presentation and documentation, and tips and tricks of presentation using the 4'Ps approach which is planning, preparing, practicing, and presenting. In addition, the session also explained the FYP Handbook 4th edition 2019 regarding some regulations in terms of FYP Grades and plagiarism.

In addition, I have begun writing chapter 2, titled Literature Review, this week. After weeks of looking for journals relating to the title of my FYP, The Development of Industrial Air and Sound Pollution Monitoring and Avoidance System Using IoT, four journals were discovered. They will be used as references for chapter 2 and the subsequent stages. These four journals are previous project studies relevant to my FYP title, and they include:

1. Air and Sound Pollution Monitoring System using IoT
2. IoT Based Noise Monitoring System (NOMOS)
3. Air and Noise Pollution Monitoring in the City of Zagreb by Using Mobile Crowdsensing
4. A Raspberry Pi Controlled Cloud Based Air and Sound Pollution Monitoring System with Temperature and Humidity Sensing

Each of these four previous projects will be summarised, including the theory, concept, methodology, etc. This week, I only had time to summarise the writing of the two previous projects. The remainder will be completed next week.