Global Ionosphere Maps Produced by CODE

Global ionosphere maps (GIM) are generated on a daily basis at CODE using data from about 200 GPS/GLONASS sites of the IGS and other institutions. The vertical total electron content (VTEC) is modeled in a solar-geomagnetic reference frame using a spherical harmonics expansion up to degree and order 15. Piece-wise linear functions are used for representation in the time domain. The time spacing of their vertices is 2 hours, conforming with the epochs of the VTEC maps. Instrumental biases, so-called differential P1-P2 code biases (DCB), for all GPS satellites and ground stations are estimated as constant values for each day, simultaneously with the 13 times 256, or 3328 parameters used to represent the global VTEC distribution. The DCB datum is defined by a zero-mean condition imposed on the satellite bias estimates. P1-C1 bias corrections are taken into account if needed. To convert line-of-sight TEC into vertical TEC, a modified single-layer model mapping (MSLM) mapping function approximating the JPL extended slab model mapping function is adopted. The global coverage of the GPS tracking ground stations considered at CODE is shown here (PS/PDF file), or here including 4-figure abbreviations for station identification (PS/PDF file).

Note 1: CODE GIM results correspond to the results for the middle day of a 3-day combination analysis solving for 37 times 256, or 9472 VTEC parameters and one common set of satellite and receiver DCB constants. In this way, discontinuities at day boundaries can be minimized. Furthermore, a time-invariant quality level is achieved. This model improvement concerns the final GIM results as of day 076, 2002 (GPS week 1158). This model change was announced in IGS Mail 3823 (and BSW Mail 144).
Note 2: Starting with day 307, 2002 (GPS week 1191), all provided CODE IONEX files include 13 VTEC maps. The first map refers to 00:00 UT, the last map to 24:00 UT (instead of 01:00 and 23:00 UT, respectively). The time spacing of the maps (snapshots) is still 2 hours. Due to the fact that each new daily file contains ionospheric information covering not only 22 but 24 hours, data interpolation becomes more user-friendly. This model change was announced in IGS Mail 4162 (and BSW Mail 153).
Note 3: Starting with day 117, 2003 (GPS week 1215), GLONASS tracking data from GPS/GLONASS-combined receivers is considered. Data of 173 such GNSS receivers is regularly analyzed (simultaneously with that of GPS-only receivers).

CODE GIM Product Overview

Our ionosphere products are available via the AIUB anonymous ftp server in the IONosphere map EXchange (IONEX) format and in the ION format of the Bernese GPS Software. Since June 1, 1998, the final IONEX product is delivered weekly to CDDIS, a global data center of the IGS. Examples of both file types containing the most recent GPS-derived GIM information are accessible here: Our global TEC data series covers, without any gaps, the time interval from January 1, 1995 to now. If you are interested in using the (space-saving) Bernese ION files, we refer to the document explaining How to use CODE's Global Ionosphere Maps (PS file) and the corresponding subroutines. Nevertheless, nowadays we highly recommend to make use of the IONEX interface, since this is the ionosphere interface adopted by the IGS community and also used by altimeter groups, etc.

CODE's final IONEX files (named CODGddd0.yyI.Z) are made available with a delay of 3 days and the rapid ones (named CORGddd0.yyI.Z) with a delay of approximately 12 hours, whereas the predicted IONEX information (named COPGddd0.yyI.Z) can be used for real-time applications. ddd denotes the 3-digit day of year and yy is the 2-digit year. The Bernese ION files are called CODwwwwd.ION, CODwwwwd.ION_R, CODwwwwd.ION_P, and CODwwwwd.ION_P2, respectively, where wwwwd stands for the 4-digit GPS week and a 1-digit day number (0-6). Examples: CODG1520.98I.Z and COD09601.ION.Z - for the final ionospheric files of June 1, 1998. All rapid and predicted CODE IGS products may be found at; the final products are stored in year-specific subdirectories, like 2012. Click here to get a calendar (with MJD, GPS and DIN weeks, days of the year) for a specific year.

Fortran-77 modules for writing and reading IONEX files are quoted in the IONEX manual. In addition, an interpolating routine is available, that supports various interpolation strategies. For CODE IONEX data, we recommend to use interpolation strategy number 3. In case of (old) 12-map data sets, strategy number 4 (or alternatively 3) is recommended (see also IGS Mail 4162) A PS version of the IONEX manual is available here. Note that AIUB's IONEX modules are no longer available at$ftp/ionex/source/ but at

A list of AIUB publications which are available in electronic form may be found in CONTENTS.TXT. Corresponding articles and reports are accessible at In connection to GPS-ionosphere issues, let us emphasize in particular (205 pp.).

Differential GPS and GLONASS P1-P2 Code Biases

Moreover, our IONEX files contain in the header part information concerning the so-called differential (P1-P2) code biases (DCBs) for all active GPS and GLONASS satellites (see also IONEX example). A brief DCB description can be found in the IONEX manual. A combined set of DCB values for the GPS satellites and the IGS stations processed at CODE - taking into account the last 30 daily sets (PDF file) - is regularly computed. The daily repeatability of the satellite-specific biases is currently 0.033 nanoseconds rms for the GPS constellation and 0.057 nanoseconds rms for the GLONASS constellation. (Note that the rms specification may be falsified, associated with a DCB jump concerning PRN G11 on day 256, 2001, PRN G17 on day 055, 2003, PRN R07 on day 121, 2003, PRN R23 on day 266/267, 2003, PRN R05 on day 274, 2003, PRN R24 on day 328, 2003, PRN R24 on day 358, 2003, PRN R21 on day 019, 2004, PRN R18 on day 036, 2004, PRN R24 on day 139, 2004, PRN R23 on day 241, 2004, PRN R06 on day 265, 2004, PRN R04 on day 291, 2004, PRN R06 on day 345/346, 2004, PRN G14 on day 355/356, 2004, PRN R02 on day 047, 2005, PRN R05 on day 073, 2005, PRN R06 on day 078/079, 2005, PRN R23 on day 059, 2006, PRN G17 on day 256, 2006, PRN R08 on day 257, 2006, PRN G23 on day 095/097, 2007, or PRN R24 on day 114-125, 2007.) The present CODE DCB list contains estimates for 32 GPS plus 24 GLONASS satellites (56 GNSS satellites) and 287/173 tracking stations of the GPS/GLONASS system.

GLONASS P1-P2 DCB results are plotted here (PDF). The differing DCB value belongs to R05 (105), which is a GLONASS satellite of the GLONASS-M modernization program.

Monthly P1-P2 DCB solutions are available as of October 1997. The corresponding files are called P1P2yymm.DCB.Z, or P1P2yymm_ALL.DCB.Z, if station-specific bias values are included. They are archived here. The latest two monthly DCB solutions are compared here.

A comparison of current CODE 30-day GPS P1-P2 DCB averages with GPS broadcast group delay (GD) values may be found here (PDF). The CODE computed DCB values are indicated by encircled dots. Note that the GPS broadcast GD values were converted into DCB values and realigned following a zero-mean condition. The GPS DCB offset is 5.252 nanoseconds, corresponding to a mean GD value of -8.118 nanoseconds divided by -1.55.

Differential GPS P1-C1 Code Biases

Starting with GPS week 1056, the IGS analysis centers have to take P1-C1 code biases into account in order to ensure that their precise clock information is fully consistent to P1/P2 code measurements. Background and details may be gathered from IGS Mails 2320, 2744, 2827, 2879, and 3160.

CODE is accounting for this type of code bias as from GPS week 1057 (April 9, 2000) by solving for satellite-specific differential (P1-C1) code bias (DCB) parameters as part of the clock estimation procedure. Our approach works as long as a mixture of data of cross-correlation style receivers and modern receivers is processed. At present, about 30-40 of about 80 stations in all used for the clock estimation may be related to a cross-correlation style receiver providing C1 and X2 code measurements. The improvement of our clock estimates due to the mentioned measure is clearly detectable.

Let us briefly highlight the P1-C1 DCB files automatically updated:

The day-to-day reproducibility of our daily P1-C1 DCB estimates is of the order of 0.05 nanoseconds, or 15 millimeters (currently 0.018 nanoseconds rms). (Note that this rms specification may be falsified, associated with a DCB jump concerning PRN 11 on day 256, 2001, PRN 17 on day 055, 2003, or PRN 23 on day 095/097, 2007.)

The straightforward method to derive P1-C1 code biases is to analyze P1-C1 code differences based on GPS tracking data from non-CC receivers, like Ashtech Z12, AOA Benchmark, or AOA Turborogue upgraded with ACT, etc. Depending on the receiver type considered, slightly different results are obtained, however. This reveals that a receiver-specific component may be present with respect to P1-C1 biases (specific to the satellites).

Remark: P1-C1 DCBs specific to receivers may be expected to be existing for both non-CC and CC receivers. In principle, there is only one case where the user may not simply connive at receiver-specific P1-C1 DCBs, namely if tracking data of a CC receiver has been recorded in both AS-on and AS-off mode (depending on the PRN observed).

CODE uses a fundamentally different, more sophisticated approach:

We will continue in monitoring these code biases since they are not as constant as one might like - and since several launches of new GPS spacecrafts are announced for the near future. Another motivation for us to continue with this service is certainly the circumstance that our P1-C1 bias values are recommended to be adopted for use with the IGS official products from GPS week 1097 onwards (see IGS Mail 3160). The history of the values adopted by the IGS may be traced in the file p1c1bias.hist maintained by the IGS Central Bureau. The interested reader is also referred to the IGS/BIPM web site.

Our continuously updated P1-C1 and P1-P2 DCB sets are posted to the ftp directories BSWUSER50/ORB and CODE. At the beginning of each month, monthly DCB solutions with respect to the preceding month are computed and automatically archived in the subdirectory CODE/yyyy, where yyyy is the 4-digit year. Corresponding files are addressed with 2-digit year and month (e.g., P1C10012.DCB.Z or P1C10012.F.Z). Monthly P1-C1 DCB solutions are available as of May 2000. Daily P1-C1 bias estimates are available on special request.

For the user of IGS precise clock information, it remains important to realize that the knowledge of P1-C1 and/or P1-P2 code biases allows them to transform the P1/P2-consistent clock estimates to clock estimates which are consistent to the ionosphere-free linear combination of code observations provided by cross-correlation style receivers, or, in the single-frequency case, to C/A code observations. It is obvious that corresponding clock corrections may be also derived for other combinations, if desired. It is worth mentioning that in addition to P1/P2 and C1/X2 receivers a third receiver class must be recognized: C1/P2 receivers (see IGS Mail 3737 for more details). Our receiver table includes the receivers commonly used within IGS and EUREF.

CC2NONCC is an easy-to-use tool to handle P1-C1 biases. This tool works properly on the condition that (a) receiver names are used following the IGS naming conventions and (b) current RINEX data is converted. In the case the user wishes to convert older data, he is advised to revert to our DCB data archive and to adjust CC2NONCC accordingly. The same is valid if somebody is interested in updating CC2NONCC more frequently.

Differential GPS P2-C2 Code Biases

Publication of corresponding results (concerning PRN G17) is intended within the next months.

Klobuchar-Style Ionospheric Coefficients

Since mid of July 2000, Klobuchar-style ionospheric coefficients (alphas and betas) best fitting our IONEX data are computed on a regular basis. A validation study based on two months of data confirmed that our predicted coefficients perform significantly better than the coefficients originally broadcast by the GPS for the single-frequency user.

The RINEX navigation data files containing such improved ionospheric coefficients are named CGIMddd0.yyN, where ddd and yy substitute doy and 2-digit year. Those coefficients derived from our final IONEX product are stored under in yyyy-specific subdirectories as of 1995. For the few days where the final product is not yet available, rapid as well as predicted coefficients serving real-time applications may be found generally at CGIM1850.12N_R contains the latest set of rapid coefficients; CGIM1860.12N_P and CGIM1870.12N_P2 contain the current 1-day and 2-day predicted coefficients, respectively:

Because the Klobuchar-style TEC parameterization may be unpleasant at the polar caps and especially at the poles, we display a corresponding warning in our RINEX navigation data files in case the TEC above a latitude of 75 degrees reaches day-time level. This basic problem is effective actually for both our model derivative and the original model.

Hint Concerning CODE Data Archive

If you experience a problem in accessing our anonymous ftp area at by using your internet browser, there is also a possibility to access this area via http, by pointing your browser to the following address:

For questions about the CODE GIM and DCB products please contact Stefan Schaer from the CODE AC Team.

This page was automatically updated on 04-Jul-2012 at 08:18:58 UT.

Back to CODE homepage, Bernese GPS Software homepage, AIUB homepage, or University of Berne homepage.