## 2 Prototype
### Two-Stage Detection
#### 2.3.3 Bridge Node  
For the bridge node, a mobile application was developed in Java [60], using the Android Studio integrated development environment (IDE) [61]. It is important to note that the application requires a minimum version of the Android software development kit (SDK) (minSdk) of 30, which corresponds to Android version 11, to work correctly on the devices. The version of the Android SDK on which the application was compiled and tested (targetSdk) is 34, i.e., Android 14 (see Table 1, A3). Because the goal is simply to demonstrate the concept, the application is simple and has been divided into three services [62]: location service, Bluetooth service and synchronization service. The application contains just one activity [63] with two buttons, as can be seen in Figure 22. One of the buttons starts the activity on the trail and the other ends it. This activity also contains a map with markers [64] which identify where the sensor nodes are located. In addition, a text area is displayed at the bottom of the graphical user interface (GUI), describing all of the actions carried out in the application, which is useful for functional tests and troubleshooting. Figure 20: Example of block of 10 records in JSON. Figure 21: Communication between nodes when transmitting data. After initializing the application, if Internet access is available, the application makes a GET request to the API to obtain the GPS geographic coordinates of the available sensor nodes. If the request to the API is successful, the data received are stored in the application's local database. Otherwise, an error will be displayed to the user. Once this information has been obtained, the locations of the sensor nodes are loaded onto the available map. When the user presses the \"Initiate Route\" button, the application starts the location service, showing the smartphone's current location (i.e., bridge node). Then, it determines the nearest sensor node, keeping it in memory. This service will be active even if the application is minimized (see Table 1, A4), so that it is possible to check whether the bridge node is at a distance of 30 m or less from a sensor node. Until this condition is verified, the service is \"listening\" until it reaches this distance. At this point, the Bluetooth service is started and tries to establish a connection between the sensor node and the bridge node. If this is unsuccessful, another attempt is made. Figure 23 shows the information that appears in the text area of the prototype mobile application when these iterations take place. If the connection attempt is successful, the location service is terminated. The data are exchanged between the sensor and bridge nodes, as described in Section 2.3.2. Once the data have been received, the records are inserted into the bridge node's local database. These steps can be seen in Figure 24, which shows the text area of the prototype mobile application. Figure 23: The output on the mobile application with information on the route started and the location of the nodes. Figure 22: Mobile application screen. The bridge node's local database, shown in Figure 25, was implemented in SQL. Lite [65] and consists of two tables: _Users_data_ and _Equipment_. The _Users_data_ table stores the records captured and stored by the sensor node and sent to the bridge node. Its attributes are _id_, which identifies the record uniquely, _class_, which identifies the class of the user type, _timestamp_, which indicates the date and time of the record, _devicld_, which identifies the device that captured the record, and _isSyntced_, which controls the synchronization of that record. The _Equipment_ table stores data on the sensor nodes installed on trails that are available for data exchange.