IoT-Based Parking Monitoring System using Magnetometer as the Sensor

The IoT-Based Parking Monitoring System using Magnetometer as the Sensor is developed to detect the presence of cars in parking slots and to collect all the data from the sensor to be displayed in a mobile application so that user can easily find the empty parking slot. The system consists of four types of hardware and two types of software. This four hardware are magnetometer sensors, repeaters, gateways, and LED displays. Whereas the software are the hardware programming and a mobile application. The system developed has been successful in detecting all the present and absence of the car with 100% accuracy and displaying all the information needed into LED displays and mobile application for the service purposes.


Introduction
Parking facilities are created in many places as the needs of finding a parking spot has become a crucial factor in accessing places or facilities [1]. Yet, frankly, finding a parking spot has become a problem. According to INRIXa company that has analysed 35 million parking spaces across 100 countries, this parking problem costs drivers huge amount of time and money. After a large-scale survey of 18 thousand drivers in 30 cities across the US, UK, and Germany were carried out, it is concluded that parking is the second biggest problem the respondents experience after traffic congestions. 90% of the respondents also want a technology that helps to know the availability of parking spots in real time [2]. In addition to wasting a lot of time, circling around to find a parking spot is also causing several other problems, such as traffic congestion, driver stress, and waste of fuel which produces excessive greenhouse gas pollution [3].
The number of IoT (Internet of Things) devices is expected to increase in the coming years and currently, there are many applications based on IoT have been developed such as IoT for emergency response systems [4], home security systems [5], smart equipment [6], etc. The system that was developed in this paper is an IoT based application that consists of four types of hardware, a software application, and a cloud server infrastructure containing the support software and the database system. HMC5883L magnetometers will be used to detect presence of cars [7]. The data generated from the detection will be sent to the cloud server via Wi-Fi and stored in a MySQL . A software application intended for drivers wishing to find a parking spot in the form of a mobile application will be made using Fluttera cross-platform mobile development framework [9].

Research Method
As shown in Fig. 1, the system consists of four types of hardware: sensor node, repeater node, gateway node, and LED display node. The sensor node sends parking information to the gateway node via the repeater node. The gateway node will be connected to the cloud server through the internet via Wi-Fi. The data sent by the gateway node will be handled and processed by the REST API before being stored in the database. The dashboard app and the mobile app will be the two applications that are used to view the parking data. The number of hardware devices in a location are customized to accommodate the parking slots. This paper assumes that the system is deployed in the parking area of Syahdan Campus of BINUS University in Jakarta which consists of roughly 60 parking slots.

Figure 1. System block diagram
The Sensor node is the device that responsible in deciding the availability of its parking spot and it is placed on the groundbelow the carin the middle of the parking spot. Fig. 2 show the developed magnetometer sensor while figure 3 is the block diagram of the sensor node. The Repeater node is the device responsible in delivering messages throughout the whole parking space via the mesh networking protocol used in the system. The mesh networking protocol is also used to overcome the distance limitation of the wireless communication. HC-12, a 433 MHz wireless transceiver module, is used by all the hardware devices to communicate. The block diagram of repeater node can be seen in Fig. 4.

Figure 4. Block diagram of Repeater Node
Gateway node is the brain of the whole system on-site. It receives information regarding the changes in all slots and take necessary actions by updating the cloud server and the number displayed on the corresponding LED display node. The LED display node will help approaching drivers to see the number of currently available parking slots on-site. Fig. 5 and 6 shows the block diagram of the Gateway node and the LED display node. The connection between all devices in the system can be seen through the flow diagram in Figure 7, while the display from the mobile application can be seen in Figures 8.

Result and Analysis
Several tests have been conducted to measure the reliability of the system. The sensor node uses a magnetometer sensor to quantify its surrounding magnetic field. The presence of a car above the sensor node changes the surrounding magnetic field, thus changes the value read from the sensor. Fig.  7 shows how the quantified magnetic field reading change due to the absence and presence of a car.

Figure 9. Magnetic Field Detection Graph
The first test conducted was to see whether the sensor node can accurately detect the absence and presence of a car. The test was conducted across two different locations in a different cityeach with two different cars with 20 samples taken from each car. The test concluded that the sensor node can detect the absence and presence of a car with 100% accuracy (shown in Table 1). The second test taken was to measure the maximum distance the HC-12 wireless transceiver can correctly transmit/receive. The result of the test can be used to determine how far each repeater can be placed. The test was conducted by having two devicesone transmitting, one receiving (listening). The transmitting device transmits a 20-character long message while the other one listens. The listening device is carried apart by walking in a straight line until it fails to receive a complete message. The distance between the two devices are then measured with Google Maps.
There were three environment conditions for the testopen space, below car when off, and below car when on. Open space means the test was conducted in an open space and nothing was in the way blocking the transmission path. Below car when off means the transmitting device was placed below a car with its engine turned off. Below car when on means the transmitting device was placed below a car with its engine turned on. The result of the test can be seen on Table 2 which concludes that a blocking car can reduce the transmission distance particularly when the engine is on. The last test conducted was actually a series of tests to determine the time needed for a change in the parking lot to also apply in the next devices of the data flow direction, such as the mobile app, and, the LED display nodethe last device of the data flow. Each and every significant process within each of these hardware devices, software applications, and supporting software are measured. These durations can be summed up together to find the time needed within the system. Arduino millis function was used to measure the duration of process in all hardware devices. A stopwatch was used to measure the time needed for a repeater node to receive transmissions from the rest of devices.
Late in the design process, a limitation was found in the repeater node. The repeater node was supposed to listen to two different wireless transceivers at the same time but was prevented by its use of the SoftwareSerial library. The implementation of the SoftwareSerial library currently only allows one instance of the SoftwareSerial class to listen to its connected UART device. A workaround to overcome this problem has been implemented by listening to only one instance at a time. However, because of how the workaround was implemented, only 50% chance of the messages were able to be received as the microcontroller might be listening to the other instance of SoftwareSerial at the time. Fortunately, due to the messaging protocol design, the sender will keep on sending its message until it received a reply from the repeater node acknowledging that the repeater has received the message. Hence, the message will eventually be received at a longer time. Table 3 shows the effect of the limitation on the unpredictable durations. The test was conducted on two conditions. The first condition was the ideal condition where the repeater node was assumed capable of listening to two wireless transceivers at the same time. In reality, the test was taken using only one of the wireless transceivers to simulate the ideal condition. As a reminder, the repeater node is not capable of listening to two wireless transceivers at the same time and cannot operate in the ideal condition portrayed by the test. The other condition was when the workaround was applied in the repeater node source code. This test involves one device transmitting to the repeater node. Fig. 9 illustrates the complete duration in the system. The total time is the result of summing up the durations in the system appropriate to the data flow illustrated by the curved arrows. As seen in the figure, the sensor node detection is one of the lengthiest process. This is because the sensor node awaits 8 seconds before redoing the magnetic field reading in a more accurate manner to reduce the chance of a false detection.   In this series of duration tests, a message collision test was also conducted. The purpose of this test was to find out what happens when there are multiple devices transmitting messages to the repeater node simultaneously. As mentioned previously, a message will eventually be received by the repeater. This should also apply when multiple devices are transmitting messageswhich collide to one anotherto the repeater at the same time, however, with an even longer time. The duration of the colliding messages that the repeater successfully receivedfrom two, three, and four transmissions simultaneouslywas recorded by a stopwatch and plotted into Fig. 9. A polynomial equation was created from the data to predict durations from an x number of simultaneous transmissions.  Figure 11. Duration of simultaneous transmissions As an example, the duration from fifteen simultaneous transmissions can be calculated using the polynomial equation. The result is 317.5 seconds.

Conclusions
The developed system works very well which is indicated by the 100% accuracy of the magnetometer sensor to detect the presence and absence of the car. The system also has a reasonable time to update the information to the LED display node and mobile application in 41 and 25 second respectively.