# Native Smartphone Single- and Dual-Frequency GNSS-PPP/IMU Solution in Real-World Driving Scenarios
## 2 Mathematical Models and Data Processing Strategies
### Tightly-Coupled PPP/IMU Model  
The inertial sensor serves as the dead-reckoning sensor that provides relative displacement information that determines the user's position based on the previous position. Rather than absolute, position-fixing measurements such as GNSS, an IMU requires initialization from known knowledge to compute a navigation solution. GNSS solution suffers from the inherent disadvantage of a space-based ranging system where challenging environments degrade or disable position solutions. Fusing the measurements from the native IMU within smartphones provides (1) a dead-reckoning solution from mechanization equations and (2) an improved EKF (Extended Kalman Filter) solution that employs sensor fusion. The section briefly reviews the key ideas in mechanization and EKF fusion with PPP.  
Typically, in a GNSS/IMU fused system, the IMU has a higher data rate than GNSS receivers. In the case of smartphones, typically the GNSS sensor has a one-second sampling interval and a varying data frequency from IMUs due to internal power-saving or other factors within the operating system. To unify IMU input, the IMU data are pre-processed through interpolation to produce a uniform 100 Hz data stream [35].  
Mechanization enlists a series of deterministic physical equations to compute the updated attitude, velocity, and position based on known information and current IMU accelerometer/gyroscope readings. This solution, without GNSS measurements is considered the IMU-only solution in the subsequent analysis, or the dead-reckoning solution. The IMU measures specific force \(f^{b}_{ib}\) and angular rate \(\omega^{b}_{ib}\) as inputs to the mechanization equations. Here, the subscript \(b\) refers to the IMU body frame, and \(i\) refers to the inertial frame. In this context, the specific force measured \(f^{b}_{ib}\) should be interpreted as measurements in the body frame with respect to the inertial frame, resolved in the body frame axes. The inertial solution coasted from the last GNSS observation is carried onto the next available GNSS epoch for the EKF.  
A tightly-coupled integration approach is used in this study. In tightly-coupled GNSS/IMU integration, the EKF takes in GNSS measurements and updates both IMU and GNSS states in a centralized approach. The total-state vector is defined as Equation (2) [31, 42, 43]:  
\[\delta X=[X_{x,y,z}\quad V_{x,y,z}\quad\varepsilon_{x,y,z}\quad\delta I_{r}^{s} \quad\delta T_{r}^{s}\quad\delta t\quad\delta i\quad b_{x,xy,yz}\quad b_{gx, gy,gz}\quad N^{s}] \tag{2}\]  
where \(X_{x,y,z}\) denotes the position states; \(V_{x,y,z}\) denotes the velocity states; \(\varepsilon_{x,y,z}\) denotes the attitude in local navigation frame; \(\delta I_{r}^{s}\) and \(\delta T_{r}^{s}\) denote the slant ionospheric and tropospheric delay, respectively; \(\delta t\) denotes receiver clock errors; \(\delta t\) denotes receiver clock drift; \(b_{ax,ay,az}\) and \(b_{gx,gy,gz}\) denote bias in accelerometer and gyroscope, respectively; and \(N^{s}\) denotes the float ambiguity terms.  
The design of the PPP/TC EKF is based on a conventional closed-loop model demonstrated in Figure 1. The raw measurements conditioned through pre-processing are fed into the mechanization equations to produce an IMU-only solution. Once the next GNSS observation set becomes available, the GNSS-PPP/IMU EKF runs to produce a solution. Finally, the bias estimates for accelerometers and gyroscopes are fed back to the IMU data reading in the closed-loop feedback approach for the next epoch. The feedback is additive to raw \(f^{b}_{ib}\) and \(\omega^{b}_{ib}\) inputs. Since mechanization runs using the state vector inherited from the previous epoch, an accurate dead-reckoning solution requires an accurate fused prior epoch estimate. The EKF employs zero-velocity update (ZUPT) to improve solution quality when the vehicle is stationary.