Development of End-to-End Low-Cost IoT System for Densely Deployed PM Monitoring Network: An Indian Case Study

Particulate matter (PM) is considered the primary contributor to air pollution and has severe implications for general health. PM concentration has high spatial variability and thus needs to be monitored locally. Traditional PM monitoring setups are bulky, expensive and cannot be scaled for dense deployments. This paper argues for a densely deployed network of IoT-enabled PM monitoring devices using low-cost sensors. In this work, 49 devices were deployed in a region of the Indian metropolitan city of Hyderabad out-of this, 43 devices were developed as part of this work and 6 devices were taken off the shelf. The low-cost sensors were calibrated for seasonal variations using a precise reference sensor. A thorough analysis of data collected for seven months has been presented to establish the need for dense deployment of PM monitoring devices. Different analyses such as mean, variance, spatial interpolation and correlation have been employed to generate interesting insights about temporal and seasonal variations of PM. In addition, event-driven spatio-temporal analysis is done for PM values to understand the impact of the bursting of firecrackers on the evening of the Diwali festival. A web-based dashboard is designed for real-time data visualization.


I. INTRODUCTION
Air pollution has been an issue of grave concern across the world for decades [1].Particulate matter (PM) occurring from local activities is a significant contributor to air pollution, which causes serious health implications.In India, the average PM concentration is 55.8 µg/m³, 11 times higher than the WHO guideline [2].According to an estimate, in 2019, around 6.7 million premature deaths globally were associated with air pollution [3].Studying and continuously monitoring the various patterns related to air pollution is essential to address the challenge comprehensively.Many countries have established elaborate structures for air-quality monitoring based on beta attenuation monitor (BAM) and tapered element oscillating microbalance (TEOM) often deployed by pollution This work is partially supported by Dept. of Science & Technology (DST), Govt. of India under grant no.2073 (2020) and Pernod Ricard India Foundation (PRIF) Social Incubator Program 2019, with no conflict of interest.
control boards and other governmental agencies to monitor air quality [4].Although the PM data from these stations is very accurate, this approach has the limitation of scalability.Often the centralized air quality monitoring stations (AQMS) are expensive, bulky and large in size [5].Thus, they cannot be densely deployed.For example, in a big metropolitan city like Hyderabad, with a population of over 6.7 million [6] and area over 650 km 2 , the Central Pollution Control Board (CPCB) and the Telangana State Pollution Control Board (TSPCB) have deployed only 12 AQMS [7].All of this points out not only the issue of the expensive and time-consuming setup of the air quality monitoring apparatus but also a significant mismatch between the requirement of PM data and its availability.Consequently, the resolution of available air quality data is limited as very few stations are typically responsible for an entire city region.Low resolution is not enough for a deeper understanding of PM as the pollutant levels can vary drastically even within smaller blocks in a city [8].
To overcome the limitation of scalability, several studies have been carried out recently focusing on the use of low-cost sensors-based PM monitoring devices [9].Moreover, internetof-things (IoT) and cloud computing have been used for realtime PM monitoring.Citywide deployment of such devices has been studied to increase pollution data's spatial-temporal resolution.For instance, in [10], 169 devices were deployed in 20 km × 20 km area measuring PM2.5 every hour with a focus on identifying the primary source of PM2.5.Similarly, in [11], 100 devices have been deployed, both stationary and mobile, for 5 months in Turin, Italy.In [12], 50 devices have been deployed in a large area of 100 km 2 for 6 months in Utah, United States, discussing the reliability and efficiency of lowcost PM sensors for spatial and temporal dense heterogeneous pollution data.In [13], 30 devices were deployed in an area of 800 m × 800 m discussing the suitability of low-cost sensors for networks of air quality monitors for dense deployment, but the data collection is very less.In [14], authors deployed a network of 45 low-cost electrochemical sensor devices in and around Cambridge, UK, for 2.5 months.The network provided measurements of harmful gases (CO, NO, NO2), temperature and relative humidity (RH).The collected data from these devices was analyzed for source attribution.The authors also determined the regional pollution level by studying variations in the sensor readings deployed in different environments.In [15], authors developed a low-cost device named uSense, which can measure the concentration of harmful gases (NO2, O3, CO) in the ambient environment.It uses Wi-Fi to offload the sensed data on a cloud server.Wi-Fi connectivity enables users to place the device indoors or outdoors in places like balconies or gardens.
For localized monitoring and real-time analysis of outdoor PM, a dense IoT system is needed, which is scalable with low-cost portable ambient sensors.In our preliminary work [16], a smaller network with 10 devices was deployed inside the IIITH campus for PM monitoring.Field experience from this deployment highlighted the need for a denser deployment across different environments and areas with calibrated PM sensor and a more robust device that can cache data to avoid loss due to communication outages.In this paper, an end-toend low-cost IoT system is developed and densely deployed for monitoring PM with fine spatio-temporal resolution.The system includes designing the hardware, calibrating the lowcost sensors, cloud interfacing, and developing a web-based dashboard.
The specific contributions of this paper are: 1) For the high spatial resolution of outdoor PM, 49 IoTbased PM monitoring devices were developed, calibrated and deployed at various outdoor locations.
2) The developed device is designed to be robust against the issue of data loss due to connection and power outages.
The device maintains an offline cache in the event of an outage.The stored data is offloaded in bulk once the power and communication are restored.3) All PM sensors were calibrated for seasonal variations by co-locating with a reference sensor.Also, each device was calibrated individually.4) The devices were deployed at 49 outdoor locations covering a 4 km 2 area in Gachibowli, Hyderabad, India.The field locations were selected to include urban, semiurban, and green regions.Few devices were deployed at busy traffic junctions and roadsides.The data were recorded at a frequency of every 30 seconds (sec) spanning over all the seasons for six months, thus aggregating 20.7 million data points.5) A web-based dashboard was developed and deployed to visualize the data in real-time.6) Different analyses were carried out by observing seasonal mean and variance, spatial interpolation, eventdriven variation and correlation.Results show the optimal deployment across a varied landscape and can be a key factor in identifying the release of high concentration in real-time.
Our work differs significantly from the previous studies discussed earlier [10]- [15].For example, [14], [15] are about gas monitoring, while the main focus of this paper is on PM monitoring.The studies in [10]- [12] have a large number of devices for citywide monitoring of PM but have a sparse deployment (< 0.6 devices per km 2 ) in contrast to our dense deployment (> 12 devices per km 2 ).The work in [13] is on dense deployment, but it is not an IoT network.Data is collected locally on microSD card for a small duration, while our work involves an IoT network deployed since last one year collecting large data sets.The rest of the paper is structured as follows: Section II describes the complete system's hardware architecture and software design.Section III describes the measurement setup and the deployment plan.Section IV describes the process of data collection, preprocessing and calibration.Section V presents the development of the dashboard and its framework.Section VI presents the observations from the measurement campaign.Finally, the conclusions are deduced and articulated in Section VII.

II. HARDWARE ARCHITECTURE: GENERAL OVERVIEW AND SPECIFICATIONS A. Hardware Specification
Fig. 1 shows the hardware architecture and circuit board for the developed PM monitoring device in this work.The basic architecture consists of sensors (PM sensor SDS011 and temperature humidity sensor SHT21), a communication module (SIM800L and eSIM), a real-time clock (RTC), and a lithium polymer (LiPo) battery.All these components are connected to the microcontroller TTGO T-Call ESP32.The controller reads data from all the sensors periodically every 30 sec and offloads it to ThingSpeak, a cloud-based server employing message queuing telemetry transport secured (MQTTS) over a 2G or Wi-Fi network and the data packet size is 28 bytes.The device is powered with an AC-DC power adapter and a 1000 mAh  I.The details of each component are given below.1) Nova SDS011: A Nova-SDS011 PM sensor [17] is used in this study to gauge the presence and concentration of tiny particles with a diameter 10 µm or less (referred to as PM10) and particles with a diameter 2.5 µm or less (referred as PM2.5).The sensor uses light scattering phenomena to sense particle concentration.It is a low-cost sensor with a good correlation with BAM for PM monitoring [21].At the same time, it can achieve low error values after calibrating and using a simple linear regression [22].
2) SHT21: At high temperature and RH levels, light scattering-based PM sensors do not operate reliably [23].Therefore, temperature-humidity sensor SHT21 [18] is installed in the developed device to measure temperature and RH for filtering out any unreliable PM values.
3) Battery/Power Adapter: The developed device is powered using a 3.3 V rechargeable 1000 mAh LiPo battery.A battery management circuit onboard the micro-controller module and a dedicated AC-to-DC power adapter are used to charge the battery.If the AC input is available, the device will work using an AC-to-DC power adapter and charge the battery.It will switch automatically to battery power if no AC input is available.

4) TTGO T-Call ESP32:
In field deployment, a wireless module is needed to send the sensed data to the cloud.This study uses the TTGO T-Call ESP-32 [19], a Wi-Fi and SIM800L GSM/GPRS module with built-in Bluetooth wireless capabilities.Each device is configured to use Wi-Fi or GPRS according to the network availability in the area.
5) Cellular Network: In the previous deployment on the campus, [16], Wi-Fi routers were used to communicate sensed data to the ThingSpeak server.However, Wi-Fi connectivity is unavailable at most locations outside the campus, particularly on the roadsides.In such places, we have used a 2G network, which has very good coverage in the city.Since the sensed data is small in packet size (24 bytes), a 2G network data rate is sufficient.Moreover, the use of removable SIM cards in-field deployment gives rise to the threat of their misuse in case of theft.Hence an embedded SIM (eSIM) customized for IoT applications from the Sensorise service provider is used in the device [20].An eSIM is a small chip embedded in the hardware setup with the help of the SIM 800L module [24], thus restricting the reusability by the general public.IoT devices planned for long-term projects and having a field deployment are protected from the impact of evolving network technologies or service terminations by eliminating technical or carrier lock-ins with a single eSIM.The information on eSIM is rewritable, which makes it easy to change the operator at any time.It allows the user to change the service provider over the air without physically changing the eSIM.The Sensorise eSIM also provides the facility of multi-operator subscriptions.If there is an issue with one network, eSIMs can switch to other operators to connect to the network.
6) ThingSpeak: In the deployed IoT network, the data is aggregated at ThingSpeak, a cloud-based platform for IoT applications.It facilitates data access, logging and retrieval by providing an application programming interface (API) [25].In [26], the authors conducted a security analysis of AirIoT, an air-quality monitoring network and proposed solutions for baseline security of any smart city air monitoring network.The paper recommended using MQTTS instead of MQTT as the latter does not provide data integrity, while attackers can access information such as payload, topic names, and IP addresses.Therefore, the MQTTS protocol is implemented in this work for communication between the device and the ThingSpeak.

B. Working mechanism of the device
Fig. 2 illustrates the flowchart of the sensing algorithm developed to avoid data loss in the event of a connection outage.The microcontroller first reads the sensed data every 30 sec; however, the time to offload the sensed data depends upon the network.Next, the controller checks the network connectivity for pushing the data to the server.If the network is available, the data is transmitted instantaneously.However, if the network is unavailable, the data is stored locally in a part of the microcontroller RAM until the device reconnects to the network.Note that the size of microcontroller RAM is 540 KB and part of it is used for code and header files (created while pushing data), while the part of the remaining memory can be used to store data.We define S = 20000 as the maximum number of data points that can be stored.Once the connection restores, the stored data is uploaded to the cloud server in a bulk transmission and subsequently cleared from the device.In the case device memory is filled with back-logged data in the event of a long connection outage, i.e., if the number of stored data points (s) is equal to the S, the data is cleared in first-in-first-out (FIFO) format to make space for the new incoming data.III.DEPLOYMENT STRATEGY Fig. 3a shows the plan for the field deployment of devices, while Fig. 3b shows an example of the deployed device at one of the locations.The deployment was done in the Gachibowli region of Hyderabad, the capital city of the Telangana state and the fourth largest populated city in India [6].A total of 49 devices were deployed in a region of approximately 4 km 2 to understand the variation of PM across different environments and areas.
Based on the landscape pattern of Gachibowli, the entire region is divided into three categories: urban, semi-urban and green.A few devices have also been deployed at busy traffic junctions and roadsides.Fig. 3a shows the deployment plan of all the devices with exact locations of the following location types: • Location type L1: Urban region  3a represents an area of 400 × 400 m 2 .An attempt has been made to deploy 1 device in each box depending on the availability of power, network and consent availability.However, in some boxes, more than 1 device has been deployed, as shown in 3a.The field deployment of devices was completed in July 2021 and the data collection started in Aug. 2021.As part of experimentation, along with the devices developed at IIITH, a few devices from an Indian manufacturer, Airveda, were also deployed [27].Table II summarizes all the deployed devices with their network configuration.
IV. DATA COLLECTION, PREPROCESSING AND CALIBRATION Fig. 4 shows a flow diagram depicting different steps in collecting usable data analysis data.This involves data collection, creating the dataset, removing outliers and interpolating missing data, followed by calibration.Each of the steps involved is explained in detail.

A. Data collection
To create the data set, the air quality was sensed at a frequency of t = 30 sec for 43 IIITH devices.For 6 Airveda devices, t = 1 sec, averaged over 30 sec.All the devices were deployed for almost one year and are still deployed.However, usable data were collected for seven months (Aug.2021, Nov. 2021, Dec. 2021, Jan. 2022, Apr.2022, May 2022, and June 2022).The loss in the data is because the devices had to be brought back to the lab due to the frequent failure of low-cost sensors requiring regular repair and maintenance.
Additionally, the devices were brought for seasonal calibration at regular intervals and to make a major upgrade in the use of ThingSpeak from MQTT to MQTTS (in Mar.2022).A total of 20.70 million usable data points have been collected.As shown in Fig. 4a, the collected dataset has PM2.5, PM10, temperature and RH parameters.All the concentration values of PM10 and PM2.5 are mentioned in µg m −3 hereafter.The temperature and RH values are mentioned in • C and %, respectively.Corresponding to every device, a vector of data points sent from the device is stored on the cloud server for each sensing instance having the following elements: • created at: Timestamp at which the sensor value is read.This timestamp is recorded utilizing the RTC module of the device.• PM10: Raw concentration of PM10 read by SDS011.
• RH: Raw RH value read by SHT21 • Temp: Raw temperature value read by SHT21 sensor.The size of this payload (or sensor data sent from the device) for each sensing instance is 24 bytes.In addition to this, the following static information is stored in the cloud server • Device id: ID for device identification like IIITH device as AQ-XX and Airveda device as AV-XX, where XX denotes the device sequence number.• Location: Latitude and longitude according to the deployment location.

B. Data preprocessing
The following methods have been employed for preprocessing the raw data received from the PM monitoring device: 1) Outlier removal: Environmental conditions like RH and temperature, sensor behavior and anthropogenic activities occasionally result in outliers in the sensed data.Hence the raw data received from the devices need to be preprocessed to make it statistically significant, as shown in Fig. 4b.PM values are unreliable at higher RH levels (RH>80%).Apart from this, errors may cause raw values to be out of the PM sensor range (0-999).These unreliable points are thus removed.In the dataset, nearly 0.5% values have been found unreliable.
Further, to identify and remove outliers, the interquartile range (IQR) method [28] is used.In this method, the data is separated into four equal parts and sorted in ascending order using three quartiles (Q 1 , Q 2 (median), Q 3 ).Let the difference between the first (Q 1 ) and the third quartile (Q 3 ) be represented by the I QR , which is a measure of dispersion.A decision range is set to detect outliers with this approach, and every data point that falls outside this range is deemed an outlier.The lower and upper values in the range are given by ( Any data point less than the L r or more than the U r is called an outlier.In the collected dataset, nearly 1.4% values have been found as an outlier. 2) Interpolation: Interpolation is a technique to estimate the missing (or removed) data point between two existing data points.In the data set, only 1.9% data is an outlier which is very less and easy to interpolate.In this work, simple linear interpolation was used for this purpose.

C. Calibration
For calibration, the low-cost PM sensors were co-located with a reference sensor (Aeroqual S500 [29], [30]) in a ventilated room for a week.Data points were collected at a frequency of 30 sec.A raw dataset of approximately 20,160 data points for each sensor was collected to perform the calibration.Fig. 5a shows the time series plot of PM10 averaged hourly for a few devices before deployment in the field.It can be observed that all the sensors follow the reference sensor in trend but differ with an offset in absolute value.Therefore, there is a need for calibration.It can also be observed that the offsets for each sensor are different.Although not shown to maintain brevity, the same is also valid for raw PM2.5 values.
This paper uses simple linear regression to compensate for the difference between the values of the low-cost sensor and the reference sensor.Linear regression has been chosen since it can compensate for the offset well while preserving the trend in the data, as shown for SDS011 in [22].The calibrated data y(i) corresponding to the i th data point can be written as where x(i) is the i th raw data point and m, c are the learned parameters.Each sensor will have a different value of m and c.Fig. 6a shows the calibrated data of PM10 for a few devices.It can be observed that the low-cost sensors match well with the reference sensor after calibration.Similar results are obtained by training separate functions for PM2.5 as well.It can also be observed from Fig. 5b and Fig. 6b that every low-cost sensor differs uniquely from the reference sensor.The same is also concluded in [22] for 3 sensors.Therefore, PM10 and PM2.5 of each low-cost sensor have to be calibrated using unique functions for each sensor.Moreover, it is observed that V. DEVELOPMENT OF WEB-BASED DASHBOARD Fig. 7 shows the overview of a web-based dashboard named AirIoT, developed to easily access the real-time data sensed by the deployed sensor devices.AirIoT is a responsive website (https://spcrc.iiit.ac.in/air) that aims to visualize the air pollution levels of the areas where the devices have been deployed.Fig. 7a shows the dashboard that provides a view of all the deployed devices and their locations on an interactive map.Fig. 7b shows that for all locations, the users can get 10 minutes average of real-time data and also visualize the trend of the past 48 hours.The user can select and deselect the parameters to visualize the trend individually.The dashboard also provides the features of implementing calibration algorithms, authorizing and maintaining user profiles and logging network activities.Fig. 7c shows the basic architecture of the dashboard connecting all the building blocks.The data flow pipe and the sequence of communication steps between the users and the server are presented in Fig. 7d and Fig. 7e, respectively.Fig. 7c shows the backend of the dashboard, which is built using Django.It is an open-source python-based framework created using model-template-views architecture.It provides a host of features that efficiently help the data manipulation using GUI.PostgreSQL, an open-source and SQL-compliant relational database management system, is used to store the device's data on the server [31].The periodic task of fetching data from the ThingSpeak cloud server to the dashboard is implemented using Huey, a python queue.Web technologies like CSS, Bootstrap and Javascript are used to build the dashboard's frontend.
The 43 IIIT devices upload the sensed data on the ThingSpeak server every 30 sec, and the 6 Airveda devices upload sensed data on the Airveda server every 1 sec.As shown in Fig. 7d, for data management on a single platform, all the data from the Airveda server is aggregated at ThingSpeak using a separate REST-API with periodic calls.The dashboard fetches data from ThingSpeak for all the locations every 10 minutes and updates the AQI in real-time.
The Django frameworks also help maintain users and their access rights.Fig. 7e shows that there are mainly two types of supported users, the website users and the API users.The website users are the system administrators who log in on the admin console to maintain or update network details like adding new devices or updating information like location, sensing parameters, calibration coefficients, etc.On the other hand, the API users are other platforms like mobile applications which can take air quality data from the dashboard to integrate with their services.Every API user must use OAuth authentication to fetch the data from the server.Initially, the API users send their credentials to the server.The server verifies them and responds with a token.This token is used in every request to the API to fetch the server's data after that.

VI. RESULTS AND ANALYSIS
This section presents mean and variance analysis results and the spatial interpolation for PM values in different seasons.Further, the event-driven variation analysis is done for the data collected during the festival of Diwali.This is followed by correlation analysis to understand the range, after which the correlation between the two points is insignificant.Note that the results are shown only in terms of PM10 for brevity and similar observations have been made for PM2.5 as well.

A. Mean and Variance
Fig. 8 shows the mean and variance of PM10 in monsoon (Aug.2021), winter (Dec.2021) and summer (May 2022).It can be observed that the mean and variance values are highest in winter and lowest in monsoon.This is expected as the surface temperature inversion (cold air near the ground and warm air on top) in winter trap PM near the ground.On the other hand, frequent rains during monsoons settle the PM, reducing their concentration in the air.It can also be observed that there is a lot of variation in the mean and the variance of the PM values among the various devices in the same geographical region, demonstrating the need for dense deployment to understand street-level pollution.
In Fig. 8, the three devices with the highest mean PM10 values among the 49 devices are AQ23 (Traffic junction), AQ20 (Green region), and AQ16 (Roadside), while the three devices with the lowest mean PM10 values are AQ11 (Residential area), AQ43 (Roadside), and AQ22 (Roadside).Devices like AQ23 near the traffic junctions have high PM10 exposure due to heavy traffic.Similarly, devices like AQ16 near traffic

B. Spatial Interpolation
Inverse distance weighting (IDW) is used for spatial interpolation, one of the most popular spatial interpolation techniques.IDW follows the principle that closer devices will have more impact than farther devices [32].A linearly weighted combination of the measured values at the devices is used to estimate the parameters at the nearest location.The weights are a function of the inverse distance between the device's location and the estimate's location.It can be observed from Figs. 9, 10 and 11 that PM concentration was high at 1100 hrs and 2100 hrs and low at 1400 hrs.At 1100 hrs, PM concentration was high, primarily due to heavy traffic.As the day progresses, the density of traffic decreases and the PM concentration decrease at 1400 hrs.However, with the onset of night, PM concentrations can be seen as increased at 2100 hrs, falling in peak traffic hours.

C. Event Driven Variation Analysis
Diwali, also known as the festival of lights, is celebrated during the start of the winter.As part of this five-day festival, people burst large numbers of firecrackers in the late evening of the third day of Diwali (4 Nov. 2021).The bursting of firecrackers leads to a significant increase in PM values during those times.Fig. 12 shows a time series plot of hourly averaged PM10 values for a few devices over a few days around Diwali.A few critical observations can be made from this figure.First, there was a sudden drop in the PM10 values on the afternoon of 4 th Nov. because of rain.The same has been observed on 5 th and 6 th Nov. afternoons.Second, a clear peak is observed for all the devices during the late evening on 4 Nov. 2021, roughly after 2000 hrs.For example, the PM10 values in AV64 increased from 40 to 307 before and after bursting crackers.This peak can be attributed to the widespread bursting of firecrackers during the festive celebrations.Third, it can be observed that the PM10 concentrations decrease sharply after a few hours, indicating that the rise was temporary and activity driven.
Further, we see the effect of sparse deployment on the event-driven analysis.Figs.14, 15 and 16 show the IDW-based interpolation maps for PM10 using all 49 devices and sparse deployment of 12 and 4 devices, respectively, at different time instances on 4 Nov. 2021.For sparse deployment, 4 and 12 devices were chosen randomly with the constraint that they should not form a cluster and should also cover different types of regions.It can be seen from Fig. 14 that the interpolation plot with all 49 devices can identify the event as well as the local hotspots of pollution.Although the interpolation in Fig. 15 (with 12 devices within 4 km 2 ) can identify the event but is not able to identify the hotspots.On the other hand, the interpolation (with 4 devices within 4 km 2 ) misses the event entirely and can be misleading.The root mean square error (RMSE) for different number of deployed devices (12 and 4 devices) is calculated.The RMSE for sparse deployments like 4 devices (59.29) is significantly more compared to 12 devices (32.47).

D. Correlation Analysis
Correlation is a type of bivariate analysis that evaluates the direction and strength of an association between two variables [33].Kendall's tau method is used as it does not require any presumptions on the data and suits the work in this study.The correlation coefficient's value ranges from -1 to +1 depending on the strength of the association.Kendall's correlation coefficients τ between the 49 sensor devices have been calculated using hourly averaged PM10 samples.
A two-term exponential fit is obtained on the correlation values when plotted against the distance between the devices.The fitted model can be written as where a = 0.4801, b = −0.0124,c = 0.7380 and d = −0.0001are the coefficients of the best fit for PM10.Fig. 13 shows the correlation of PM10 plotted against distance.It can be observed that the change in the correlation coefficient under 350 meters is significantly large, after which the decline is gradual.The τ change rate between 0 to 350 meters is very fast compared to distances above 350 meters.Similar results were obtained for PM2.5 as well.It indicates that the PM monitoring devices shall be deployed at most 350 meters apart to capture the spatial variability of PM accurately.
VII. CONCLUSION In this paper, an end-to-end low-cost IoT system is developed and densely deployed in Indian urban settings for monitoring PM with fine spatial and temporal resolution.For evaluating the dense deployment, 49 calibrated devices were deployed covering a 4 km 2 area in Hyderabad, the capital city of Telangana state and the fourth most populated city in India.For data visualization, a web-based dashboard was developed for the real-time interface of PM data.The measurements over the year clearly show a significant difference between the mean and variance of PM values across different locations and seasons.The mean values and the variance were significantly higher in winter than in the summer and the monsoon.The IDW-based spatial interpolation results in monsoon, winter and summer at three different times show significant spatial variations in PM10 values.Furthermore, variation in PM values before and after the bursting of firecrackers on the day of Diwali is clearly visible in the results.The results also show noticeable temporal variations, with PM10 values rising by 4-5 (AV64) times at the same spot in a few hours, coinciding with Diwali celebrations and identifying the hotspots in dense deployment, which is not noticeable in sparse deployment.It has been shown that the correlation coefficient among a set of devices in the area has low values demonstrating that the PM values across a small region may be significantly different.A 350 m distance has been estimated for optimal device deployment for this data set based on insights deduced from the correlation versus distance plot.Thus, there is a need for dense deployment to understand the effect of local pollutants in the air and for improved spatial and temporal resolution of the pollutant data.

Fig. 1 :
Fig. 1: Block Architecture and the circuit board of the deployed PM monitoring device.

Fig. 8 :
Fig. 8: Mean and variance of PM10 concentration at the different locations in different seasons.

Figs. 9 ,
10 and 11 are the IDW-based interpolation maps for PM10 in monsoon (Aug 21), winter (Dec 21) and summer (May 22), respectively.For all three seasons, the interpolation results are shown at three different times of the day, 1100 hrs, 1400 hrs and 2100 hrs, based on hourly averaged PM values.Similar to the observations from Fig. 8, it can also be observed in these figures that the PM concentrations are lowest in monsoon and highest in winter.

TABLE I :
Specifications of the components used in the developed PM monitoring device.

TABLE II :
Deployment Setup