Introduction

Today, Global Navigation Satellite Systems (GNSSs) are used for a multitude of applications around the world, and there is a general quest for better positioning accuracy and reliability, as well as faster position acquisition from both user groups and the GNSS research community. Combining observations from multiple GNSSs in one positioning process and/or using multiple frequencies from one or more GNSSs is important step toward reaching these goals (Gleason and Gebre-Egziabher 2009). Accounting for all error sources in the positioning process, including hardware biases, is a prerequisite for accurate results.

GNSS hardware biases occur because of imperfections and/or physical limitations in GNSS hardware. The biases are a result of small delays between events that ideally should be simultaneous in the transmission of the signal from a satellite or in the reception of the signal in a GNSS receiver. Consequently, these biases will also be present in the GNSS code and phase measurements. Moreover, hardware-induced biases differ between different signals, e.g., P1 and P2, and between different carrier waves, e.g., L1 and L2. Hardware-induced biases will cause degradation in the accuracy of the positioning solution if not handled properly. This is especially important in high-accuracy positioning with multiple GNSSs (Odijk and Teunissen 2012; Paziewski and Wielgosz 2014; Tegedor et al. 2014), in Precise Point Positioning (PPP) for the resolution of the integer ambiguities (Teunissen and Khodabandeh 2014), and when using GNSS observations for estimation of the Total Electron Content (TEC) in the ionosphere (Jensen et al. 2007; Lanyi and Roth 1988; Sardon and Zarraoa 1997).

The topic of GNSS hardware biases has received a great deal of attention in recent years. The introduction of GLONASS besides GPS in precise positioning requires knowledge of biases in the receiver hardware that tend to be specific to the receiver model (Leick et al. 1998; Raby and Daly 1993; Wanninger and Wallstab-Freitag 2007). The emergence of new GNSSs, such as the European Galileo (OS-SIS-ICD-1.2 2015) and the Chinese BeiDou (BDS-SIS-ICD-2.0 2013), further increases the need of understanding about GNSS hardware biases, as such knowledge can lead to both an increase in the accuracy of the positioning solution, as well as a reduction in the solution convergence time. The International GNSS Service (IGS) (Dow et al. 2009) arranged bias workshops in 2012 and 2015 to address this issue. In addition, a new data format with the purpose to store and exchange bias information has been developed recently. The format is called SINEX BIAS, and it is based on the Solution (Software/technique) INdependent EXchange Format (SINEX). It supports storage of code and phase biases specific to a particular GNSS, satellite, receiver, or satellite–receiver combination (Schaer 2016).

As it turns out, code and phase biases are difficult to estimate in their undifferenced form, as they are highly correlated with other terms, e.g., clock errors. Thus, only differences between biases are possible to estimate directly from code and phase observations. However, very often, it is sufficient to know only the differences between certain biases, as common offsets to the absolute biases might be absorbed by other terms (e.g., the receiver clock error) in the positioning process and thereby not influencing the calculated positions. Bias differences can be formed in various ways, relevant for different applications. Here, a review is performed of various phase and code bias differences, and a special emphasis is given to biases that have relevance for precise positioning. The term bias will be used exclusively for delays that are induced either in the satellite or in the receiver hardware.

Theoretical description of various biases

The observation equations have the following form for the code and phase observables, respectively (Hoffman-Wellenhof et al. 2008). They are slightly modified to also include the receiver and satellite phase and code biases.

$$\phi_{f,r}^{{{\text{sys}},s}} = \rho_{r}^{s} + c\left( {\delta_{r} - \delta^{s} + b_{f,r}^{\text{sys}} - b_{f}^{s} + \tau^{\text{sys}} } \right) + T_{r}^{s} - I_{f,r}^{s} + m_{f,r}^{s} + \lambda_{f} N_{f,r}^{s} + \varepsilon_{\phi }$$
(1)
$$R_{{{\text{sig}},r}}^{{{\text{sys}},s}} = \rho_{r}^{s} + c\left( {\delta_{r} - \delta^{s} + B_{{{\text{sig}},r}}^{\text{sys}} - B_{\text{sig}}^{s} + \tau^{\text{sys}} } \right) + T_{r}^{s} + I_{{f_{\text{sig}} ,r}}^{s} + M_{{{\text{sig}},r}}^{s} + \varepsilon_{R}$$
(2)

The notation \(( \cdot )_{{{\text{sig}}/f,r}}^{{{\text{sys}},s}}\) is henceforth used for a term associated with a signal sig or carrier wave frequency f, recorded by a receiver r, and which is transmitted by satellites, belonging to a GNSS system sys. Absence of either of these notations means that the term represents a contribution that is independent of that notation, only limited to the context in which the equation appears. Here the term “signal” depicts a ranging code modulated on a particular carrier frequency.

In (1) and (2), the terms are defined in the following way: ρ s r true geometrical distance between receiver r and satellite s, δ r receiver clock error, δ s satellite clock error, B syssig,r receiver hardware code bias for signal sig, B ssig satellite hardware code bias for signal sig, b sys f,r receiver hardware phase bias for carrier wave frequency f, b s f satellite hardware phase bias for carrier wave frequency f, τ sys time offset for the system time of GNSS system sys with respect to a chosen reference, T tropospheric delay, I ionospheric delay, M code multipath, m phase multipath, λ f wavelength of the carrier wave with frequency f, N phase ambiguity term, ɛ ϕ phase noise, and ɛ R code noise.

In (1) and (2), some error sources have been omitted for the sake of brevity. These error sources include antenna phase center variations, earth tides, ocean loading, and for phase observations also the phase windup effect. The time dependence of the terms has been omitted for the same reason. In addition, extra care has to be taken with the receiver clock error as the observation time tags also depend on this error. It can be corrected with an additional term \(\dot{\rho }_{r}^{s} \delta_{r}\), where \(\dot{\rho }_{r}^{s}\) is the time derivative of the geometrical distance between receiver r and satellite s.

It is here assumed that the receiver hardware delays are the same for satellites belonging to the same constellation and broadcasting the same signal. As will be shown, this assumption holds true most often for GNSSs using code division multiple access (CDMA) to distinguish between signals transmitted by different satellites. It is, however, not true for GLONASS biases, as GLONASS employs frequency division multiple access (FDMA) instead of CDMA. A consequence of FDMA is that the receiver hardware bias will vary depending on the satellite tracked, as the channels for different carrier wave frequencies will cause different delays in the receiver. These GLONASS-related biases apply both for phase and code measurements, and they will be discussed later.

Table 1 gives a summary of the biases that will be treated in the following sections. GNSS hardware biases appear both in the receiver and in the satellite hardware, and this is reflected in the second column in Table 1. For completeness, the absolute biases as given in (1) and (2) are also included in the table even though these biases are not estimable directly from GNSS observations; thus, the third column indicates whether the bias is an absolute value or a relative value (most often the product of combinations of observations). A bias will here also be defined as relative if it is biased by other error sources. The fourth column refers to the symbols used for the biases in this paper, and the fifth column lists the temporal variation of the biases. In general, GNSS hardware biases have been shown to be stable over time, and this is reflected for most of the biases estimated for practical applications. However, in some cases, the estimated bias might contain residues from other error sources that will affect its long-term stability. The last two columns list how the biases are normally treated on the user side in the positioning process. Here, we distinguish between four different ways of dealing with biases on the user side:

Table 1 GNSS Hardware biases
Full size table

  • Eliminate—the bias cancels out in the positioning model used, usually by between satellites or between receivers differencing

  • Estimate—the bias is estimated as an unknown parameter in the positioning process

  • Correction—the bias is estimated by other sources and broadcasted to the user in real-time as the bias only have a short-term stability

  • Calibrate—the bias is pre-estimated by other sources and used for the more stable biases

When applying these methods, the bias in question might be merged with other error sources, i.e., for elimination, the bias might be eliminated together with other error sources, and for estimation, the bias does not need to be explicitly expressed in the model and might be merged with other parameters.

In Table 1, the symbols for the relative satellite phase bias, the code intersystem bias (ISB), and for the GLONASS code inter-frequency bias (IFB) have been omitted, as they are not described by any equations in this paper. Further, in the user columns, as mentioned earlier, none of the absolute biases can actually be estimated, either in the estimation process, or as a correction. However, they can be eliminated by forming either between receivers or between satellites differences.

Phase biases

Precise positioning techniques rely on measuring the phase of the carrier wave on which the GNSS signals are modulated. In comparison with the code observable, the phase observable has a much lower noise level, which allows for a higher positioning accuracy. However, the phase observable is ambiguous by an unknown number of wavelengths, which also has to be resolved in the positioning process. In addition, as is apparent by (1), the phase observable is biased by delays induced by the receiver and satellite hardware. These delays prevent integer ambiguity resolution if not accounted for properly.

Relative precise positioning

Relative precise positioning techniques often employ double differencing, even though relative positioning can be performed through an undifferenced approach (De Jonge 1998). The process of forming double differences is described in Hoffman-Wellenhof et al. (2008). Double differencing (1) gives

$$\phi_{{f,r_{1} r_{2} }}^{{sys_{1} sys_{2} ,s_{1} s_{2} }} = \rho_{{r_{1} r_{2} }}^{{s_{1} s_{2} }} + cb_{{f,r_{1} r_{2} }}^{{sys_{1} sys_{2} }} + T_{{r_{1} r_{2} }}^{{s_{1} s_{2} }} - I_{{f,r_{1} r_{2} }}^{{s_{1} s_{2} }} + m_{{f,r_{1} r_{2} }}^{{s_{1} s_{2} }} + \lambda_{f} N_{{f,r_{1} r_{2} }}^{{s_{1} s_{2} }} + \varepsilon_{{\phi_{DD} }}$$
(3)

where \(\left( . \right)_{{f,r_{1} r_{2} }}^{{{\text{sys}}_{ 1} {\text{sys}}_{2} ,s_{1} s_{2} }} = \left( {\left( . \right)_{{f,r_{2} }}^{{{\text{sys}}_{2} ,s_{2} }} - \left( . \right)_{{f,r_{1} }}^{{{\text{sys}}_{2} ,s_{2} }} } \right) - \left( {\left( . \right)_{{f,r_{2} }}^{{{\text{sys}}_{ 1} ,s_{1} }} - \left( . \right)_{{f,r_{1} }}^{{{\text{sys}}_{1} ,s_{1} }} } \right)\), and satellite s i belongs to system sys i . It is here apparent that the satellite bias term cancels out along with the satellite clock term when differencing between receivers. This is not true for the receiver bias when differencing between satellites, as these may belong to different GNSS constellations. The remaining receiver bias term is the so-called ISB, which will be discussed later on. In addition, the carrier wave frequencies may differ if the satellites belong to different constellations even if that is not reflected in the formula above. However, it should be noted that while the double-differenced ambiguity is an integer in the single frequency case, different frequencies would mean that the integer nature of the double-differenced phase ambiguity is lost.

PPP

PPP is an absolute precise positioning technique, where undifferenced or between satellites single differenced observations are used (Kouba and Héroux 2001; Zumberge et al. 1997). In contrast to relative positioning, where most biases that inhibit the integer ambiguity resolution cancel out in the double differencing process, these biases remain as an error source in PPP. Their presence will affect the quality of the positioning solution if not dealt with accordingly. As error sources need to be handled explicitly to a greater degree in PPP, rank deficiencies might appear in the positioning model as a consequence of an increasing number of parameters to estimate. Various ways to deal with these rank deficiencies have been developed over the years, and they can be summarized as either lumping different parameters together, or assuming some of their values. This is a reason why the hardware biases often appear in the equations as merged with other error sources to which they are highly correlated. In the following two sections, about satellite phase biases and phase ISBs, the usage of constellations employing CDMA is assumed. The last section about phase biases will treat the FDMA case with GLONASS inter-frequency biases.

Satellite phase biases

Unlike relative positioning, where the biases cancel out when forming the double differences as in (3), the receiver and satellite hardware biases remain in the PPP model, described by (1). Because of these biases, the resolution of phase ambiguities to integers cannot be performed the same way in PPP as in relative positioning.

An advantage of integer ambiguity resolution in PPP is that the convergence time for real-time applications is reduced, at the same time as the accuracy of the solution is increased, especially in the longitudinal direction (Collins et al. 2008). Unfortunately, a rank deficiency of the system of observation equations for this positioning model makes it impossible to unambiguously and simultaneously estimate both the phase bias terms and the ambiguity term in (1) (Teunissen and Khodabandeh 2014). The size of typical phase biases does not allow the resolution of the integer ambiguities when the ambiguity term and the phase bias terms are lumped together (Ge et al. 2008). It is thereby only possible to resolve the integer ambiguities in PPP when the phase biases are known beforehand.

In (1) and (2), it was assumed that the receiver hardware biases were the same for all satellites in the same constellation. The assumption that receiver phase biases are similar for different satellites is proven correct by the fact that the phase ambiguities of double-differenced phase observations can be resolved as integers. Because of this similarity of the receiver phase bias with respect to the tracked satellite, this term is not correlated with the ambiguity term in (1), and it might even cancel out together with the receiver clock error if single differences between satellites are formed. For this reason, the main error sources that inhibit the resolution of the integer ambiguities in PPP are the satellite clock error together with the satellite phase biases.

Consequently, PPP with integer ambiguity resolution needs satellite phase bias corrections to counteract the presence of phase biases in the observations. When it comes to estimating these bias corrections by the service provider, as mentioned above, they are impossible to estimate to their true undifferenced value due to the system of observation equations being rank deficient. The satellite phase bias term is highly correlated with the phase ambiguity term. On the user side, phase bias corrections are needed to restore the integer nature of the phase ambiguities. Fortunately, it is not necessary to know the true undifferenced phase biases at the user in order to restore the integerness of the ambiguities. Even corrections that are biased by an unknown integer value will achieve this goal. For this reason, this bias is marked as relative in Table 1. It should not be confused with the absolute satellite phase bias in the same table, which can be eliminated in relative positioning.

Several models for PPP with resolution of the integer ambiguities have been presented in recent years. These models include for instance Geng et al. (2012), Bertiger et al. (2010), Collins et al. (2010), Laurichesse et al. (2009), and Ge et al. (2008). It was shown by Teunissen and Khodabandeh (2014) that the various models for integer ambiguity resolved PPP differ in their choice of \({\mathcal{S}}\)-basis (Teunissen 1985) and in the way they are parametrized. To choose a \({\mathcal{S}}\)-basis means to assume values of certain terms in the equation system to remove rank deficiencies, and the assumed terms compose the \({\mathcal{S}}\)-basis. This is similar to setting minimal constraints as described in Leick et al. (2015). The difference in parametrization and the choice of \({\mathcal{S}}\)-basis between the models affects the way the satellite phase bias corrections are provided to the user. They can roughly be divided into either providing fractional cycle biases (FCBs) (Ge et al. 2008; Geng et al. 2012), where the fractional parts of the wide- and narrow-lane biases are distributed to the user, or as the satellite phase biases being merged with the satellite clock corrections (Collins et al. 2010; Laurichesse et al. 2009). It is therefore crucial that the same PPP model is employed both at the service provider side and at the user side. The satellite bias correction corresponds to the relative satellite phase bias in Table 1, as it is lumped either with an unknown integer number of cycles or with the satellite clocks. Since the satellite bias correction in this case is lumped with other error sources, it only has a short-term stability. According to Ge et al. (2008), the narrow-lane bias correction needs to be supplied to the user at least every 15 min.

Phase ISB

When multiple GNSSs are used for one positioning solution, care has to be taken of timescale and reference frame differences between the GNSSs. In addition, there exists an intersystem delay due to receiver and satellite hardware biases. Assuming that the system-related satellite biases are handled appropriately (such as the differences in timescales between GNSSs and satellite biases related to the GNSS own system time), the remaining delay can be attributed to the receiver hardware alone, and it is commonly referred to as an ISB. The ISB appears in the receiver hardware as a consequence of the various signal structures used by satellites belonging to different GNSS constellations (Hegarty et al. 2004). The ISB is thereby also present in cases where identical carrier frequencies are used by the systems. The following discussion about ISBs will be divided into separate parts about relative carrier phase-based positioning and PPP, respectively.

ISBs in relative positioning

As obvious from (3), the ISB is a bias that persists even after forming the double differences if these are formed between satellites belonging to different systems. This bias will therefore be of relevance also in relative positioning. The role of ISBs in relative positioning can be divided between the cases when the carrier frequencies between the systems are identical, and when they are not. In the former case, the formation of double differences can be employed between the systems without destroying the integer nature of the ambiguities, as shown in (3). Forming differences in multi-constellation solutions with overlapping frequencies are sometimes also referred to as tight combining (Julien et al. 2003; Paziewski and Wielgosz 2014; Zhang et al. 2003). Conversely, a multi-constellation solution where the double differences are formed separately for each constellation might be referred to as loose combining (Deng et al. 2013).

An advantage with tight combining is that the integer nature of the ambiguities is preserved even after forming double differences between the systems. This in turn allows for the increased positioning performance associated with fixing the phase ambiguities to integers. The integer nature of the phase ambiguity will, however, only be preserved if the relative phase ISB between the receivers, \(b_{{f,r_{1} r_{2} }}^{{{\text{sys}}_{1} {\text{sys}}_{2} }}\) from (3), can be estimated. As in the case with the satellite phase biases, a rank deficiency in the system of observation equations makes it impossible to estimate the phase ISB in its absolute form, and the estimated phase ISB will thereby be shifted by an unknown integer number of periods. This will not pose any problem, as the restoration of the integer nature to the phase ambiguities still can be achieved.

One instance where tight combining might be employed is for a combined GPS/Galileo solution where the L1 and L5 of GPS are using identical carrier frequencies as the E1 and E5a of Galileo. Both Odijk and Teunissen (2012) and Paziewski and Wielgosz (2014) estimate the GPS/Galileo phase ISBs as an additional parameter in the double-differenced system of observation equations. In Odijk and Teunissen (2012), the rank deficiency is handled by re-parametrization of the observation equations, while Paziewski and Wielgosz (2014) handle it by a constrained least squares adjustment that never allows the estimated ISB to be larger than ±1 cycles.

The phase ISB has been shown to be stable over time (Odijk and Teunissen 2012; Paziewski and Wielgosz 2014), which allows the usage of pre-estimated ISBs when tight combining is employed. This raises the redundancy of the system of observation equations as one parameter less has to be estimated. It was shown by Odijk and Teunissen (2012) that use of pre-estimated phase ISBs will also increase the success rate in fixing the ambiguities to integer values. The relative ISB is insignificant between receivers of the same type, and it is thereby only necessary to consider it in relative positioning where reference and rover receivers are of different types (Odijk and Teunissen 2012).

In cases when the frequencies of the GNSS systems are not identical, tight combining cannot be employed without destroying the integer nature of the phase ambiguities. The integer nature of the ambiguities can then only be preserved with loose combining. This means that the double differences are formed separately for each system, by using one reference satellite from each system. The obvious drawback is that the model contains less equations, which reduces its redundancy, as one additional reference satellite is needed for each additional system. Forming separate double differences for each system means that the phase ISBs of the receivers cancel out from the model, and they can in this case therefore be disregarded. One case in which loose combining is necessary to utilize is combined GPS/BeiDou positioning, as GPS and BeiDou are using different carrier frequencies for their signals. Combined GPS/BeiDou positioning has been demonstrated in Deng et al. (2013), He et al. (2014), and Teunissen et al. (2014).

ISBs in PPP

In contrast to the relative positioning model, additional parameters are present in the PPP model. Most obvious is the correlation between the ISB at the receiver side and the time offset at the system side. It is here necessary to distinguish between PPP with float ambiguity resolution and PPP where the phase ambiguities are fixed as integers. It was shown by Chen et al. (2015) that the ISB and the time-offset parameters could be fully merged with the receiver clock error and the phase ambiguity parameters in float PPP, without affecting the calculated coordinates. This mode of multi-GNSS positioning has been demonstrated by Cai and Gao (2013) and Li et al. (2015) in a GPS/GLONASS/Galileo/BeiDou multi-GNSS solution.

In integer ambiguity resolved PPP, the situation is different. In this case, the satellite clock corrections can be estimated in the same timescale, which thereby eliminates the problem with the system time offset. These corrections will, however, still be contaminated by the ISBs of the reference receivers used to generate the corrections (Melgard et al. 2013). This would not pose any problem if the same receiver type is used at the user side, as the ISBs tend to be similar for receivers of the same type. Otherwise, the clock correction would need to be corrected with the relative ISBs corresponding to the combination of receivers employed by the service provider and the user.

GLONASS phase IFB

The GLONASS IFB is a receiver bias that is caused by the fact that GLONASS is using FDMA to separate signals transmitted by different satellites. In this multiplexing technique, adjacent frequencies within the frequency bands L1 and L2 are assigned for the carrier waves of the different satellites. Different carrier frequencies are processed differently in the receiver channels, causing delays that differ depending on the frequency, and thereby also by the transmitting satellite. The phase IFBs arise in the analog radio-frequency hardware and the digital signal processing (DSP) of the receiver. Sleewaegen et al. (2012) showed that the phase IFB to the greatest part was caused by the DSP in the receiver. The contribution of the analog part only amounted to the sub-millimeter level. Furthermore, it was shown that the IFBs are caused by differences of the delays between the correlator and the generation of the code and phase replicas, respectively. These delays are specific to the receiver architecture, and the GLONASS IFBs are therefore almost identical on receivers of the same type. IFB delays between receivers of different types can differ as much as 5 cm between adjacent frequencies, which means a 73-cm spread for the whole L1 or L2 band (Wanninger 2011). Additionally, it was discovered that the phase IFB was dependent both on the firmware version of the receiver, and on the type of the antenna used (Wanninger 2011). Pratt et al. (1998) found some indications of a linear dependency between the carrier phase IFB and the frequency used by the transmitting satellite. This was later confirmed by both Wanninger and Wallstab-Freitag (2007), and Wanninger (2011). It was furthermore shown by Wanninger (2011) that IFBs remained almost constant during a period of 6 months, which permits the use of pre-estimated values in relative positioning with baselines of mixed receiver types.

GLONASS phase IFBs in relative positioning

In relative positioning, most of these biases will cancel out as long as the reference and the rover receivers are of the same type or belong to the same receiver family (Wanninger 2011; Zinoviev 2005). Relative positioning with mixed receiver baselines and PPP is, however, more problematic. The IFBs between the receivers will here inhibit the resolution of the phase ambiguities as integers. This can, however, be overcome with the knowledge of the relative IFBs between the reference/rover receiver pair. Due to the linear relation between the phase IFB and the frequency, the single difference of (1) can be expressed as

$$\phi_{{f_{s} ,r_{1} r_{2} }}^{{{\text{GLO}},s}} = \rho_{{r_{1} r_{2} }}^{s} + c\left( {\delta_{{r_{1} r_{2} }} + bc_{{r_{1} r_{2} }}^{\text{GLO}} + k_{{f_{s} }} \cdot bv_{{r_{1} r_{2} }}^{\text{GLO}} } \right) + T_{{r_{1} r_{2} }}^{s} - I_{{f,r_{1} r_{2} }}^{s} + m_{{f,r_{1} r_{2} }} + \lambda_{{f_{s} }} \left( {N_{{f_{s} ,r_{2} }}^{s} - N_{{f_{s} ,r_{1} }}^{s} } \right) + \varepsilon_{{\phi_{\text{SD}} }}$$
(4)

where bc is the constant part of the IFB, and bv is the linear frequency dependent term. k is either the frequency offset or the frequency number of satellite s. In practice, it is impossible to estimate both the receiver clock δ r and the constant part of the IFB due to their high correlation. These two terms may therefore be lumped together, to form a GNSS-specific receiver clock offset term \(\delta_{r} + bc_{r}^{\text{GLO}} = \bar{\delta }_{r}^{\text{GLO}}\) (Wanninger and Wallstab-Freitag 2007).

As the GLONASS IFB is a receiver bias that is also dependent on the transmitting satellite, the IFBs of the receiver can only be estimated in its relative form, as a between receivers bias. This is due to the high correlation between the satellite dependent receiver bias, or IFB, and the biases of the satellites themselves. This is reflected in (4), where the satellite biases have been canceled out in the single differencing process, but at the expense that the IFBs are now expressed as relative IFBs.

An alternative way of fixing the GLONASS phase ambiguities to integers was demonstrated by Banville et al. (2013). This technique does not require explicit knowledge of calibrated IFBs, but instead two satellites with adjacent frequency numbers have to be observed simultaneously. A drawback of this method, in comparison with the method of using predetermined IFBs, is that a considerably lower success rate of the integer ambiguity resolution is achieved in a GLONASS only solution. However, the success rates of the two methods are comparable if also GPS observations are included in the solution.

GLONASS phase IFBs in PPP

In a PPP GLONASS float solution, the phase IFBs can be absorbed by the phase ambiguity parameters in the positioning process (Chen et al. 2015), which means that no explicit knowledge of the IFBs is needed. GLONASS PPP with integer-resolution of the phase ambiguities is, however, more complicated. The integer-resolution of the phase ambiguities is in this case not only inhibited by the satellite phase biases, as described in the previous section, but also by the existence of GLONASS phase IFBs at the receiver side. Furthermore, the GLONASS phase IFB will not only be present in the receiver at the user side, but will also be mixed into the satellite phase bias corrections transmitted to the user. The satellite phase bias corrections will inevitably be contaminated by the GLONASS phase IFBs of the reference receivers used for their generation, as the satellite phase biases and the GLONASS IFBs in practice are impossible to separate due to their high correlation.

It was demonstrated by Reussner and Wanninger (2011) that the GLONASS wide-lane ambiguities could be resolved in a PPP solution with the knowledge of both IFBs and satellite phase biases. Resolution of the wide-lane ambiguity was, however, limited to cases where the satellite phase bias corrections were generated at a nearby reference station, as the slant ionospheric delays are highly correlated with the IFBs and the phase ambiguity. The presence of IFBs also in GLONASS code measurements (which will be discussed subsequently) inhibits wide-lane ambiguity resolution with the Hatch–Melbourne–Wübbena linear combination (Hatch 1982; Melbourne 1985; Wübbena 1985). In theory, an external ionospheric model can be applied, but also in this case limitations of the accuracy of the model might prevent successful integer-resolution of the ambiguities. As an alternative, Banville (2016) presented a method utilizing the frequency spacing of the L1 and L2 bands. In this method, an ionosphere-free ambiguity of about 5 cm could be defined. Fixing the ambiguity to an integer would in this case not reduce the convergence time of the solution. An increase of the repeatability in the east component was, however, observed.

Code biases

As Eq. (2) suggests, the code bias can be separated into one term that refers to the bias that originates from the receiver hardware, B syssig,r , and one term that refers to the bias that originates from the satellite hardware, B ssig . In this representation, only the satellite term of the equation is assumed to be satellite dependent, while the receiver term is assumed to be constant for all satellites for a given GNSS signal and constellation. However, as will be explained later, this assumption of the receiver originating term being totally independent of the tracked satellite is not true in general, even for GNSS systems employing CDMA.

It was shown by Hegarty et al. (2004) that the receiver hardware delays depend on how signal tracking is employed in the receiver. Depending on the design of the delay-locked loop (DLL), signals that were using the same type of modulation showed different delays. Tracking of signals on the same carrier frequency with different types of modulation also showed delay differences of several nanoseconds. Consequently, receivers of different models, which are built with different architectures, will induce different hardware delays into the signal tracking process. Moreover, signals from different GNSSs, which use different types of modulation, will show different delays in the receiver hardware, even if they are modulated on the same carrier frequency. This applies for instance in combined GPS and Galileo tracking where the same carrier frequencies are used for L1/E1 and L5/E5, but different modulation schemes are applied. Here, a receiver-specific intersystem bias will appear between the pseudorange observables from GPS and Galileo satellites, even though the signals are modulated on carrier waves of the same frequency.

Satellite dependency of receiver originating biases

One of the earliest examples of the phenomenon that different receivers got different range errors tracking the same satellite appeared in 1993, when a signal anomaly of GPS Block II space vehicle number (SVN) 19 gave large differential positioning errors (Edgar et al. 1999). Depending on the correlator spacing adopted in the receiver design, signal deformations on L1 originating from the SVN 19 hardware gave rise to different internal delays in the receivers, resulting in a differential positioning error of several meters when the reference and the rover receiver used different correlator spacing in their discriminators. Recent findings by Lestarquit et al. (2012) showed delay differences as large as 0.7 m between using a 0.1 and 0.05 chip discriminator when analyzing distortions on the C/A-code transmitted from GPS Block IIA PRN-32, corresponding to SVN 23. It was also shown that different satellites, which exhibit different kinds of distortions on their signals, produced different delays for a given correlator spacing. It was described by Simsky and Sleewaegen (2004) that this effect would be reinforced on some receiver brands when the multipath-mitigation setting was turned on. Since some multipath-mitigation algorithms use the form of the measured correlation peak to detect multipath, these distortions on the received signals would incorrectly be interpreted as multipath by the receiver, which would produce an addition to the pseudorange error in the receiver.

However, even if the phenomenon mentioned above is present on all satellite systems using CDMA, its effect is comparatively small in relation to the code interchannel delays induced in the receiver hardware during GLONASS tracking. This effect is similar to the GLONASS phase IFB, and it will be discussed later on. In the following sections, we will focus on various code biases that are of importance in TEC estimation and multi-GNSS positioning.

Differential code biases

The differential code bias (DCB) is a time delay between two GNSS signals transmitted by a single satellite, and it consists of both delays induced in the receiver hardware at reception and in satellite hardware at transmission. The DCBs arise due to the use of different carrier frequencies, and due to differences between the structures of the signals. These delays thereby also exist between different types of signals using the same carrier frequency, as the C/A-code and P-code on GPS L1 (Gao et al. 2001).

The observation equation for the difference between two signals collected with a single receiver has the following form, derived from (2):

$$R_{{{\text{sig}}_{1} {\text{sig}}_{2} ,r}}^{s} = R_{{{\text{sig}}_{ 2} ,r}}^{s} - R_{{{\text{sig}}_{1} ,r}}^{s} = c\left( {B_{{{\text{sig}}_{2} ,r}} - B_{{{\text{sig}}_{2} }}^{s} - B_{{{\text{sig}}_{1} ,r}} + B_{{{\text{sig}}_{1} }}^{s} } \right) + I_{{f_{{{\text{sig}}1}} f_{{{\text{sig}}2}} ,r}}^{s} + M_{{{\text{sig}}_{ 1} {\text{sig}}_{2} ,r}}^{s} + \varepsilon_{{R{\text{sig}}1{\text{sig}}2}}$$
(5)

This difference is sometimes referred to as the geometry-free linear combination, as all geometric terms are canceled out. These include the geometric range, the clock errors, and the tropospheric delay. The term \(B_{{{\text{sig}}_{2} ,r}} - B_{{{\text{sig}}_{2} }}^{s} - B_{{{\text{sig}}_{1} ,r}} + B_{{{\text{sig}}_{1} }}^{s}\) refers to the combined receiver and satellite DCB. The DCB term might be separated into one receiver-specific and one satellite-specific DCB term,

$${\text{DCB}}_{{{\text{sig}}_{1} {\text{sig}}_{2} ,r}}^{s} = {\text{DCB}}_{{{\text{sig}}_{1} {\text{sig}}_{2} ,r}} - {\text{DCB}}_{{{\text{sig}}_{1} {\text{sig}}_{2} }}^{s}$$
(6)

where

$${\text{DCB}}_{{{\text{sig}}_{1} {\text{sig}}_{2} ,r}} = B_{{{\text{sig}}_{2} ,r}} - B_{{{\text{sig}}_{1} ,r}}$$
(7)

and

$${\text{DCB}}_{{{\text{sig}}_{1} {\text{sig}}_{2} }}^{s} = B_{{{\text{sig}}_{2} }}^{s} - B_{{{\text{sig}}_{1} }}^{s}$$
(8)

In (5), \(f_{{{\text{sig}}_{1} }}\) and \(f_{{{\text{sig}}_{2} }}\) might be equal. In that case, even the ionosphere and multipath terms cancel out and only the bias terms remain. Otherwise, both the ionospheric and multipath influences have to be accounted for beside the DCBs.

As the ionosphere is a dispersive medium for all frequencies used by current GNSS carriers, GNSS signals modulated onto carrier waves of different frequency will be delayed by a different amount of time at the moment of reception in the GNSS receiver. DCBs are thereby of significant importance when we want to relate the TEC along the signal path in the atmosphere with a geometry-free linear combination of code observations from different carriers, as the DCB delay adds to the ionospheric delay in the measurements. Separation of these two terms is therefore necessary in order to estimate TEC from GNSS measurements. This is a technique which is used for instance in GNSS-based ionospheric modeling (Jensen et al. 2007).

GPS system time correction parameters transmitted in the broadcast navigation message are given with respect to the ionosphere-free linear combination of the P-code signals on L1 and L2 (IS-GPS-200H 2013). This is achieved by the satellite clock corrections terms in the broadcast navigation message (Tetewsky 2009). Consequently, single frequency users of P-code on L1 or L2 have to correct their measurements with the T GD parameter supplied in the broadcast navigation message. This value corresponds to the differential delay induced in the satellite at the time of transmission of the P-code signals. The GPS Interface Specification document IS-GPS-200H (2013) states that

$$T_{\text{GD}} = \frac{1}{{1 - \frac{{f_{{L_{1} }}^{2} }}{{f_{{L_{2} }}^{2} }}}}\left( {t_{L1P} - t_{L2P} } \right)$$
(9)

Replacing t L1P  − t L2P in (9) by −DCB GPS,s P1P2 , using the same sign convention as earlier, the relation between the T GD parameter and the satellite DCB can be expressed as

$${\text{DCB}}_{P1P2}^{{{\text{GPS}},s}} = \left( {\frac{{f_{{L_{1} }}^{2} }}{{f_{{L_{2} }}^{2} }} - 1} \right)T_{\text{GD}} + C$$
(10)

The constant C has been added to the expression above due to the fact that only the total DCB, \({\text{DCB}}_{{{\text{sig}}_{ 1} {\text{sig}}_{ 2} ,r}}^{s}\), is estimable from GNSS observations alone. The satellite and the receiver part of the total DCB can in practice only be separated if an additional constraint is added. This constraint is usually chosen to be either a mean value constraint, where the mean value of the satellite DCBs are set to zero, or a constraint where the receiver DCB for a certain receiver is set to a certain value known beforehand (Montenbruck and Hauschild 2014). This will give the effect of a constant offset depending on the chosen constraint in the estimation process. For a user relying on the C/A-code on L1 instead of the P-code, only the most modern GPS satellites, which includes the Block IIR-M, Block IIF and subsequent satellite blocks, transmit a C/A-code correction parameter called Inter-Signal Correction (ISC) in the newly implemented civil navigation (CNAV) message (IS-GPS-200H 2013).

As was suggested in the previous section, the receiver originating code biases are sometimes also dependent on the transmitting satellite. This is the case when the transmitted signals are distorted at the satellite payload (Edgar et al. 1999; Lestarquit et al. 2012). As the receiver biases of both signals are constituents of the DCB, this effect of satellite dependence will also show up on the receiver DCB under the conditions mentioned above.

Code ISB

In contrast to the phase ISB, the relative code ISB can be estimated unambiguously. It was shown by Odijk and Teunissen (2012) and Paziewski and Wielgosz (2014) that the code ISBs between GPS and Galileo are close to constant over time, and that receivers of the same type tend to have very similar code ISBs. As in the case with phase ISBs, this means that relative positioning with baselines of mixed receiver types also has to estimate or rely on estimates of the relative code ISB. Typical values of the relative code ISB span from almost zero for receivers of similar type to several hundreds of meters in some cases where the receivers are of different types (Odijk and Teunissen 2012; Paziewski and Wielgosz 2014). This implies that the ISB is of significant importance also in code-based positioning.

GLONASS code IFB

The GLONASS code IFB consists of receiver hardware contributions caused both by the difference in carrier wave frequencies of different satellites, which causes different delays in the channels of the receiver, and to a lesser degree by signal distortions as in the case with CDMA-based GNSS systems. The code IFBs have been shown to be of importance both in Single Point Positioning (SPP), and at the initial convergence of a PPP solution (Chuang et al. 2013). They must also be taken into account in PPP, when resolving the wide-lane ambiguity using the Hatch–Melbourne–Wübbena linear combination (Reussner and Wanninger 2011).

Conversely to the case with the GLONASS phase IFB, the code IFBs in general do not follow a simple linear relation with the carrier wave frequency (Chuang et al. 2013; Reussner and Wanninger 2011; Yamada et al. 2010), even though there exist some exceptions with certain receiver pairs where a linear model will suffice (Al-Shaery et al. 2012; Chuang et al. 2013). As in the case with the phase IFBs, the code IFBs are also dependent on firmware version of the receiver and the type of antenna used (Chuang et al. 2013). The GLONASS code IFB has been shown to be stable over time (Al-Shaery et al. 2012; Chuang et al. 2013; Yamada et al. 2010), which allow for the use of pre-calibrated values in the position estimation.

Concluding remarks and outlook

We have provided a review of current research in the field of GNSS phase and code hardware biases. The origin of the biases has been discussed along with their effect on GNSS-based positioning, and descriptions of how the biases can be estimated or in other ways handled in the positioning process have been provided.

Phase and code biases are becoming increasingly important as the future involves the usage of multiple GNSS systems in one combined positioning process. In addition, the increasing use of PPP as an alternative to conventional relative carrier phase-based positioning makes the consideration of GNSS hardware biases an important issue. This will have a great relevance not only to the end users of positioning solutions, but also to organizations operating networks of continuously operating reference stations (CORS) and to the providers of high-accuracy positioning services. In the future, it is likely that the providers of current network RTK services will provide PPP corrections, and it is obvious that the satellite phase bias corrections together with the phase ISB corrections will be an important ingredient in such new services. The GNSS hardware biases are highly correlated with other parameters, and they can, therefore, not be estimated reliably in their undifferenced form. However, in practical positioning applications it is sufficient to have a differenced value of the biases or have it combined with other parameters. This might, for instance, be in multi-GNSS integer ambiguity resolved PPP, where the satellite phase bias corrections together with the relative phase ISBs can be distributed from the service provider. If also GLONASS is to be included in such a service, the GLONASS IFB needs to be considered. In the case of ISBs and IFBs, there is the option to use pre-estimated values. In that case, it will be up to the user equipment to have bias values of possible reference–rover receiver combinations available, for instance stored in the memory of the user equipment.