## 4 Implementation
### Embedded Software  
The applications of the \"FloatingBlue\" manager on the DM are background software services. The implementation of Bundle Protocol 7 adopted is based on the dtn7 library in the Go language (dtn7-go). In the embedded software, a library initialization service is responsible for implementing a bundle node in addition to the _BLE Handler_ and _DTN Handler_ services. The _BLE Handler_ software service collects parameters the SNs measure. Figure 5 illustrates the flowchart of the algorithm. The application maintains a Public Device Addresses (PDA) list of pre-registered BLE-enabled devices. The service periodically performs scanning routines to identify BLE devices within the DMs range. This scanning occurs in loops with defined intervals to maximize detection chances. When a device is detected, the data it collects is compared with the PDAs registered in the DM. If the service finds the address of a registered node, it extracts the Broadcast Code (0x2D 2D) from the advertising, along with the corresponding PDA and the timestamp of the collection. This process allows for the distinction between SNs and enables recording the exact instant of data collection. The collected data are then stored in a file, typically a text file by default. The flowchart in Figure 5 is designed to reflect the logical sequence of operations performed by the _BLE Handler_ algorithm. The process begins with a scanning routine aimed at discovering nearby BLE-enabled devices. Upon finding a device, the algorithm verifies if it is among the pre-registered devices by comparing the detected Public Device Address (PDA) with those stored in the dictionary. This step is important for filtering out irrelevant devices and focusing only on those of interest. Once a registered device is identified, the flowchart outlines the extraction of the Broadcast Code and the corresponding PDA, then stores these data, including the timestamp, into a text file. This design ensures the data collection is systematic and traceable, which is essential for subsequent analysis. The decision block at the end of the flowchart determines whether the scanning process should continue or terminate, depending on whether all devices have been scanned. This loop  
Figure 4: Implementation of DM hardware using UAV (**a**) and SN with NRF52840 beacon (**b**). Figure 5: Flowchart of the _BLE Handler_ algorithm. maximizes detection accuracy and ensures comprehensive data collection within the _BLE Handler_'s operational range. The _DTN Handler_ software service, as illustrated in Figure 6, is responsible for transforming the output file from the _BLE Handler_ service into a bundle. The service consists of a watcher application that monitors the directory where the output files from the _BLE Handler_ are saved. Upon the creation event of a new file, the watcher calls the create tool from dttn7. This tool receives the path of the new file and implements an Application Agent (AA) that transforms the file's payload into a bundle using the Bundle Protocol Agent. In parallel to the services, a bundle exchange tool is activated. The tool monitors the bundle directory using a watcher module in the Go language. Upon detecting the presence of a new bundle file, the tool sends the bundle to the AA via a WebSocket API. The AA forwards the bundle to the CLA, which transmits it to the destination node using the TCPCL transport layer. The flowchart in Figure 6 is designed to represent the steps involved in converting the output files from the _BLE Handler_ into DTN bundles. The process starts with a continuous scan of the directory where the _BLE Handler_ saves files. When a new file is detected, the system creates an event to trigger the bundle creation process. The flowchart then outlines how the file path is extracted and passed to the \"dttn-tool create\" command, which generates a new bundle with the same file payload. This design ensures that every new file is promptly and systematically converted into a DTN bundle, ready for transmission.