# Low-Cost COTS GNSS Interference Monitoring, Detection, and Classification System +
## 3 Hardware Design
### Power Consumption and Optimization  
A Joy-IT TC66C USB power meter (Joy-IT, Neukirchen-Vluyn, Germany) measures the power consumed by the interference monitoring system with different configurations. The system is switched on, and a minimum of 5 min is waited before conducting any tests to allow the system to stabilize. Next, the average power and peak power over 60 min is measured for each configuration. This approach is rudimentary and has significant tolerances, but it facilitates a rough idea of the power consumption of the different stages. Table 1 shows the various configurations and the measured power profiles. All hardware is connected in the \"Full\" profiles (Profiles 1 to 4), but different interfacing and late-stage processing are switched on or off. These include switching the web service for easy interfacing off (Profiles 2 to 4), switching communications and networking off (Profiles 3 and 4), or disabling the initial ML detection (Profile 4). In the \"Only GNSS\" configuration (Profile 5), the NeSDR is removed, using less hardware, and in the \"SDR\" configurations (Profiles 6 and 7), the GNSS pHat is removed. In the \"Only SDR\" configuration, the NesDR is connected, data are recorded, and the spectral processing (see the software and algorithmic design sections) is switched on. The spectral processing is switched off in the \"No SDR proc\" configuration. Finally, in the last setup (Profile 8), the GNSS pHat and the NeSDR are removed, and the Raspberry Pi is tested in idle mode. From these measurements, the following deductions are made:  
* (1) minus (2): Power of web server processes (expectation: low power) = 21 mW;
* (2) minus (3): Power of WiFi and networking (expectation: medium power) = 394 mW;
* (3) minus (4): Power of ML inference processing (expectation: low power) = 99 mW;
* (5) minus (8): Power of the GNSS receiver with LNA and logging (expectation: medium power) = 463 mW; \begin{table}
\begin{tabular}{c c c c c c c c c c} \hline \hline \multirow{2}{*}{**No.**} & \multirow{2}{*}{**Description**} & \multirow{2}{*}{**Web**} & \multirow{2}{*}{**WiFi**} & \multirow{2}{*}{**ML**} & **GNSS** & **SDR** & **SDR** & **Mean** & **Peak** \\  & & & & & **Log** & **Proc** & **Only** & **[W]** & **[W]** \\ \hline
1 & Full—debug & x & x & x & x & x & x & 6.107 & 7.510 \\
2 & Full—op. & & x & x & x & x & x & 6.086 & 7.325 \\
3 & Full no link & & & x & x & x & x & 5.692 & 7.145 \\
4 & External ML & & & x & x & x & 5.593 & 6.932 \\ \hline
5 & Only GNSS & & & x & & & 2.682 & 4.059 \\
6 & Only SDR & & & & & x & x & 5.289 & 6.514 \\
7 & No SDR proc & & & & & & 3.692 & 4.137 \\
8 & Only RP & & & & & & 2.219 & 2.526 \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Power consumption test configurations and results. Figure 4: Side view of the system and its antennas in an outdoor setup. * (6) minus (7): Power of SDR FFT features processing (expectation: high power) = 1.597 W;
* (7) minus (8): Power of SDR interface (expectation: medium power) = 1.473 W;
* (8): Raspberry Pi idle and hardware overhead (expectation: high power) = 2.219 W.  
Figure 5 shows the power distribution. The most significant part, roughly one-third of the power, is contributed to the Raspberry Pi hardware in idle mode. It indicates that more energy-efficient solutions than the Raspberry Pi 4B for a monitoring station can be considered as a first optimization step. Nevertheless, a SBC still consumes considerably less power than other monitoring stations based on fully-fledged computers. Choosing a different SBC that is more power efficient may reduce this part of the energy consumption. However, this could limit the rapid prototyping that the Raspberry Pi allows with its large community and associated hardware and software resources and may limit the processing capabilities it supplies for the SDR processing. The second largest part is the power consumption for the SDR processing. The SDR processing mainly consists of FFT and statistics calculation, which are parallelized efficiently.