## 3 Prototype Design
### Software Components  
As said in Section 3.1, the ODROID-X2 has PC-like performance: it features several peripherals and hosts an Ubuntu Linaro Operative System (OS). Consequently, the entire development work was done directly on the target platform, with no need for another machine for cross-compiling. Nevertheless, the implementation of the master-slave configuration required not only the integration of the logic level translator, described in Section 3.1, at the hardware level, but also some additional work at the software  
Figure 4: Photos of the sensor prototype, closed in its carbon fiber case (**A**), opened (**C**,**D**) showing internal components and equipped with a keyboard, mouse, HDMI monitor and power supply for the in laboratory tests (**B**).  
level: the original FE drivers required to be modified and recompiled on the target platform, in order to manage the connection of the two FEs unambiguously.  
Software components include routines for FE configuration, usage modes and grabbing functionality. Thanks to the flexibility of the selected FEs, based on the SDR paradigm, the user is allowed to create his or her own setup, configuring the parameters listed in the first column of Table 2. In our setup, the parameter configuration is the same for both FEs in the sensor. In order to manage two USB data streams, the default sampling frequency chosen for the prototype was the lowest possible permitted by the manufacturer; this choice allows for storing more than \(30\) min of data on the ODROID-X2 eMMC, which is sufficient for our purposes.  
The sensor can be used in two modes, based on the number of signals the user desires to process:  
1. Basic mode: direct channel + one LHCP reflected channel (only the master FE enabled);
2. Advanced mode: direct channel + two reflected channels (LHCP and RHCP).  
Each mode is implemented via software, using proper shell scripts for the FE configuration, which are executed as startup applications. In this way, at power up, the ODROID-X2 automatically boots the OS, configures the FEs based on one of the above-described usage modes and launches the data grabbing, which uses the eMMC module as the storage unit. The start and stop commands and the duration of data grabbing are parameters to be defined based on the flight plan. Note that, with a \(13\) MHz sampling frequency, the two modes have a different impact on the necessary amount of memory: the advanced configuration requires \(1.56\) GB/min, allowing one to save more than 30 min of data, while the basic configuration halves the rate, thus doubling the total amount of storable data. Since the raw data are stored to memory, ready for off-line processing, the sensor is fully enabled for all of the available GNSS signals, and the information of all visible satellites is fully preserved: this approach facilitates a thorough validation of the prototype and an accurate interpretation of the soil parameter estimation.  
\begin{table}
\begin{tabular}{l l l} \hline \hline
**Configurable Parameter** & **Admissible Range** & **Default Value** \\ \hline Sampling frequency & 13 \(\div\) 40 MHz & 13 MHz \\ Channel IF, carrier frequency & \{L1, E1, G1\} & 1575.42 MHz \\ Channel IF, intermediate frequency & Not specified & 3.55 MHz \\ Channel IF, double-sided bandwidth & 2 \(\div\) 9.66 MHz & 4.2 MHz \\ Channel BB, carrier frequency & \{L1, E1, G1, L2, G2, L5, E5a, E5b\} & 1575.42 MHz \\ Channel BB, intermediate frequency & 0 MHz & 0 MHz \\ Channel BB, single-sided bandwidth & 1.39 \(\div\) 10.09 MHz & 4.0 MHz \\ Channel BB, filter gain & 0 \(\div\) 15 dB & 6 dB \\ \hline \hline \end{tabular}
\end{table}
Table 2: Configuration options for the RF front-ends. Channel IF and Channel BB are the two RF chains of each front-end. The rightmost column contains default values used during the tests. The admissible ranges are derived from the examples presented in the Stereo front-end (FE) user manual and have not been completely tested by the authors.