Outdoor System

3.1 Test Plan

Our testing strategy for the directional signal localization system encompasses both short-term and long-term objectives. In the short term, our focus is on validating the basic functionality of the Software-Defined Radio (SDR) and exploring the feasibility of the Angle of Arrival (AoA) methodology for signal localization. Short-term goals include successful tuning to lower frequency radio stations, effective demodulation of signals, and accurate AoA measurements. These initial tests serve as foundational steps, paving the way for long-term refinement and expansion of the system's capabilities to address real-world applications.

Basic Functionality of the SDR:

Objective: Evaluate the fundamental functionality of the Software-Defined Radio (SDR).

Test Case:

• Tune the SDR to lower-frequency radio stations.

• Monitor signal reception and assess the SDR's ability to demodulate frequency-modulated signals.

Criteria:

• Successful tuning to lower frequency radio stations.

• Effective demodulation of frequency-modulated signals.

Angle of Arrival Methodology Test:

Objective: Investigate the feasibility of using the Angle of Arrival (AoA) methodology for signal localization.

Test Case:

• Deploy multiple antennas and measure phase differences to determine the angle of arrival for a received signal.

Criteria:

• Accurate and reliable AoA measurements.

• Identification of challenges and potential areas for improvement.

Power Measurement Calibration:

Objective: Assess the Software-Defined Radio's (SDR) capabilities in measuring power in the chosen 1-6 GHz band.

Test Case:

• Utilize a Laboratory Signal Generator (LNO) to generate a range of tones in the 1-6 GHz band.

• Measure and record the power levels using the SDR.

• Compare SDR measurements with known signal generator outputs for calibration.

Criteria:

• Achieve consistent and accurate power measurements within an acceptable margin of error.

3.2 Results and Analysis

Basic Functionality Test:

The basic functionality test successfully showcased the Software-Defined Radio's (SDR) capability to capture, demodulate, and save received signals. As evidenced in the provided content, including a screenshot of the demonstration and sample audio extracted from a received and demodulated radio station signal, the SDR performed effectively in tuning to lower-frequency radio stations and accurately demodulating signals.

Angle of Arrival (AoA) Test:

The AoA test revealed a nuanced challenge in achieving stable measurements of the phase for determining signal direction. Despite effective phase measurements under stable conditions, small displacements in the source's position resulted in drastic phase jumps, rendering it impractical for accurate signal source direction determination. This challenge is a contributing factor to the shift in our direction-finding methodology, as shown in the implementation section earlier. The recommended course of action for follow-up testing involves conducting experiments in a large, open area to better mitigate the effects of multipath interference from signal reflections, ensuring more accurate and reliable AoA measurements.

Indoor System

3.1 Test Plan

Our test plan for the indoor system starts with setting up all of the data gathering, data training, data storage, and data reading. Each of these steps are completed linearly and are originally completed on a Raspberry Pi. 

Fingerprint Gathering

The objective for the fingerprint gathering is to set up server to gather and save Wi-Fi and Bluetooth fingerprints. The two cases to test are to gather and save Wi-Fi and Bluetooth fingerprints from an active scan and from a passive scan. The success criteria for both will be whether or not these scans save legible and accurate output data that matches the intended format.

AI Training

The objective for the AI training portion is to create an accurate and legible AI model that takes the recorded fingerprints as input. The test case will be to build the program and run it on the data from the fingerprint gathering portion. The success criteria is whether or not the model matches the testing files existing in the repository. 

Data Storage

The objective of the data storage portion is to have a server running locally to hold the fingerprint data for future reading. The test case is to set up the software and be able to import data from the initial fingerprint gathering into the correct file structure. The success criteria is whether or not the file structure is set up in totality and matches the structure given in the test materials in the repository. 

Data Reading

The objective for the data reading portion to finally read and generate a text output of Wi-Fi fingerprints in the area. The test case for this is to have a test signal move through the area between the beacons. The success criteria would be to correctly identify the signal, the device if applicable, and the location. 

Dimensional Organization

The objective for the dimensional organization is to stack rooms to create a 3D data field. The test case for this is to place multiple sets of vertical beacons to act as floors and move the test signal across all axes. The success criteria would be to see that the vertical change in signal is correctly reflected in the saved data. 

3.2 Results and Analysis

Fingerprint Gathering

The Fingerprint-Gathering-CLI program has been set up on the Raspberry Pi 3B and has all the dependencies created without Docker. The program can begin and gather some data from both active and passive scans. However, both crash upon recording more than a few data points. This is potentially due to requiring the set up of the storage server. Another reason this may exist is because of older GO dependencies not matching with those currently in use. The next steps are to read on the Golang versions in use and to parse the code for array sizing issues. After that, the data storage set up will be moved to a priority. 

Data Reading

This step was started early in an attempt to view the GUI. The front end has not correctly installed on a Windows or Linux machine, and is next to be started on a Raspberry Pi. This process has moved to installing dependencies directly onto the Raspberry Pi and not Docker, though this may change as other problems arise during the fingerprint gathering section. 

GUI

3.1 Test Plan

Outline the plan for testing the implemented design.

The plan for testing the GUI depends on information provided by the hardware and software portions of the system. Once the hardware collects signal information and the software processes it, the GUI will then visualize those details onto the webpage. This includes the frequency of the detected signal as well as the latitude and longitude that it was located at. Once this information gets uploaded onto the .csv file, the GUI will graphically display all necessary information about the signal that concerns the user. The test plan involves completing this process using sample signal data generated from MATLAB that we know the frequency and exact location of, so when it displays on the GUI, we will be able to determine how accurate a signal is portrayed.

Define specific test cases and criteria.

Checking Accuracy of Signal Representation

Objective: Assess GUI's ability to correctly represent a signal on the webpage

Below is a snapshot of the .csv file with sample data used to test the functionality of the GUI

Test Cases 1-8:

It holds data for longitude, latitude,  and frequency.

Below is what the GUI displays based on this given data:

Below we have Test Case 1 compared with the information displayed by its corresponding signal on the GUI:

3.2 Results and Analysis

Share the results of the testing phase.

After running the GUI and comparing the information displayed to the sample data, we observed that each signal was correctly represented and the details were reflected correctly both textually and visually.

Discuss any unexpected outcomes and their resolutions.

Fortunately, the results were successful and no unexpected outcomes came from testing the GUI.