# Situational Awareness: Mapping Interference Sources in Real-Time Using a Smartphone App
## 3 NGeneApp: An Android-Based Real Time RFI Detector for Smartphones
### NGeneApp High-Level Architecture  
As shown in Figure 1 the high-level architecture of NGeneApp consists of two main blocks: the Graphical User Interface (GUI) and the receiver. The GUI, written in Java, has been designed to allow the user to set the configurable parameters, to interact with the receiver, and to display some basic information such as the receiver status and the tracked satellites. Then, like any other satellite navigation tool, the real-time position computed by receiver can be shown in Google Maps thanks to the Google Map API in Android. In addition to these basic functionalities, the GUI is able to plot the Power-Spectral-Density (PSD) of the raw samples coming from the FE, by using a charting library called Achartegine [47], so that the user can monitor the presence of interference in real-time.  
The NGeneApp's receiver includes four modules, also illustrated in Figure 1:  
* the _graber_, which consists of a function that stores the raw GNSS samples coming from the FE to the internal memory of the smartphone, for post-processing analysis;
* the whole GNSS signal processing chain, from acquisition to PVT computation, for the real-time processing of the raw GNSS samples coming from the FE;
* the interference detection functionality, working in real-time and implemented at two stages, as better detailed in Section 4: \(\bigcirc\)  
Early stage detection, by means of a spectral analysis, called PSD evaluator in Figure 1;Intermediate stage detection, by means of a correlation distortion monitoring technique, as shown in Figure 1;
* real-time server communication and data storage for interference distribution monitoring in a crowdsourcing perspective: NGeneApp sends a data message containing the receiver measurements to the server every second. The data are processed and stored in the database for mapping and investigating the distribution of interference in the area in real-time. In case the communication connection is lost, the data message is kept in the local memory of the device and will be resubmitted to the server right after the network is available again. NGeneApp can be executed in two modes:  
1. Grabbing mode: NGeneApp stores the raw GNSS samples coming from the FE to the internal memory of the smartphone. In this mode, only the _grabber_ module, as depicted in Figure 1, is enabled.
2. Receiver&RFI detector mode: NGeneApp acts as a complete GNSS receiver and enables its capabilities of RFI detection and transmission of data to a remote server. The user can further specify the data source and its associated processing mode: 1. _Real-time_: the raw GNSS samples come at high rate (tens of MHz) from a USB-based FE and are processed on the fly; 2. _Post-processing_: NGeneApp reads the GNSS data from a file. In this case, no real-time requirements have to be satisfied.  
Table 1 reports the main features of the FEs currently supported by NGeneApp, in terms of sampling frequency, intermediate frequency (IF) and FE bandwidth. It is worth noting that, thanks to the Software Defined Radio (SDR) approach, NGeneApp can be used with other FE parameters combinations, allowing the user to specify its own tailored setup, taking into account that the real-time requirements have to be satisfied. The sampling frequency is upper limited by the USB transfer speed and the hardware capabilities. Both the SiGE v3 [48] and the STEREO FE [49] are configurable, thus the configuration reported in the second and third rows of Table 1 represents just one of the many possibilities. Other FEs are currently under evaluation. For the purpose of a portable and easily deployable RFI detector, an additional aspect that cannot be neglected is the power supply mode required by the FEs. Both SiGE v2 and v3 can be powered by the smartphone USB, so both are suitable to be used for on-field tests. The STEREO FE, on the contrary, needs an external power supply, to be provided via an additional portable charger.  
Figure 1: NGeneApp high-level architecture.