## 3 Testing and Validation
Figure 40: SSH connection to the sensor node via the Terminus application. The next test evaluated a scenario that was prone to classifying two classes simultaneously, which in this case were the person and bicycle classes. Looking at Figure 43, it can be concluded that the person is correctly classified with 98% certainty, while the user who is using the bicycle is incorrectly classified as a person with 73% certainty. This error is caused by the great distance of this user from the sensor node. The last test carried out aimed to evaluate the classification of the person class. The test consisted of two users walking side by side. As we can see in Figure 44, the users were correctly classified with certainties of 97% and 99%, even at a considerable distance. Figure 44: Simultaneous identification of person class. Figure 36:0 Classification and detection of bicycle class. Figure 36:1 Simultaneous identification of person and bicycle classes. It can be concluded that the results obtained in the different detection and classification tests are satisfactory. It should be explained that the difficulty associated with detecting and classifying the motorcycle class is related to the low computing power of Raspberry (sensor node) and the high speed at which this type of user moves. After this last test, a total of 12 detections were carried out, leaving the sensor node database with the records shown in Figure 36:2  
After a few hours, the passage of a new user was simulated, who would play the role of the bridge node. This user, classified as a person, started the trail by selecting the \"Initiate Route\" option in the mobile application. His route started approximately 27 m from the \"PRN-3\" sensor node, as shown in Figure 36:3 As the user moves along the route and enters the Bluetooth range of the sensory node, the nodes negotiate and establish a connection (Figure 46). The sensor node then sends its records to the bridge node. The service used to synchronize the data from the bridge node to the central database, which is hosted on a server on the Internet, is initialized and remains in the background, waiting for an Internet connection, as shown in Figure 36:4  
Figure 36:5 Starting the trail and connection establishment. Figure 36:6 The records in the sensor node database. As illustrated in Figure 48, later in the day, the user went to a location that has access to a Wi-Fi network but could also use a 3G/4G/5G connection. In this case, the Android device's Wi-Fi is activated and it connects to the Internet. Once this connection has been established, the service successfully synchronizes the data with the central database, as seen in Figure 36:7  
Figure 36:8 Data exchange between nodes and initialization of synchronization service. Figure 36:9 Activating Wi-Fi on the Android device. After this iteration, the records with the detections and classifications of the different types of users are already in the central database hosted on a server on the Internet. Figure 50 shows these new 12 detected records. The information collected by the sensor and bridge nodes, now stored in the central database, can now be viewed in the web application. After logging in and accessing the  
Figure 35:0 Data synchronized with central database. Figure 35:1 Records in central database. main page, it is possible to apply filters to the information. The device responsible for these detections and classifications is the \"Proenca-a-Nova-3\" sensor node, with the ID \"PRN-3\", which is why it was selected. It is possible to see the counts of the three classes since this sensor node has been in operation. If filtering is applied with a start and end date, the counts of each class are displayed individually, totaling 12 records, as seen in Figure 35:2  
In Figure 52, it is possible to see the same counts by class in \"PRN-3\" but now on the page showing the map and the sensor nodes distributed on the ground.