Tutorial Bernese PDF

Bernese GNSS Software
Version 5.2
Tutorial
Processing Example
Introductory Course
Terminal Session
Rolf Dach, Peter Walser
September 2014
AIUB
Astronomical Institute, University of Bern
Contents
1 Introduction to the Example Campaign 1
1.1 Stations in the Example Campaign . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Directory Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 The DATAPOOL Directory Structure . . . . . . . . . . . . . . . . . . 4
1.2.2 The CampaignDirectory Structure . . . . . . . . . . . . . . . . . . 6
1.2.3 Input Files for the Processing Examples . . . . . . . . . . . . . . . 7
1.2.4 The SAVEDISK Directory Structure . . . . . . . . . . . . . . . . . . 10
2 Terminal Session: Monday 11
2.1 Start the Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Select Current Session . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Campaign Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Menu Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5 Generate A Priori Coordinates . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Session Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Terminal Session: Pole and Orbit Preparation 17
3.1 Prepare Pole Information . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Generate Orbit Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Session Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Terminal Session: Tuesday 27
4.1 Importing the Observations . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2 Data Preprocessing (I) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2.1 Receiver Clock Synchronization . . . . . . . . . . . . . . . . . . . . 31
4.2.2 Form Baselines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.3 Preprocessing of the Phase Baseline Files . . . . . . . . . . . . . . 38
4.3 Daily Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5 Terminal Session: Wednesday 43
5.1 Data Preprocessing (II) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2 Produce a First Network Solution . . . . . . . . . . . . . . . . . . . . . . . 51
5.3 Ambiguity Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3.1 Ambiguity Resolution: QuasiIonosphereFree (QIF) . . . . . . . . 55
5.3.2 Ambiguity Resolution: Short Baselines . . . . . . . . . . . . . . . . 64
5.3.3 Ambiguity Resolution: Bernese Processing Engine (BPE) . . . . . 67
5.3.4 Ambiguity Resolution: Summary . . . . . . . . . . . . . . . . . . . 71
5.4 Daily Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6 Terminal Session: Thursday 75
6.1 Final Network Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Check the Coordinates of the Fiducial Sites . . . . . . . . . . . . . . . . . 80
Page I
Contents
6.3 Check the Daily Repeatability . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.4 Compute the Reduced Solution of the Sessions . . . . . . . . . . . . . . . 89
6.5 Velocity Estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
6.6 Daily Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7 Additional Examples 101
7.1 Preparing Combined GPS and GLONASS IGSOrbits . . . . . . . . . . . 101
7.1.1 Prepare Pole Information . . . . . . . . . . . . . . . . . . . . . . . 101
7.1.2 Merging Precise Orbit Files . . . . . . . . . . . . . . . . . . . . . . 102
7.1.3 Generating Standard Orbit Files . . . . . . . . . . . . . . . . . . . 103
7.2 Kinematic Positioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.2.1 Estimating Kinematic Positions in a DoubleDierence Solution . . 107
7.2.2 Extracting the Program Output from a Kinematic Positioning . . . 111
7.2.3 Further suggestions . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.3 Zero Dierence Processing for Clock Estimation . . . . . . . . . . . . . . . 112
7.3.1 Preprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.3.2 Residual Screening . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
7.3.3 Generate Clock Solutions . . . . . . . . . . . . . . . . . . . . . . . 124
7.3.4 Further suggestions . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
7.4 Simulation of Global Navigation Satellite Systems (GNSS) Observations . 133
7.4.1 Simulation of GNSS Observations . . . . . . . . . . . . . . . . . . . 133
7.4.2 Zero Dierence Solution from Simulated GNSS Observations . . . 136
7.4.3 DoubleDierence Solution from Simulated GNSS Observations . . 140
7.4.4 Final Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Page II AIUB
1 Introduction to the Example Campaign
1.1 Stations in the Example Campaign
Data from thirteen European stations of the International GNSS Service (IGS) net-
work and from the EUREF Permanent Network (EPN) were selected for the example
campaign. They are listed in Table 1.1. The locations of these stations are given
in Figure 1.1. Three of the stations support only Global Positioning System (GPS)
whereas all other sites provide data from both GPS and its Russian counterpart
Globalna navigacionna sputnikova sistema: Global Navigation Satellite Sys-
tem (GLONASS).
GANP
HERT
JOZ2
LAMA
MATE
ONSA
PTBB
TLSE
WSRT
WTZR
WTZZ
ZIM2
ZIMM
Receiver is tracking
Station with coordinates/velocities in IGb08
Receiver is tracking
GPS/GLONASS GPSonly
,
Figure 1.1: Stations used in example campaign
The observations for these stations are
available for four days. Two days in year
2010 (day of year 207 and 208) and two
in 2011 (days 205 and 206). In the ter-
minal sessions you will analyze the data
in order to obtain a velocity eld based
on nal products from Center for Orbit
Determination in Europe (CODE). For
eight of these stations, coordinates and
velocities are given in the IGb08 refer-
ence frame, an IGSspecic realization
of the ITRF2008 (see ${D}/STAT_LOG/
IGb08.snx).
Between these days in 2010 and 2011
the receivers (LAMA, TLSE, WTZR) and
the full equipment (WTZZ) have been
changed. The receiver type, the antenna
type, and the antenna height are also pro-
vided in Table 1.1. Notice, that for three
antennas (GANP, WTZR, ZIM2) values
from an individual calibration are available
from the EPN processing. For all other antennas only typespecic calibration results
from the IGS processing (${X}/GEN/IGS08.ATX) are available. More details are provided
in Table 1.2. Only in two cases where no calibration of the antenna/radome combination
was available (ONSA, WSRT) the calibration values of the antenna without radome were
used instead. With one exception (ONSA) even systemspecic calibrations for GPS and
GLONASS measurements are available.
The distances between stations in the network are between 200 and 1000 km. There
are two pairs of receivers at one site included in the example dataset: in Zimmerwald,
the distance between ZIMM and ZIM2 is only 19 m. In Ktzting the receivers WTZR
Page 1
Table 1.1: List of stations used for the example campaign including receiver and antenna type
as well as the antenna height.
Receiver type Antenna
Station name Location Antenna type Radome height
GANP 11515M001 Ganovce, Slovakia TRIMBLE NETR8
TRM55971.00 NONE 0.3830 m
HERT 13212M010 Hailsham, LEICA GRX1200GGPRO
United Kingdom LEIAT504GG NONE 0.0000 m
JOZ2 12204M002 Jozefoslaw, Poland LEICA GRX1200GGPRO
LEIAT504GG NONE 0.0000 m
LAMA 12209M001 Olsztyn, Poland 2010: LEICA GRX1200GGPRO
LEIAT504GG LEIS 0.0600 m
2011: LEICA GRX1200+GNSS
LEIAT504GG LEIS 0.0600 m
MATE 12734M008 Matera, Italy LEICA GRX1200GGPRO
LEIAT504GG NONE 0.1010 m
ONSA 10402M004 Onsala, Sweden JPS E_GGD
AOAD/M_B OSOD 0.9950 m
PTBB 14234M001 Braunschweig, Germany ASHTECH ZXII3T
ASH700936E SNOW 0.0562 m
TLSE 10003M009 Toulouse, France 2010: TRIMBLE NETR5
TRM59800.00 NONE 1.0530 m
2011: TRIMBLE NETR9
TRM59800.00 NONE 1.0530 m
WSRT 13506M005 Westerbork, AOA SNR12 ACT
The Netherlands AOAD/M_T DUTD 0.3888 m
WTZR 14201M010 Ktzting, Germany 2010: LEICA GRX1200GGPRO
LEIAR25.R3 LEIT 0.0710 m
2011: LEICA GRX1200+GNSS
WTZZ 14201M014 Ktzting, Germany 2010: TPS E_GGD
TPSCR3_GGD CONE 0.2150 m
2011: JAVAD TRE_G3TH DELTA
ZIM2 14001M008 Zimmerwald, Switzerland TRIMBLE NETR5
TRM59800.00 NONE 0.0000 m
ZIMM 14001M004 Zimmerwald, Switzerland TRIMBLE NETRS
TRM29659.00 NONE 0.0000 m
Page 2 AIUB
1.2 Directory Structure
Table 1.2: List of antenna/radome combinations used in the example campaign together with
the available antenna calibration values in IGS08 model.
Type of calibration used at
Antenna type for GPS for GLONASS stations
AOAD/M_B OSOD ADOPTED from NONE ADOPTED from GPS ONSA
AOAD/M_T DUTD ADOPTED from NONE WSRT
ASH700936E SNOW ROBOT PTBB
LEIAR25.R3 LEIT ROBOT ROBOT WTZR,
WTZZ(2011)
LEIAT504GG NONE ROBOT ROBOT JOZ2, HERT,
MATE
LEIAT504GG LEIS ROBOT ROBOT LAMA
TPSCR3_GGD CONE ROBOT ROBOT WTZZ(2010)
TRM29659.00 NONE ROBOT ZIMM
TRM55971.00 NONE ROBOT ROBOT GANP
TRM59800.00 NONE ROBOT ROBOT TLSE, ZIM2
and WTZZ are separated by less than 2 m this is a short GPS/GLONASS base-
line.
The receivers used at the stations MATE, ONSA, PTBB, and WSRT are connected to
H-Maser clocks. The receiver type ASHTECH Z-XII3T used at PTBB was specically
developed for time and frequency applications. In 2011 both receivers in Ktzting (WTZR
and WTZZ) were connected to the same HMaser (EFOS 18).
The data belonging to this example campaign is included in the distribution of the Bernese
GNSS Software. Therefore, you may also use this document to generate solutions from
the example dataset to train yourself in the use of the Bernese GNSS Software outside the
environment of the Bernese Introductory Course.
There are three areas relevant for the data processing (in the environment of the
Bernese Introductory Course they are all located in the ${HOME}/GPSDATA direc-
tory):
${D}: The DATAPOOL area is intended as an interface where all external les can be de-
posited after their download. It can be used by several processing campaigns.
${P}: The CAMPAIGN52 directory contains all processing campaigns for the Version 5.2 of
the Bernese GNSS Software. In the Bernese Introductory Course environment all
groups use ${P}/INTRO in their ${HOME} directory.
${S}: The SAVEDISK area shall serve as a product database where the result les from
dierent processes/projects can be collected and archived. At the beginning it only
contains reference les (*.*_REF) obtained with the example BPE from the distri-
bution.
Bernese GNSS Software, Version 5.2 Page 3
1.2.1 The DATAPOOL Directory Structure (${D})
Motivation for the DATAPOOL area
The idea of the DATAPOOL area is to place local copies of external les somewhere on your
lesystem. It has several advantages compared to downloading the data each time when
starting the processing:
The les are downloaded only once, even if they are used for several campaigns.
The data download can be organized with a set of scripts running independently from
the Bernese GNSS Software environment, scheduled by the expected availability of
the external les to download.
The processing itself becomes independent from the availability of external data
sources.
Structure and content of the DATAPOOL area
The DATAPOOL area contains several subdirectories taking into account the dierent po-
tential sources of les and their formats:
RINEX :
The data of GNSS stations is provided in Receiver INdependent EXchange for-
mat (RINEX) les. The directory contains observation (Hatanakacompressed) and
navigation (GPS and GLONASS) les. These RINEX les are originary les that
are not changed during the processing.
The RINEX les can be downloaded from international data centers. Projectspecic
les are copied into this area. If you mix the station lists from dierent projects,
take care on the uniqueness of the fourcharacter IDs of all stations in the RINEX
le names.
HOURLY :
The same as the RINEX directory but dedicated to hourly RINEX data as used for
near realtime applications. Note: not all stations in this example provide hourly
RINEX les.
LEO :
This directory is intended to host les which are necessary for Low Earth Orbiter
(LEO) data processing. RINEX les are stored in the subdirectory RINEX (of the LEO
directory). The corresponding attitude les are placed in the subdirectory ATTIT.
These les are needed to run the example BPE on LEO orbit determination (LEOPOD.
PCF). They are not used in the example during the Bernese Introductory Course.
SLR_NP :
The Satellite Laser Ranging (SLR) data is provided in the quicklook normal point
format. The directory contains the normal point les downloaded from the Interna-
tional Laser Ranging Service (ILRS) data centers.
These les are needed to run the example BPE on validating orbit using SLR ob-
servations (SLRVAL.PCF). They are not used in the example during the Bernese
Introductory Course.
Page 4 AIUB
STAT_LOG :
This directory contains the station information les (e.g., from ftp://igscb.igs.
org/pub/station/general). This information may be completed by the originary
information on the reference frame (e.g., the IGb08.snx from ftp://igscb.igs.
org/pub/station/coord).
It also contains (apart from the coordinates and velocities of selected IGS sites)
the history of the used equipment as it has been assumed for the reference frame
generation. A comparison with the igs.snx le constructed at the IGS Central
Bureau (IGSCB) from the site information les may be useful for a verication of
the history records.
COD/IGS :
Orbits, Earth orientation parmeters (EOP), and satellite clock corrections are ba-
sic external information for a GNSS analysis. The source of the les may be the
FTP server from CODE (ftp://ftp.unibe.ch/aiub/CODE or http://www.aiub.
unibe.ch/download/CODE/), or the Crustal Dynamics Data Information System
FTP server (e.g., for downloading GPSrelated IGS products ftp://cddis.gsfc.
nasa.gov/gnss/products and in ftp://cddis.gsfc.nasa.gov/glonass/products
for GLONASSrelated IGS products). The les are named with the GPS week and
the day of the week (apart from les containing information for the entire week, e.g.,
EOP, or the processing summaries).
The IGS provides GPS and GLONASS orbits only in separate les (IGS/IGLseries
from the nal product line) stemming from independent combination procedures
with dierent contributing analysis center (AC). Nevertheless, they are consistent
enough to merge both les together as the rst step of the processing. CODE
contributes fully combined multiGNSS solutions to the IGS nal (and ultrarapid)
product line.
BSW52 :
In this directory we have placed les containing external input information in
Bernesespecic formats. The les are neutral with respect to the data you are
going to process. Typical examples are ionosphere maps or dierential code bi-
ases (DCB) les. These les can be downloaded from http://www.aiub.unibe.ch/
download/CODE/ or http://www.aiub.unibe.ch/download/BSWUSER52/ areas.
REF52 :
Here we propose to collect les in Bernese format which are useful for several
campaigns (e.g., reference frame les: IGB08_R.CRD, IGB08_R.VEL). Typical ex-
amples are station coordinate, velocity, and information les (e.g., EXAMPLE.CRD,
EXAMPLE.VEL, EXAMPLE.STA, . . . , EPN.CRD). All stations of a project are contained
in one le but the processing of the projects data may be performed in dierent
campaigns.
MSC :
This directory contains example les for the automated processing with the BPE.
VMF1 :
The grids for the Vienna Mapping Function (VMF1) are located in a separate direc-
tory. The les can be downloaded from http://ggosatm.hg.tuwien.ac.at/DELAY/
GRID/VMFG/ . They are not used for the examples but it shall indicate that for other
types of les other directories may be created.
All les and metainformation related to the 13 stations selected for the example campaign
are already in this DATAPOOLarea (${D}) after installing the Bernese GNSS Software.
GNSS orbit information is available from CODE and IGS (directory ${D}/COD or ${D}/
IGS).
1.2.2 The CampaignDirectory Structure
Putting data from the DATAPOOL into the campaign
When running an automated processing using the BPE there is a script at the beginning
of the process which copies the data from the DATAPOOLarea into the campaign. If you
are going to process data manually you rst have to copy the necessary les into the
campaign and decompress them if necessary using standard utilities (uncompress, gunzip
1
,
or CRZ2RNX for RINEXles).
Content of the campaign area to process the example
All les needed to process the data according to this tutorial are already copied into the
campaign area. If you want to follow the example outside the Bernese Introductory Course
environment you have to put the following les at the correct places in the campaign
directory structure.
${P}/INTRO/ATM/ COD10207.ION COD10208.ION COD11205.ION COD11206.ION
${P}/INTRO/BPE/
${P}/INTRO/GRD/ VMF10207.GRD VMF10208.GRD VMF11205.GRD VMF11206.GRD
${P}/INTRO/OBS/
${P}/INTRO/ORB/ IGS15941.PRE IGS15942.PRE IGS16460.PRE IGS16461.PRE
IGL15941.PRE IGL15942.PRE IGL16460.PRE IGL16461.PRE
IGS15947.IEP IGS16467.IEP
COD15941.PRE COD15942.PRE COD16460.PRE COD16461.PRE
COD15947.IEP COD16467.IEP
P1C11007.DCB P1C11107.DCB
P1P21007.DCB P1P21107.DCB
${P}/INTRO/ORX/
${P}/INTRO/OUT/ IGS15941.CLK IGS15942.CLK IGS16460.CLK IGS16461.CLK
COD15941.CLK COD15942.CLK COD16460.CLK COD16461.CLK
${P}/INTRO/RAW/ GANP2070 .10O GANP2080 .10O GANP2050 .11O GANP2060 .11O
HERT2070 .10O HERT2080 .10O HERT2050 .11O HERT2060 .11O
JOZ22070 .10O JOZ22080 .10O JOZ22050 .11O JOZ22060 .11O
LAMA2070 .10O LAMA2080 .10O LAMA2050 .11O LAMA2060 .11O
MATE2070 .10O MATE2080 .10O MATE2050 .11O MATE2060 .11O
ONSA2070 .10O ONSA2080 .10O ONSA2050 .11O ONSA2060 .11O
PTBB2070 .10O PTBB2080 .10O PTBB2050 .11O PTBB2060 .11O
TLSE2070 .10O TLSE2080 .10O TLSE2050 .11O TLSE2060 .11O
WSRT2070 .10O WSRT2080 .10O WSRT2050 .11O WSRT2060 .11O
WTZR2070 .10O WTZR2080 .10O WTZR2050 .11O WTZR2060 .11O
WTZZ2070 .10O WTZZ2080 .10O WTZZ2050 .11O WTZZ2060 .11O
ZIM22070 .10O ZIM22080 .10O ZIM22050 .11O ZIM22060 .11O
ZIMM2070 .10O ZIMM2080 .10O ZIMM2050 .11O ZIMM2060 .11O
${P}/INTRO/SOL/
${P}/INTRO/STA/ EXAMPLE.CRD EXAMPLE.VEL EXAMPLE.STA EXAMPLE.ABB
EXAMPLE.BLQ EXAMPLE.ATL EXAMPLE.CLU EXAMPLE.PLD
IGB08_R.CRD IGB08_R.VEL IGB08.FIX IGB08.SIG
SESSIONS.SES
1
These tools are also available for WINDOWS-platforms, see www.gzip.org . Note, that gunzip can also
be used to uncompress UNIXcompressed les with the extension .Z .
Page 6 AIUB
The directory ${P}/INTRO/GEN/ contains copies of les from the ${X}/GEN directory, which
are used by the processing programs. If you want to view these les, please use those in your
campaign and not the ones in the ${X}/GEN directory to prevent potential interferences
with your colleagues.
${P}/INTRO/GEN/ CONST. DATUM. GPSUTC. POLOFF.
RECEIVER.
SATELLIT.I08 PCV.I08 I08.ATX
SAT_2010.CRX SAT_2011.CRX
IAU2000R06.NUT IERS2010XY.SUB OT_FES2004.TID TIDE2000.TPO
EGM2008_SMALL. s1_s2_def_ce.dat
SINEX. SINEX.PPP SINEX.RNX2SNX
IONEX. IONEX.PPP
1.2.3 Input Files for the Processing Examples
Atmosphere les ATM
The input les in this directory are global ionosphere models in the Bernese format ob-
tained from the IGS processing at CODE. They will be used to support the phase ambi-
guity resolution with the QIF strategy and to enable the higher order ionosphere (HOI)
corrections.
General les GEN
These general input les contain information that is neither user nor campaignspecic.
They are accessed by all users, and changes in these les will aect processing for everyone.
Consequently, these les are located in the ${X}/GEN directory. Table 1.3 shows the list
of general les necessary for the processing example. It also shows which les need to be
updated from time to time by downloading them from the anonymous ftpserver of AIUB
(http://www.aiub.unibe.ch/download/BSWUSER52/GEN).
Each Bernese processing program has its own panel for general les. Make sure that you
use the correct les listed in Table 1.3 .
Grid les GRD
In this directory the grid les *.GRD are collected. To apply for instance the VMF1 tro-
posphere model (a priori information from European Centre for Medium-Range Weather
Forecasts (ECMWF) and Vienna mapping function) you need a grid with the necessary
coecients.
Orbit les ORB
The precise orbits in the les *.PRE are usually the nal products from CODE analysis
center containing GPS and GLONASS orbits from a rigorous multiGNSS analysis. Alter-
natively also the combined nal products from the IGS can be used. They do not contain
orbits for the GLONASS satellites. The combined GLONASS satellite orbits from the IGS
are available in IGLles. Both precise orbit les need to be merged for a multiGNSS
analysis.The corresponding EOP are given in weekly les with the extension *.IEP (take
care on full consistency with the orbit product).
Furthermore, the directory contains monthly means for the DCB.
Table 1.3: List of general les to be used in the Bernese programs for the processing example.
Filename Content Modication Update from
CONST. All constants used in the
Bernese GNSS Software
No BSW aftp
DATUM. Denition of geodetic
datum
Introducing new reference
ellipsoid
BSW aftp
GPSUTC. Leap seconds When a new leap second is
announced by the IERS
BSW aftp
POLOFF. Pole oset coecients Introducing new values
from IERS annual report
(until 1997)
RECEIVER. Receiver information Introducing new receiver

type
BSW aftp
SATELLIT.I08 Satellite information le New launched satellites BSW aftp
PCV.I08 Phase center eccentricities
and variations
Introducing new antenna
corrections or new
antenna/radome
combinations
BSW aftp or
update with
ATX2PCV
SAT_$Y+0.CRX Satellite problems Satellite maneuvers, bad
data, ...
BSW aftp
IAU2000R06.NUT Nutation model
coecients
No
IERS2010XY.SUB Subdaily pole model
coecients
No
OT_FES2004.TID Ocean tides coecients No
TIDE2000.TPO Solid Earth tides
coecients
No
EGM2008_SMALL. Earth potential coecients No
(reduced version, sucient
for GNSS and LEO orbit
determination)
s1_s2_def_ce.
dat
S1/S2 atmospheric tidal
loading coecients
No
SINEX. SINEX header information Adapt SINEX header for
SINEX.TRO your institution
SINEX.PPP . . . for the PPP example
SINEX.RNX2SNX . . . for RNX2SNX example
IONEX. IONEX header
information
Adapt IONEX header for
your institution
IONEX.PPP . . . for the PPP example

Page 8 AIUB
Clock RINEX les OUT
The clock RINEX les are located in the OUTdirectory. They are consistent with
the GNSS orbits and EOP products in the ORBdirectory. They contain station and
satellite clock corrections with at least 5 minutes sampling there are also les from
the IGS or some of the ACs providing satellite clock corrections with a sampling of
30 seconds .
RINEX les RAW
The raw data are given in RINEX format. The observations *.$YO ($Y is the menu
time variable for the twodigit year of the current session) are used for all exam-
ples.
Station les STA
The coordinates and velocities of the stations given in the IGS realization of the reference
frame ITRF2008 are available in the les IGB08_R.CRD and IGB08_R.VEL . The IGS core
stations are listed in IGB08.FIX . This le will be used to dene the geodetic datum when
estimating station coordinates. You can browse all these les with a text editor or with
the menu ("Menu>Campaign>Edit station files").
For all stations that have unknown coordinates in the IGb08 reference frame a Precise
Point Positioning (PPP) using the example BPE (PPP_BAS.PCF) for day 207 of year 2010
has been executed. For our EXAMPLEproject a resulting coordinate le EXAMPLE.CRD has
been generated. It contains all IGS core sites (copied from le IGB08_R.CRD) and the
PPP results for the remaining stations. The epoch of the coordinates is January 01,
2005. The corresponding velocity le EXAMPLE.VEL contains the velocities for the core
sites (copied from le IGB08_R.VEL) completed by the NNRNUVEL1A velocities for the
other stations. The assignment of stations to tectonic plates is given in the le EXAMPLE.
PLD.
To make sure that you process the data in the Bernese GNSS Software with correct
station information (station name, receiver type, antenna type, antenna height, etc.) the
le EXAMPLE.STA is used to verify the RINEX header information. The reason to use this
le has to be seen in the context that some antenna heights or receiver/antenna types in
the RINEX les may not be correct or may be measured to a dierent antenna reference
point. Similarly, the marker (station) names in the RINEX les may dier from the names
we want to use in the processing. The antenna types have to correspond to those in the
le ${X}/GEN/PCV.I08 in order that the correct phase center osets and variations are
used. The receiver types have to be dened in the ${X}/GEN/RECEIVER. le to correctly
apply the DCB corrections.
For each station name unique four and twocharacter abbreviations to construct the
names for the Bernese observation les need to be dened in the le EXAMPLE.ABB . It was
automatically generated by the PPPexample BPE. If you want to process big networks,
the baselines need to be divided into clusters to speed up the processing. For that purpose
each station has to be assigned to a region by a cluster number in the le EXAMPLE.
CLU .
The last les to be mentioned in this directory are EXAMPLE.BLQ and EXAMPLE.ATL. They
respectively provide the coecients for the ocean and atmospheric tidal loading of the
stations. They should at least be applied in the nal run of GPSEST.
1.2.4 The SAVEDISK Directory Structure (${S})
Motivation for the SAVEDISK area
When processing GNSS data, a lot of les from various processing steps will populate
your campaign directories. The main result les from the data analysis should be col-
lected in the SAVEDISK area. This area is intended as longterm archive for your result
les.
Because the result les are stored in the SAVEDISK area, you can easily clean up your cam-
paign area without loosing important les. Please keep in mind that the computing perfor-
mance decreases if you have several thousands of les in a directory.
Structure and content of the SAVEDISK area
We propose to build subdirectories in the SAVEDISK area for each of your projects. If these
projects collect data over several years, yearly subdirectories are recommended. It is also
practical to use further subdirectories like ATM, ORB, OUT, SOL, STA to distribute the les
and to get shorter listings if you are looking for a le.
The SAVEDISK area contains after its installation a directory structure according to the
description above. Each example BPE is assumed as a project. Therefore, you will nd on
the top level of the SAVEDISK the directories PPP, RNX2SNX, CLKDET, LEOPOD, and SLRVAL
(related to the dierent example BPEs).
In each of these directories you will nd several les ending with _REF. They are gen-
erated by running the example BPEs on the system at Astronomical Institute of the
University of Bern (AIUB). Even if the objectives of this tutorial and of the RNX2SNX
example BPE are in both cases to process data from a regional network, the resuls must
not be identical since there are some dierences in the processing strategies and selected
options.
Page 10 AIUB
2 Terminal Session: Monday
Todays terminal session is to:
1. become familiar with the UNIX environment, the menu of the Bernese GNSS
Software, and the example campaign,
2. verify the campaign setup done for you (see sections 2.2 and 2.3, and also
the handout for the terminal sessions),
3. generate the a priori coordinates for all 4 days using COOVEL (see Section
2.5), and
4. start to prepare pole and orbit information according to chapter 3.
2.1 Start the Menu
Start the menu program using the command G
1
.
Navigate through the submenus to become familiar with the structure of the menu. Read
the general help (available at "Menu>Help>General") to get an overview on the usage of the
menu program of the Bernese GNSS Software.
For the terminal session in the Bernese Introductory Course, the campaign setup has
already been done for each user. Please check that the campaign name in the statusbar
of the Bernese Menu is set correctly to your campaign (i.e., Campaign ${P}/INTRO) and
that the current session is set to the rst session (i.e., $Y+0=2010, $S+0=2070). If this
is not the case, please contact the sta in the Terminal room.
2.2 Select Current Session
Select "Menu>Campaign>Edit session table" to check the session table. It is recommended to use
the wildcard string ???0 for the List of sessions in panel SESSION TABLE. The panel below
shows the session denition for a typical permanent campaign with 24-hours sessions. The
setup of the session table is a very important task when you prepare a campaign. Please
read the corresponding online help carefully.
1
At the exercise terminals the Bernese environment is loaded automatically during the login. At home
you have to source the le ${X}/EXE/LOADGPS.setvar on UNIXplatforms either manually or during
the login.
Page 11
Save the session table (press the Save button) and open the Date Selection Dia-
log in the "Menu>Configure>Set session/compute date" in order to dene the current ses-
sion:
2.3 Campaign Setup
Usually, a new campaign must be added to the campaign list ("Menu>Campaign>Edit list of
campaigns") rst and select it as the active campaign ("Menu>Campaign>Select active campaign"),
before the directory structure can be created ("Menu>Campaign>Create new campaign"). In the
Bernese Introductory Course environment this should already have been done for your
campaign, but please verify that.
In the Bernese Introductory Course environment the selected campaign should be ${P}/
INTRO . In order to become familiar with the campaign structure, you can inspect your
campaign directory and inspect the contents using the command line (using cd for chang-
ing directories and ls to create directory listings) or using a lemanager (e.g., midnight
commander mc).
2.4 Menu Variables
When processing GNSS data, it is often necessary to repeat a program run several times
with only slightly dierent option settings. A typical example would be the processing
of several sessions of data. The names of observation les change from session to ses-
sion because the session number is typically a part of the lename. It would be very
cumbersome to repeat all the runs selecting the correct les manually every time. For
the BPE an automation is mandatory. For such cases the Bernese menu system pro-
vides a powerful tool: the socalled menu variables. The menu variables are dened in
the userspecic menu input le ${U}/PAN/MENU_VAR.INP that is accessible through "Menu
Page 12 AIUB
2.4 Menu Variables
>Configure>Menu variables". Three kinds of menu variables are available: predened variables
(also called menu time variables), userdened variables, and system environment vari-
ables.
The use of system environment variables is necessary to generate the complete path to
the les used in the Bernese GNSS Software. The campaign data are located in the
directory ${P}/INTRO=${HOME}/GPSDATA/INTRO. The userdependent les can be found
at ${U}=${HOME}/GPSUSER52 note that ${HOME} may have been already translated into
the name of your homedirectory. The temporary user les are saved in ${T}=/scratch/
local/bern52. Finally, the campaignindependent les reside in ${X}=/home/bswadmin/
BERN52/GPS.
The predened variables provide a set of time strings assigned to the current session. From
the second panel of the menu variables you get an overview on the available variables and
their usage:
Be aware that the variable $S+1 refers to the next session. Because we are using a session
table for daily processing it also corresponds to the next day.
These variables are automatically translated by the menu upon saving the panel or running
the program. We recommend to make use of them in the input panels (e.g. for lename
specication).
2.5 Generate A Priori Coordinates
As stated before the a priori coordinates generated from the PPP processing example BPE
refer to the epoch January 01, 2005 . The rst step is to extrapolate the coordinates to the
epoch that is currently processed. This is the task of the program COOVEL. Open the pro-
gram input panel in "Menu>Service>Coordinate tools>Extrapolate coordinates":
Reference epoch: date $YMD_STR+0 2010 07 26
Output coordinate le APR$YD+0 APR10207
Title line Session $YSS+0: Session 102070:
Start the program with the Runbutton. The program generates an output le COOVEL.
L?? in the directory ${P}/INTRO/OUT. This le may be browsed using the Outputbutton
or with "Menu>Service>Browse program output" . It should look like
===============================================================================
Bernese GNSS Software , Version 5.2
-------------------------------------------------------------------------------
Program : COOVEL
Purpose : Extrapolate coordinates
-------------------------------------------------------------------------------
Campaign : ${P}/INTRO
Default session: 2070 year 2010
Date : 20-Aug -2014 14:35:37
User name : bern52
===============================================================================
EXAMPLE: Session 102070: Coordinate propagation
-------------------------------------------------------------------------------
Page 14 AIUB
2.5 Generate A Priori Coordinates
INPUT AND OUTPUT FILENAMES
--------------------------
-------------------------------------------------------------------------------
Input coordinate file : ${P}/INTRO/STA/EXAMPLE.CRD
Input velocity file : ${P}/INTRO/STA/EXAMPLE.VEL
Output coordinate file : ${P}/INTRO/STA/APR10207.CRD
Program output : ${P}/INTRO/OUT/COOVEL.L00
Error message : ${U}/WORK/ERROR.MSG
Session table : ${P}/INTRO/STA/SESSIONS.SES
-------------------------------------------------------------------------------
REFERENCE EPOCH: 2005 -01 -01 00:00:00
INTERPOLATION FACTOR: -5.563312799452429
NO 15 -VELOCITY: ASPA %50503 S006
NO 49 -VELOCITY: CONZ %41719 M002
NO 153 -VELOCITY: MQZG %50214 M001
NO 156 -VELOCITY: MTKA %21741 S002
NO 207 -VELOCITY: SANT %41705 M003
NO 243 -VELOCITY: TSKB %21730 S005
-----------------------------------------------------------------
>>> CPU/Real time for pgm "COOVEL": 0:00:00.009 / 0:00:00.009
>>> Program finished successfully
The header area of the program output is standardized for all programs of the Bernese
GNSS Software, Version 5.2 . Furthermore each program has a title line that should
characterize the program run. It is printed to the program output and to most of the
result les. Many program output les furthermore provide a list of input and output les
that have been used or generated.
The last two lines of the above example appear also in each program output of the Bernese
GNSS Software, Version 5.2 . It reports the processing time and the status successful or
with error.
There are a number of stations with coordinates but no velocities (indicated in the program
output as NO 15 -VELOCITY: ASPA%50503S006). The coordinates cannot be used as
ducial point for datum denition mostly because of earthquake events. We have none of
these stations in our example.
The result of the run of COOVEL is an a priori coordinate le (${P}/INTRO/STA/APR10207.
CRD) containing the positions of the sites to be processed for the epoch of the current session
(the lines for the other stations are ignored in the processing):
EXAMPLE: Session 102070: Coordinate propagation
--------------------------------------------------------------------------------
LOCAL GEODETIC DATUM: IGb08 EPOCH: 2010 -07 -26 00:00:00
NUM STATION NAME X (M) Y (M) Z (M) FLAG
71 GANP 11515 M001 3929181.41960 1455236.82354 4793653.94456 P
89 HERT 13212 M010 4033460.85011 23537.89173 4924318.31616 I
106 JOZ2 12204 M002 3664880.47637 1409190.67771 5009618.53053 I
123 LAMA 12209 M001 3524522.83219 1329693.71146 5129846.40491 P
136 MATE 12734 M008 4641949.45506 1393045.52839 4133287.55041 I
174 ONSA 10402 M004 3370658.46283 711877.21896 5349787.00996 I
193 PTBB 14234 M001 3844059.87356 709661.40870 5023129.60550 P
236 TLSE 10003 M009 4627851.76560 119640.12481 4372993.62094 I
258 WSRT 13506 M005 3828735.77808 443305.04589 5064884.76561 I
259 WTZR 14201 M010 4075580.45801 931853.89288 4801568.18631 I
260 WTZZ 14201 M014 4075579.32680 931853.20354 4801569.09338 P
270 ZIM2 14001 M008 4331299.79229 567537.42322 4633133.79466 P
272 ZIMM 14001 M004 4331296.98900 567555.97843 4633134.00316 I
Repeat this step for the other three sessions of the example by changing the current
session using the +Day or -Day to change a limited number of days (not sessions) or via
"Menu>Configure>Set session/compute date" . You can then use the Rerun button to restart the
program. No options need to be changed because of the consequent use of the menu time
variables was made.
2.6 Session Goals
At the end of this session, you should have created the following les:
1. a priori coordinates in your campaigns STA directory: les APR10207. CRD ,
APR10208. CRD , ...
These les must be generated for all four days (days 207 and 208 of year
2010 and days 205 and 206 of year 2011).
Until the end of the Mondays terminal session you should start with preparing
the pole and orbit information, see Chapter 3 .
Page 16 AIUB
3 Terminal Session: Pole and Orbit
Preparation (Monday/Tuesday)
The terminal session on pole and orbit preparation is to:
1. generate the pole information le in the Bernese format (POLUPD)
2. generate tabular orbit les from CODE precise les (PRETAB)
3. generate the Bernese standard orbit les (ORBGEN)
You should start with these tasks during the Mondays terminal sessions and nish
the processing during the terminal session on Tuesday.
Introductory Remark
We recommend to use the nal or preprocessed products from CODE because they con-
tain consistent orbits for GPS and GLONASS. They also include all active GNSS satel-
lites (even if they are unhealthy or during GPS satellite repositioning events) with the
highest possible accuracy thanks to threeday longarc technology. Due to this choice
you will get the best possible consistency between the external products and the soft-
ware.
You may alternativly use the products from IGS. Seperate product les for GPS and
GLONASS orbits exist from independent combination procedures that rst need to be
merged for a multiGNSS processing. For most of the applications, merging the precise
orbit les is sucient a tutorial on the procedure is given in Sect. 7.1 of this book.
On the other hand, the consistency of the orbits can not be as good as that of CODE (or
other analysis center) following the strategy of the rigorous combined processing of GPS
and GLONASS measurements for orbit determination.
3.1 Prepare Pole Information
Together with the precise orbit les (PRE), a consistent set of Earth orientation information
is provided in the ORB directory. Whereas the orbits are given in daily les the EOP are
available in weekly les for the nal product series from the CODE analysis center. We
have to convert the information from the International Earth Rotation and Reference
Systems Service (IERS)/IGS standard format (le extension within the Bernese GNSS
Software is IEP) into the internal Bernese EOP format (le extension within the Bernese
GNSS Software is ERP). This is the task of the program POLUPD ("Menu>Orbits/EOP>Handle
EOP files>Convert IERS to Bernese Format") which is also able to update the EOP records of an
existing le.
Page 17
3 Terminal Session: Pole and Orbit Preparation
Page 18 AIUB
3.2 Generate Orbit Files
The last panel for the program POLUPD is an example for the specication of time windows
in the Bernese GNSS Software, Version 5.2 . Time windows can be dened by sessions
(a single session or a range of sessions). Alternatively, a time window may be specied
by a start and an end epoch. By entering either a start or an end epoch you may dene
only the beginning or the end of the time interval. We refer to the online help for more
details.
The messages
### PG POLUPD: NUTATION MODEL NAME NOT EQUAL DEFAULT
DEFAULT NUTATION MODEL NAME : IAU2000R06
NUTATION MODEL NAME IN FILE : IAU2000
### PG POLUPD: SUBDAILY POLE MODEL NAME NOT EQUAL DEFAULT
DEFAULT SUBDAILY POLE MODEL NAME : IERS2010
SUBDAILY POLE MODEL NAME IN FILE : IERS2000
just inform that you have selected the most recent nutation and subdaily pole model
whereas the operational solution at CODE was computed using an older model at that
time.
If you do not want to accept this inconsistency you may alternatively use the results
from a reprocessing eort (e.g., http://www.aiub.unibe.ch/download/REPRO_2013/
CODE/).
In this processing example we use only two programs of the orbit part of the Bernese
GNSS Software. The rst program is called PRETAB and may be accessed using "Menu
>Orbits/EOP>Create tabular orbits". The main task of PRETAB is to create tabular orbit les
(TAB) (i.e., to transform the precise orbits from the terrestrial into the celestial reference
frame) and to generate a satellite clock le (CLK). The clock le will be needed, e.g.,
in a program CODSPP (see Section 4.2.1, to be discussed in the Tuesdays lectures on
pre-processing).
You have to apply the same subdaily pole and nutation models as you have used before
when you have generated the Bernese formatted pole le (IGS$YD+0.ERP).
If you process precise orbits from CODE it is generally not necessary to remove bad
satellites. It might become necessary for orbit products from other sources (e.g., from the
IGS). Because CODE introduces the correct accuracy code for all its satellites the above
settings do not harm the import of satellite orbits from CODE.
Panel PRETAB 3: Options for Clocks contains the options for extracting the satellite clock
information. The clock values in the precise orbit le are sampled to 15 min. We interpo-
late with a Polynomial degree of 2 with an Interval for polynomials of 12 hours. This is good
enough for the receiver clock synchronization in CODSPP.
A message like this is expected:
### PG PRETAB: SATELLITE CLOCK VALUES MISSING
SATELLITE : 101
FILE NUMBER: 1
FILE NAME : ${P}/INTRO/ORB/COD15941.PRE
Page 20 AIUB
SATELLITE : 102
FILE NUMBER: 1
FILE NAME : ${P}/INTRO/ORB/COD15941.PRE
...
It indicates that the precise orbit les do not contain clock corrections for the
GLONASS satellites (GLONASS satellite are indicated with satellite number between
100 and 199 within the Bernese GNSS Software). Consequently the synchroniza-
tion of the receiver clocks in CODSPP will only be done based on the GPS satellite
clocks.
The second program of the orbit part used here is called ORBGEN ("Menu>Orbits/EOP
>Create/update standard orbits"). It prepares the socalled standard orbits using the satellite
positions in the tabular orbit les as pseudoobservations for a leastsquares adjust-
ment.
Make sure that the ERP le, the nutation, and the subdaily pole model are the same you
have used in PRETAB. It is mandatory to consistently use this triplet of les together with
the generated standard orbits for all processing programs (otherwise a warning message is
issued).
Page 22 AIUB
The program produces an output le ORB10207.OUT (or corresponding to the other ses-
sions) which should look like
...
INPUT AND OUTPUT FILENAMES
--------------------------
-------------------------------------------------------------------------------
General constants : ${X}/GEN/CONST.
Correction GPS -UTC : ${X}/GEN/GPSUTC.
Planetary ephemeris file : ${X}/GEN/DE405.EPH
Coeff. of Earth potential : ${X}/GEN/EGM2008_SMALL.
Solid Earth tides file : ${X}/GEN/TIDE2000.TPO
Ocean tides file : ${X}/GEN/OT_FES2004.TID
Satellite problems : ${X}/GEN/SAT_2010.CRX
Satellite information : ${X}/GEN/SATELLIT.I08
Nutation model : ${X}/GEN/IAU2000R06.NUT
Subdaily pole model : ${X}/GEN/IERS2010XY.SUB
Pole file : ${P}/INTRO/ORB/COD10207.ERP
Ocean loading corrections : ${P}/INTRO/STA/EXAMPLE.BLQ
Atmospheric loading corrections : ${P}/INTRO/STA/EXAMPLE.ATL
Orbital elements , file 1 : ---
Orbital elements , file 2 : ---
Standard orbits : ${P}/INTRO/ORB/COD10207.STD
Radiation pressure coeff. : ---
Summary file : ---
Summary file for IGS -ACC : ${P}/INTRO/OUT/ORB10207.LST
Residual plot file : ---
Residual file : ---
Program output : ${P}/INTRO/OUT/ORB10207.OUT
Error message : ${U}/WORK/ERROR.MSG
Scratch file : ${U}/WORK/ORBGEN.SCR
Scratch file : ${U}/WORK/ORBGEN.SC2
Session table : ${P}/INTRO/STA/SESSIONS.SES
-------------------------------------------------------------------------------
...
...
-------------------------------------------------------------------------------
RMS ERRORS AND MAX. RESIDUALS ARC NUMBER: 1 ITERATION: 4
-------------------------------------------------------------------------------
QUADRATIC MEAN OF O-C (M) MAX. RESIDUALS (M)
SAT #POS RMS (M) TOTAL RADIAL ALONG OUT RADIAL ALONG OUT
--- ---- ------- ----------------------------- --------------------
1 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.002
2 96 0.001 0.001 0.000 0.001 0.001 0.001 0.002 0.002
3 96 0.001 0.001 0.001 0.001 0.001 0.003 0.003 0.002
4 96 0.001 0.001 0.001 0.001 0.001 0.001 0.002 0.002
5 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.003
6 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.002
7 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.003
8 96 0.001 0.001 0.001 0.001 0.001 0.003 0.003 0.003
9 96 0.001 0.001 0.001 0.001 0.001 0.002 0.004 0.002
10 96 0.001 0.001 0.001 0.001 0.001 0.001 0.002 0.002
11 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.002
12 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.002
13 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.002
...
28 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.002
29 96 0.001 0.001 0.001 0.001 0.001 0.002 0.002 0.001
30 96 0.001 0.001 0.001 0.001 0.001 0.003 0.003 0.002
31 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.002
32 96 0.001 0.001 0.001 0.001 0.001 0.003 0.003 0.002
101 96 0.001 0.001 0.001 0.001 0.001 0.002 0.002 0.002
102 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.003
103 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.002
104 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.003
105 96 0.001 0.001 0.001 0.001 0.001 0.001 0.003 0.002
107 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.002
...
121 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.002
122 96 0.001 0.001 0.001 0.001 0.001 0.002 0.003 0.002
123 96 0.001 0.001 0.001 0.001 0.001 0.001 0.002 0.002
124 96 0.001 0.001 0.001 0.001 0.001 0.001 0.003 0.002
-------------------------------------------------------------------------------
...
The most important information in the output le are the RMS errors for each satel-
lite. These should be 1 mm (for older orbits it may also achieve 3. . . 5 mm) if pre-
cise orbits from CODE were used together with the consistent EOP information (the
actual RMS errors depend on the quality of the precise orbits, on the pole le used
for the transformation between IERS Terrestrial Reference Frame (ITRF) and Interna-
tional Celestial Reference Frame (ICRF) in PRETAB, and on the orbit model used in
ORBGEN).
Comparing the RMS error from the third and the fourth iteration you will see that three
iterations should already be enough to produce precise standard orbits for GNSS satel-
lites.
The le ${P}/INTRO/OUT/ORB10207.LST summarizes the orbit t RMS values in one table:
EXAMPLE: Session 102070: Standard orbit generation 20-AUG -14 15:57
TIME FROM DAY : 1 GPS WEEK: 1594
TO DAY : 2 GPS WEEK: 1594
-------------------------------------------------------------------------------
ORBIT REPEATABILITY FROM A 1-DAY FIT THROUGH DAILY ORBIT SOLUTIONS (MM)
# ECLIPSING SATELLITES: 5 E / 0 M ( 0 EM)
----------------------------- ... ---------------------- ... ---------------------------- ...
ECL .. .. .. .. .. .. .. E. E. E. .. .. .. .. .. .. .. ..
DOY 1 2 3 4 5 6 ... 12 13 14 15 16 ... 32 101 102 103 104 105 107 ...
----------------------------- ... ---------------------- ... ---------------------------- ...
207 1 1 1 1 1 1 ... 1 1 1 1 1 ... 1 1 1 1 1 1 1 ...
----------------------------- ... ---------------------- ... ---------------------------- ...
ALL 1 1 1 1 1 1 ... 1 1 1 1 1 ... 1 1 1 1 1 1 1 ...
----------------------------- ... ---------------------- ... ---------------------------- ...
The output shows that 5 satellites are in eclipse (indicated above the satellite number by
E for Earth or M for Moon).
Page 24 AIUB
3.3 Session Goals
The similar le may be generated using the orbit products from IGS (including the EOP
information) following the procedure described in Section 7.1 . As you can notice the RMS
errors are slightly higher. It does not mean that the orbits from CODE are better than
the IGS orbits. The orbit model in ORBGEN is only more consistent with the orbit model
used at CODE:
-------------------------------------------------------------------------------
----------------------------- ... ---------------------- ... ----
ECL .. .. .. .. .. .. .. E. E. E. .. ..
DOY 1 2 3 4 5 6 ... 12 13 14 15 16 ... 32
----------------------------- ... ---------------------- ... ----
207 2 1 4 1 2 3 ... 3 3 3 2 3 ... 2
----------------------------- ... ---------------------- ... ----
ALL 2 1 4 1 2 3 ... 3 3 3 2 3 ... 2
----------------------------- ... ---------------------- ... ----
(Note the missing GLONASS satellites in the IGS orbit product.)
In the example for day 208 of year 2010 a satellite 75 appears. The GPSsatellite 25 had
a repositioning event at 20100727 16:08:03 (see ${X}/GEN/SAT_2010.CRX). The satellite
is introduced in the processing with two independent arcs: one before (number 25) and
one after (number 75) the event (you may verify this by the number of epochs available
for each of these two satellite arcs).
3.3 Session Goals
At the end of this session, you should have created the following les:
1. Bernese pole le in the campaigns ORB directory: COD10207. ERP ,
2. Bernese standard orbit le in the ORB directory: COD10207. STD ,
3. Bernese satellite clock le in the ORB directory: COD10207. CLK .
Page 26 AIUB
4 Terminal Session: Tuesday
1. import the observations from the RINEX format into the Bernese format
for all four days of the example using RXOBV3 (section 4.1).
2. preprocess the Bernese observation les:
receiver clock synchronization (CODSPP, section 4.2.1)
baseline generation (SNGDIF, section 4.2.2)
preprocess baselines (MAUPRP, section 4.2.3)
4.1 Importing the Observations
The campaign has now been set up and all necessary les are available. The rst part
of processing consists of the transfer of the observations from RINEX to Bernese (bi-
nary) format. To get an overview of the data availability you may generate a pseudo-
graphic from the RINEX observation les using the program RNXGRA in "Menu>RINEX
>RINEX utilities>Create observation statistics" this step is not mandatory but it may be use-
ful to get an impression of the tracking performance of the stations before you start the
analysis.
Importing the RINEX observation les is the task of the program RXOBV3 in "Menu>RINEX
>Import RINEX to Bernese format>Observation les" (we do not use the RINEX navigation les for
this processing example).
All RINEX observation les tting the pattern ${P}/INTRO/RAW/????2070.10O are se-
lected automatically by the current entry in the input eld original RINEX observation les.
Page 27
You can verify this by pressing the button just right from this input eld (labeled with the
le extension 10O). In the le selection dialog you will nd the list of currently selected
les. The RINEX les of the year 2011 are shown if a current session from the year 2011
is selected. In that case the label of the button changes to 11O.
The next panel species the general input les. There are three further panels dening the
input options for RXOBV3. They allow to select the data to be imported and to specify a
few parameters for the Bernese observation header les.
We select GPS/GLO for the option Satellite system to be considered to exclude observations
from GNSS where no orbits are available.
Page 28 AIUB
4.1 Importing the Observations
Two more panels provide options to verify the RINEX header information:
Start the program with the Runbutton.
A warning message may appear to inform you that the observations for the GLONASS
satellite R09 (satellite system R for GLONASS in RINEX whereas satellite numbers
between 100 and 199 are in use within the Bernese GNSS Software) are removed be-
cause of an entry in the Satellite problems le provided in panel RXOBV3 1.1: General
Files.
### SR SAVMEA: PROBLEM FOR SATELLITE: 109
INDICATED IN SATCRUX : ${X}/GEN/SAT_2010.CRX
PROBLEM : BAD PHASE+CODE
REQUESTED ACTION : OBS. REMOVED
TIME WINDOW : 2008 -05 -14 00:00:00 2010 -09 -30 23:59:59
IN RINEX FILE : ${P}/INTRO/RAW/GANP2070 .10O
Messages on SR R2RDOH: TOO MANY COMMENT LINES may appear for some RINEX
les but they are not critical.
The program produces an output le RXO10207.OUT in the directory ${P}/INTRO/OUT
(resp. corresponding lenames for the other sessions). This le may be browsed using
the Output button or with "Menu>Service>Browse program output" . After echoing the input
options, the le provides an overview of the station information records in the RINEX
observation le header and the values that are used for the processing in the Bernese
GNSS Software. In addition some observation statistics are available. In the last section
you may check the completeness of the Bernese observation les by the available number
of epochs:
...
TABLE OF INPUT AND OUTPUT FILE NAMES:
------------------------------------
#satell.
Num Rinex file name Bernese code header file name #epo ... GPS GLO
Bernese code observ. file name
Bernese phase header file name #epo ... GPS GLO
Bernese phase observ. file name
---------------------------------------------------------------------------------------------
1 ${P}/INTRO/RAW/GANP2070 .10O ${P}/INTRO/OBS/GANP2070.CZH 2880 ... 30 20
${P}/INTRO/OBS/GANP2070.CZO
${P}/INTRO/OBS/GANP2070.PZH 2880 ... 30 20
${P}/INTRO/OBS/GANP2070.PZO
2 ${P}/INTRO/RAW/HERT2070 .10O ${P}/INTRO/OBS/HERT2070.CZH 2880 ... 31 20
${P}/INTRO/OBS/HERT2070.CZO
${P}/INTRO/OBS/HERT2070.PZH 2880 ... 31 20
${P}/INTRO/OBS/HERT2070.PZO
3 ${P}/INTRO/RAW/JOZ22070 .10O ${P}/INTRO/OBS/JOZ22070.CZH 2880 ... 30 20
${P}/INTRO/OBS/JOZ22070.CZO
${P}/INTRO/OBS/JOZ22070.PZH 2880 ... 30 20
${P}/INTRO/OBS/JOZ22070.PZO
...
11 ${P}/INTRO/RAW/WTZZ2070 .10O ${P}/INTRO/OBS/WTZZ2070.CZH 2880 ... 32 20
${P}/INTRO/OBS/WTZZ2070.CZO
${P}/INTRO/OBS/WTZZ2070.PZH 2880 ... 32 20
${P}/INTRO/OBS/WTZZ2070.PZO
12 ${P}/INTRO/RAW/ZIM22070 .10O ${P}/INTRO/OBS/ZIM22070.CZH 2879 ... 32 20
${P}/INTRO/OBS/ZIM22070.CZO
${P}/INTRO/OBS/ZIM22070.PZH 2879 ... 32 20
${P}/INTRO/OBS/ZIM22070.PZO
13 ${P}/INTRO/RAW/ZIMM2070 .10O ${P}/INTRO/OBS/ZIMM2070.CZH 2879 ... 31 0
${P}/INTRO/OBS/ZIMM2070.CZO
${P}/INTRO/OBS/ZIMM2070.PZH 2879 ... 31 0
${P}/INTRO/OBS/ZIMM2070.PZO
-----------------------------------------------------------------
>>> CPU/Real time for pgm "RXOBV3": 0:00:20.394 / 0:00:20.423
If epochs or satellites are missing for some RINEX les you may check this with the
RINEX observation graphic from the program RNXGRA. In July 2010 32 GPS and
20 GLONASS satellites were active, where one of the GPS satellites (PRN01) was un-
healthy. For that reason many of the stations did track only 31 out of 32 GPS satel-
lites.
Page 30 AIUB
4.2 Data Preprocessing (I)
4.2.1 Receiver Clock Synchronization
Now we are ready to invoke the processing part of the Bernese GNSS Software. We
have to run three programs for this example. The rst program is called CODSPP ("Menu
>Processing>Code-based clock synchronization". Its main task is to compute the receiver clock cor-
rections.
We already have geocentric coordinates of good quality available for the sites from the
PPP example BPE. Therefore, the option Estimate coordinates may be set to NO. The
most important option for this CODSPP run is Save clock estimates. It has to be set to
BOTH.
The warning messages issued by the program CODSPP remind that only GPS satellite clock
corrections have been extracted from the precise orbit les. Consequently, the receiver
clocks are synchronized with respect to the GPS system time.
Page 32 AIUB
CODSPP produces the following output:
...
STATION: GANP 11515 M001 FILE: ${P}/INTRO/OBS/GANP2070.CZO RECEIVER UNIT: 999999
-------------------------------------------------------------------------------------------
DAY OF YEAR : 207
FROM TO
OBSERVATIONS : 2010 -07 -26 00:00: 0.00 2010 -07 -26 23:59:30.00
REQUESTED WINDOW : -- --
MEASUREMENT INTERVAL: 30 SEC
SAMPLING RATE : 1
PROCESSED FREQUENCY : L3
ELEVATION LIMIT : 3 DEG
TROPOSPHERE IONOSPHERE
ATMOSPHERE MODELS : GMF NONE
STATISTICS FOR GPS SATELLITES:
------------------------------
SATELLITE NUMBER : 2 3 4 5 6 7 8 9 10 11 ... TOTAL
OBSERVATIONS IN FILE: 1015 910 1019 1029 838 914 841 832 971 857 ... 27074
BAD OBSERVATIONS (%): 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 ... 0.0
RMS ERROR (M) : 0.9 1.1 0.9 1.0 1.0 1.0 1.0 1.2 1.2 0.9 ... 1.0
STATISTICS FOR GLONASS SATELLITES:
----------------------------------
SATELLITE NUMBER : 101 102 103 104 105 107 108 110 111 113 ... TOTAL
OBSERVATIONS IN FILE: 905 932 935 929 1149 1097 905 1005 991 903 ... 19977
BAD OBSERVATIONS (%): 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0 100.0 ... 100.0
RMS ERROR (M) : 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 ... 0.0
RESULTS:
--------
OBSERVATIONS IN FILE: 47051
BAD OBSERVATIONS : 42.46 %
RMS OF UNIT WEIGHT : 1.07 M
NUMBER OF ITERATIONS: 2
...
You see in this statistic that the GLONASS measurements have not been used (because
of the missing GLONASS satellite clock corrections). This is also reected in the high
number of BAD OBSERVATIONS of 42.46% in that case.
...
STATION COORDINATES:
--------------------
LOCAL GEODETIC DATUM: IGb08
A PRIORI NEW NEW - A PRIORI RMS ERROR
GANP 11515 M001 X 3929181.42 3929181.42 0.00 0.00
(MARKER) Y 1455236.82 1455236.82 0.00 0.00
Z 4793653.94 4793653.94 0.00 0.00
HEIGHT 746.01 746.01 0.00 0.00
LATITUDE 49 2 4.971 49 2 4.971 0 0 0.000 0.0000
LONGITUDE 20 19 22.575 20 19 22.575 0 0 0.000 0.0000
CLOCK PARAMETERS:
-----------------
OFFSET FOR REFERENCE EPOCH: -0.000000021 SEC
GPS/GLONASS SYSTEM DIFFERENCE: OFFSET : 0.00 NSEC
RMS ERROR : 0.00 NSEC
CLOCK OFFSETS STORED IN CODE+PHASE OBSERVATION FILES
...
...
*******************************************************************************
SUMMARY OF BAD OBSERVATIONS
*******************************************************************************
MAXIMUM RESIDUAL DIFFERENCE ALLOWED : 30.00 M
CONFIDENCE INTERVAL OF F*SIGMA WITH F: 5.00
NUMBER OF BAD OBSERVATION PIECES : 3
NUMB FIL STATION TYP SAT FROM TO #EPO
-------------------------------------------------------------------------------
1 8 TLSE 10003 M009 OUT 1 10-07-26 15:10:00 10-07-26 15:28:30 38
2 8 TLSE 10003 M009 OUT 1 10-07-26 15:32:30 10-07-26 15:33:00 2
3 12 ZIM2 14001 M008 OUT 26 10-07-26 20:08:30 10-07-26 20:08:30 1
-------------------------------------------------------------------------------
*******************************************************************************
GLONASS/GPS TIME OFFSETS
*******************************************************************************
FILE STATION NAME TIME OFFSET (NS) RMS ERROR (NS)
-----------------------------------------------------------
1 GANP 11515 M001 NO RESULTS AVAILABLE
2 HERT 13212 M010 NO RESULTS AVAILABLE
3 JOZ2 12204 M002 NO RESULTS AVAILABLE
4 LAMA 12209 M001 NO RESULTS AVAILABLE
5 MATE 12734 M008 NO RESULTS AVAILABLE
6 ONSA 10402 M004 NO RESULTS AVAILABLE
7 PTBB 14234 M001 NO RESULTS AVAILABLE
8 TLSE 10003 M009 NO RESULTS AVAILABLE
9 WSRT 13506 M005 NO RESULTS AVAILABLE
10 WTZR 14201 M010 NO RESULTS AVAILABLE
11 WTZZ 14201 M014 NO RESULTS AVAILABLE
12 ZIM2 14001 M008 NO RESULTS AVAILABLE
13 ZIMM 14001 M004 NO RESULTS AVAILABLE
-----------------------------------------------------------
0 TOTAL 0.000 0.000
-----------------------------------------------------------
The most important message in the output le is CLOCK OFFSETS STORED IN
CODE+PHASE OBSERVATION FILES. This indicates that the receiver clock corrections
computed by CODSPP are stored in code and phase observation les. After this step we
will no longer use the code observations in this example.
The a posteriori RMS error (for each zero dierence le processed) should be checked in the
CODSPP output le. A value of about 2030 m is normal if Selective Availability (SA)
articial degradation of the satellite clock accuracy is on (before May 2000). Without
SA a value of about 3 m is expected if Pcode measurements are available (this is the case
for the time interval of the processing example). However, much worse code measurements
would still be suciently accurate to compute the receiver clock corrections with the
necessary accuracy of 1 s .
In the section GLONASS/GPS TIME OFFSETS you may only nd the intersystem bias
(ISB) for each of the receivers as they have been estimated by CODSPP if both, GPS and
GLONASS satellite clock corrections were introduced.
Page 34 AIUB
You may use the extraction program CODXTR ("Menu>Processing>Program output extraction>Code-
based clock synchronization") to generate a short summary from the CODSPP program output:
...
-------------------------------------------------------------------------------
File Input files
-------------------------------------------------------------------------------
1 ${P}/INTRO/OUT/COD10207.OUT
-------------------------------------------------------------------------------
13 FILES , MAX. RMS: 2.12 M FOR STATION: PTBB 14234 M001
MAX. BAD: 43.86 % FOR STATION: JOZ2 12204 M002
-----------------------------------------------------------------
>>> CPU/Real time for pgm "CODXTR": 0:00:00.007 / 0:00:00.007
4.2.2 Form Baselines
The second preprocessing program is called SNGDIF and may be activated in "Menu
>Processing>Create baseline les". SNGDIF creates the single dierences and stores them into
les. We use the strategy OBS-MAX for PHASE observation les.
To enter GPS in option Stations must contain observ. from a GNSS requires that each
station included in the baseline creation provides at least GPS measurements. This
option can be used to exclude those datasets containing only GLONASS observa-
tions.
Page 36 AIUB
The output of SNGDIF simply echoes the zero dierence les used and the single dierence
les created. The rst table conrms that all stations provide at least data from GPS.
For that reason all stations are included in the baseline creation.
...
NUM HEADER FILE NAMES STATION NAME #SAT SYS REMARK
-------------------------------------------------------------------------------
1 ${P}/INTRO/OBS/GANP2070.PZH GANP 11515 M001 50 GR included
2 ${P}/INTRO/OBS/HERT2070.PZH HERT 13212 M010 51 GR included
3 ${P}/INTRO/OBS/JOZ22070.PZH JOZ2 12204 M002 50 GR included
4 ${P}/INTRO/OBS/LAMA2070.PZH LAMA 12209 M001 50 GR included
5 ${P}/INTRO/OBS/MATE2070.PZH MATE 12734 M008 51 GR included
6 ${P}/INTRO/OBS/ONSA2070.PZH ONSA 10402 M004 50 GR included
7 ${P}/INTRO/OBS/PTBB2070.PZH PTBB 14234 M001 32 G included
8 ${P}/INTRO/OBS/TLSE2070.PZH TLSE 10003 M009 52 GR included
9 ${P}/INTRO/OBS/WSRT2070.PZH WSRT 13506 M005 31 G included
10 ${P}/INTRO/OBS/WTZR2070.PZH WTZR 14201 M010 51 GR included
11 ${P}/INTRO/OBS/WTZZ2070.PZH WTZZ 14201 M014 52 GR included
12 ${P}/INTRO/OBS/ZIM22070.PZH ZIM2 14001 M008 52 GR included
13 ${P}/INTRO/OBS/ZIMM2070.PZH ZIMM 14001 M004 31 G included
...
The creation of the following 12 baseline les from 13 zero dierence observation les is
reported:
SNGDIF: INPUT AND OUTPUT OBSERVATION FILE NAMES
-----------------------------------------------
0-DIF. HEADER FILE NAMES (INPUT) 0-DIF. OBS. FILE NAMES (INPUT) NUM
******************************** ******************************** ***
${P}/INTRO/OBS/GANP2070.PZH ${P}/INTRO/OBS/GANP2070.PZO 1
${P}/INTRO/OBS/JOZ22070.PZH ${P}/INTRO/OBS/JOZ22070.PZO 2
${P}/INTRO/OBS/HERT2070.PZH ${P}/INTRO/OBS/HERT2070.PZO 3
${P}/INTRO/OBS/ZIM22070.PZH ${P}/INTRO/OBS/ZIM22070.PZO 4
${P}/INTRO/OBS/LAMA2070.PZH ${P}/INTRO/OBS/LAMA2070.PZO 6
${P}/INTRO/OBS/ONSA2070.PZH ${P}/INTRO/OBS/ONSA2070.PZO 8
...
${P}/INTRO/OBS/ZIM22070.PZH ${P}/INTRO/OBS/ZIM22070.PZO 23
${P}/INTRO/OBS/ZIMM2070.PZH ${P}/INTRO/OBS/ZIMM2070.PZO 24
1-DIF. HEADER FILE NAMES (OUT) 1-DIF. OBS. FILE NAMES (OUT) NR1 NR2 STAT.
******************************** ******************************** *** *** *****
${P}/INTRO/OBS/GAJO2070.PSH ${P}/INTRO/OBS/GAJO2070.PSO 1 2 OK
${P}/INTRO/OBS/HEZI2070.PSH ${P}/INTRO/OBS/HEZI2070.PSO 3 4 OK
${P}/INTRO/OBS/JOLA2070.PSH ${P}/INTRO/OBS/JOLA2070.PSO 5 6 OK
${P}/INTRO/OBS/JOON2070.PSH ${P}/INTRO/OBS/JOON2070.PSO 7 8 OK
...
${P}/INTRO/OBS/ZIZM2070.PSH ${P}/INTRO/OBS/ZIZM2070.PSO 23 24 OK
If the strategy OBS-MAX was selected all possible pairs of zero dierence les are listed
with the corresponding criterion value. The baselines belonging to the created network
conguration are labeled with OK.
1 GANP 11515 M001 - HERT 13212 M010 #SAT: 50 CRIT.: 20892
2 GANP 11515 M001 - JOZ2 12204 M002 #SAT: 50 CRIT.: 23424 OK
3 GANP 11515 M001 - LAMA 12209 M001 #SAT: 50 CRIT.: 22806
4 GANP 11515 M001 - MATE 12734 M008 #SAT: 50 CRIT.: 20725
...
21 HERT 13212 M010 - WTZZ 14201 M014 #SAT: 51 CRIT.: 22697
22 HERT 13212 M010 - ZIM2 14001 M008 #SAT: 51 CRIT.: 23219 OK
23 HERT 13212 M010 - ZIMM 14001 M004 #SAT: 31 CRIT.: 13051
24 JOZ2 12204 M002 - LAMA 12209 M001 #SAT: 50 CRIT.: 24807 OK
25 JOZ2 12204 M002 - MATE 12734 M008 #SAT: 50 CRIT.: 20969
26 JOZ2 12204 M002 - ONSA 10402 M004 #SAT: 50 CRIT.: 23855 OK
27 JOZ2 12204 M002 - PTBB 14234 M001 #SAT: 30 CRIT.: 11243
28 JOZ2 12204 M002 - TLSE 10003 M009 #SAT: 50 CRIT.: 21991
29 JOZ2 12204 M002 - WSRT 13506 M005 #SAT: 30 CRIT.: 14464 OK
30 JOZ2 12204 M002 - WTZR 14201 M010 #SAT: 50 CRIT.: 24390 OK
31 JOZ2 12204 M002 - WTZZ 14201 M014 #SAT: 50 CRIT.: 24182
...
4.2.3 Preprocessing of the Phase Baseline Files
The main task of the program MAUPRP is the cycleslip detection and correction. It is
started using "Menu>Processing>Phase preprocessing".
In the next input panel MAUPRP 2: Output Files you only need to specify the Program
output, e.g., to MPR$YD+0 .
Page 38 AIUB
The output of the program MAUPRP is discussed in detail in the lecture session. The
software manual contains a detailed description, too.
You can nd here the results of the adjustment of the input parameters for the maximum
accepted change of the ionosphere from one epoch to the next, which is computed according
to the baseline length (AUTO in option Screening mode, frequency to check, panel MAUPRP 3:
General Options).
...
STATION 1: GANP 11515 M001 YEAR: 2010 SESSION: 2070
STATION 2: JOZ2 12204 M002 DAY : 207 FILE : 0
BASELINE LENGTH (M) : 344406.647
OBSERVAT. FILE NAME : ${P}/INTRO/OBS/GAJO2070.PSH
BASELINE DEPENDENT OPTIONS:
--------------------------
CHECK FREQUENCIES (L1=1, L2=2, L1&L2=3, L1,L2=4) --> : 3
MAX. IONOS.DIFF. BETW. EPOCHS (o/o OF L1 CYCLES) --> : 94
...
The most important item to check is the epoch dierence solution:
...
------------------------------------------------------------------------
EPOCH DIFFERENCE SOLUTION
------------------------------------------------------------------------
FREQUENCY OF EPOCH DIFF. SOLU.: 3
#OBS. USED FOR EPOCH DIFF. SOLU: 42814
RMS OF EPOCH DIFF. SOLUTION (M): 0.012
COORDINATES NEW -A PRIORI X (M): 0.187 +- 0.021
Y (M): 0.037 +- 0.021
Z (M): 0.284 +- 0.014
------------------------------------------------------------------------
...
The epoch dierence solution is used as the reference for the data screening. For a success-
ful phase preprocessing the RMS OF EPOCH DIFF. SOLUTION has to be below 2 cm. The
estimates for the coordinates in the epoch dierence solution are expected to be smaller
than about 0.5 m.
It should be pointed out that it is not necessary to run the program MAUPRP more than
once for each baseline. However, it is mandatory to run MAUPRP again if you (for whatever
reason) have to recreate the baselines with program SNGDIF.
Page 40 AIUB
4.3 Daily Goals
You might get some warning messages regarding too large O C (i.e., observed minus
computed) values on certain baselines for certain epochs. The corresponding observations
get agged, and will not disturb the processing.
You can use the extraction program MPRXTR ("Menu>Processing>Program output extraction>Phase
preprocessing") to generate a short summary of the MAUPRP output. The le you have
specied in MAUPRP summary le looks like this:
SUMMARY OF THE MAUPRP OUTPUT FILE
*********************************
SESS FIL OK? ST1 ST2 L(KM) #OBS. RMS DX DY DZ #SL #DL #MA MAXL3 MIN.SLIP
----------------------------------------------------------------------------------------------
2070 1 OK GANP JOZ2 344 42814 12 187 37 284 12 369 72 49 12
2070 2 OK HERT ZIM2 685 41498 13 -314 9 -343 6 591 95 47 11
2070 3 OK JOZ2 LAMA 201 43720 11 -16 -6 73 39 824 101 49 11
2070 4 OK JOZ2 ONSA 830 41462 11 -423 -155 -458 7 609 113 34 11
2070 5 OK JOZ2 WSRT 981 22358 11 -198 -24 -223 8 413 47 33 11
2070 6 OK JOZ2 WTZR 663 41785 13 -239 -80 -383 11 641 81 48 11
2070 7 OK MATE ZIM2 1014 38157 13 476 41 442 64 876 118 49 11
2070 8 OK PTBB ZIM2 640 20063 12 45 -11 -27 82 242 36 50 13
2070 9 OK TLSE ZIM2 597 41698 13 19 41 118 6 610 89 47 11
2070 10 OK WTZR WTZZ 0 43787 12 4 -8 -2 96 461 65 0 0
2070 11 OK WTZR ZIM2 476 42211 14 154 10 82 6 974 89 44 13
2070 12 OK ZIM2 ZIMM 0 23786 13 -20 6 -20 25 88 35 0 0
----------------------------------------------------------------------------------------------
Tot: 12 536 43787 14 476 41 442 96 974 118 50 0
Note that in the bottom line the maximum values for each column are reported to show
the worst case.
4.3 Daily Goals
At the end of todays session, you should have created the following les:
1. Bernese formatted zero dierence observation les in your campaigns OBS
directory: GANP2070. CZH , GANP2070. PZH , GANP2070. CZO , GANP2070.
PZO , ... (for all stations).
2. Single dierence les (baseline les) in the OBS directory: GAJO2070. PSH ,
GAJO2070. PSO , HEZI2070. PSH , HEZI2070. PSO ,... for all baselines,
3. you should also have veried the outputs of these programs: ORBGEN,
CODSPP, SNGDIF, and MAUPRP
Page 42 AIUB
5 Terminal Session: Wednesday
1. perform a residual screening (GPSEST, RESRMS, SATMRK),
2. generate a rst estimation for coordinates and troposphere parameters
(GPSEST),
3. resolve the double dierence ambiguities (GPSEST),
ideally for all four days of the processing example, but at least for one session for
each year, e.g.: 2010, 207 and 2011, 205. You can run through these steps session by
session.
5.1 Data Preprocessing (II)
The main parameter estimation based on a leastsquares adjustment is the task of program
GPSEST. It is a good idea to start GPSEST rst in the session mode and to produce a L
3
solution with realvalued ambiguities. We do not expect any nal results from this run
but we want to check the quality of data and save the residuals after the leastsquares
adjustment. The program is available via "Menu>Processing>Parameter estimation". We use the
following options:
Page 43
This run is intended to screen the postt residuals for outliers. Later on, for the ambiguity
resolution, all observations are needed without downsampling the data. To run the
program GPSEST for the network with 13 stations and the observations to more than
50 satellites without reducing the data sampling rate takes easily 10 minutes or more. For
that reason we are forced to sample the data, e.g., down to 3 minutes we will see in the
next step how to solve this discrepancy.
Page 44 AIUB
We want to give loose constraints to the station coordinates that are available from
the IGS realization of ITRF2008 reference frame (ag I like IGb08 in the coordinate
le).
No parameters (not even ambiguity parameters) can be preeliminated if residuals should
be written into the residual output le:
Page 46 AIUB
A 4 hour resolution in time for the troposphere parameters is sucient for this purpose:
The program output of GPSEST summarizes all important input options, input data,
and reports the estimated results. An important information in the output le is the
a posteriori RMS error:
...
A POSTERIORI SIGMA OF UNIT WEIGHT (PART 1):
------------------------------------------
A POSTERIORI SIGMA OF UNIT WEIGHT : 0.0013 M (SIGMA OF ONE -WAY L1 PHASE OBSERVABLE AT ...
DEGREE OF FREEDOM (DOF) : 72461
CHI **2/ DOF : 1.66
...
An a posteriori RMS error of about 1.0. . . 1.5 mm is expected if elevationdependent
weighting is used. A signicant higher RMS error indicates that either your data stems
from lowquality receivers, that the data was collected under extremely bad condi-
tions, or that the preprocessing step (MAUPRP and CODSPP) was not successfully per-
formed.
Below you nd the section reporting on coordinate estimation. You should check the
improvement for the a priori coordinates. If all stations get approximately the same
improvement in the order of decimeters, very likely the datum denition failed. Check
that you have really selected datum stations.
...
STATION COORDINATES: (NOT SAVED)
-------------------
NUM STATION NAME PARAMETER A PRIORI VALUE NEW VALUE NEW - A PRIORI RMS ERROR
------------------------------------------------------------------------------------------- ..
71 GANP 11515 M001 X 3929181.4196 3929181.4184 -0.0012 0.0045
Y 1455236.8235 1455236.8258 0.0023 0.0043
Z 4793653.9446 4793653.9492 0.0046 0.0044
HEIGHT 746.0101 746.0135 0.0033 0.0047 ..
LATITUDE 49 2 4.971198 49 2 4.971303 0.0033 0.0042 ..
LONGITUDE 20 19 22.574559 20 19 22.574685 0.0025 0.0043 ..
106 JOZ2 12204 M002 X 3664880.4764 3664880.4816 0.0052 0.0044
Y 1409190.6777 1409190.6824 0.0047 0.0043
Z 5009618.5305 5009618.5344 0.0038 0.0044
HEIGHT 152.5285 152.5356 0.0071 0.0045 ..
LATITUDE 52 5 52.211730 52 5 52.211638 -0.0028 0.0042 ..
LONGITUDE 21 1 56.470105 21 1 56.470234 0.0024 0.0042 ..
89 HERT 13212 M010 X 4033460.8501 4033460.8488 -0.0013 0.0044
Y 23537.8917 23537.8974 0.0057 0.0043
Z 4924318.3162 4924318.3214 0.0053 0.0044
HEIGHT 83.3356 83.3389 0.0033 0.0046 ..
LATITUDE 50 52 2.929096 50 52 2.929235 0.0043 0.0042 ..
LONGITUDE 0 20 3.676879 0 20 3.677171 0.0057 0.0042 ..
270 ZIM2 14001 M008 X 4331299.7923 4331299.7894 -0.0029 0.0043
Y 567537.4232 567537.4252 0.0019 0.0042
Z 4633133.7947 4633133.7822 -0.0125 0.0043
HEIGHT 956.4400 956.4292 -0.0109 0.0045 ..
LATITUDE 46 52 37.540714 46 52 37.540499 -0.0066 0.0042 ..
LONGITUDE 7 27 54.115680 7 27 54.115788 0.0023 0.0042 ..
...
If the residuals have been stored in the binary residual le (specied in GPSEST 2.2: Output
Files 2) it is possible to have a look to the residuals (program REDISP, "Menu>Service>Residual
les>Display residual le").
To screen the residuals automatically use the program RESRMS in "Menu>Service>Residual les
>Create residual statistics".
The sampling interval you have previously introduced in option Sampling interval in pro-
gram GPSEST has to be repeated here. RESRMS makes the assumption that the observa-
tions between two outliers in the sampled residual le are also bad.
Page 48 AIUB
The program output of RESRMS (${P}/INTRO/OUT/RMS10207.OUT) provides a nice
overview on the data quality.
...
FILE INFORMATION AND STATISTIC:
------------------------------
Num Station 1 Station 2 Total RMS med.Resi Sigma numObs nSat nDel ..
--------------------------------------------------------------------------------------------..
1 GANP 11515 M001 JOZ2 12204 M002 1.4 0.7 1.1 7611 50 16 ..
2 HERT 13212 M010 ZIM2 14001 M008 1.4 0.8 1.1 7372 51 12 ..
3 JOZ2 12204 M002 LAMA 12209 M001 1.3 0.7 1.1 7741 50 17 ..
4 JOZ2 12204 M002 ONSA 10402 M004 1.3 0.7 1.1 7368 50 20 ..
5 JOZ2 12204 M002 WSRT 13506 M005 1.4 0.8 1.1 4192 30 11 ..
6 JOZ2 12204 M002 WTZR 14201 M010 1.6 0.9 1.2 7460 50 18 ..
7 MATE 12734 M008 ZIM2 14001 M008 1.5 0.8 1.2 6788 51 22 ..
8 PTBB 14234 M001 ZIM2 14001 M008 1.4 0.8 1.2 3819 32 15 ..
9 TLSE 10003 M009 ZIM2 14001 M008 1.6 0.8 1.3 7443 52 19 ..
10 WTZR 14201 M010 WTZZ 14201 M014 1.6 0.7 1.0 7817 51 51 ..
11 WTZR 14201 M010 ZIM2 14001 M008 1.7 1.0 1.4 7563 51 27 ..
12 ZIM2 14001 M008 ZIMM 14001 M004 0.9 0.5 0.8 4540 31 1 ..
--------------------------------------------------------------------------------------------..
...
In addition, les containing a summary table (${P}/INTRO/OUT/RMS10207.SUM) and a
histogram (${P}/INTRO/OUT/RMS10207.LST) of the residuals are available. The most im-
portant result le for the data screening is the Edit information le (${P}/INTRO/OUT/
RMS10207.EDT), which may be used by the program SATMRK to mark outliers in the
observation les ("Menu>Service>Bernese observation les>Mark/delete observations"):
The program output from SATMRK reports the number of marked observations per base-
line:
...
SUMMARY OF ACTION IN THE OBS. FILE(S): ${P}/INTRO/OUT/RMS10207.EDT
-------------------------------------
Mea - Observations ..
Num Station name 1 Station name 2 type mark unmark delete ..
-----------------------------------------------------------------------------..
1 GANP 11515 M001 JOZ2 12204 M002 P : 420 0 0 ..
2 HERT 13212 M010 ZIM2 14001 M008 P : 324 0 0 ..
3 JOZ2 12204 M002 LAMA 12209 M001 P : 422 0 0 ..
4 JOZ2 12204 M002 ONSA 10402 M004 P : 530 0 0 ..
5 JOZ2 12204 M002 WSRT 13506 M005 P : 324 0 0 ..
6 JOZ2 12204 M002 WTZR 14201 M010 P : 538 0 0 ..
7 MATE 12734 M008 ZIM2 14001 M008 P : 638 0 0 ..
8 PTBB 14234 M001 ZIM2 14001 M008 P : 326 0 0 ..
9 TLSE 10003 M009 ZIM2 14001 M008 P : 536 0 0 ..
10 WTZR 14201 M010 WTZZ 14201 M014 P : 1096 0 0 ..
11 WTZR 14201 M010 ZIM2 14001 M008 P : 864 0 0 ..
12 ZIM2 14001 M008 ZIMM 14001 M004 P : 22 0 0 ..
-----------------------------------------------------------------------------..
Total: 6040 0 0 ..
Page 50 AIUB
5.2 Produce a First Network Solution
After screening the observations for outliers we can generate an ionospherefree (L
3
) so-
lution with unresolved ambiguities. The input options are very similar to the previous
preprocessing step. There are only a few dierences shown in the following panels:
The le in the input eld Ionosphere models enables the HOIcorrections.
We store the coordinates and troposphere parameters into les to be reintroduced later:
In the subsequent panel you should remove the output lename for the Residuals because
we do not need the residuals from this run.
The next two panels with the general options for GPSEST remain untouched:
To heavily constrain the coordinates of the IGS core sites is not the best way to realize the
geodetic datum for a solution. The program ADDNEQ2 oers more sophisticated options
(e.g., minimum constraint solution). This will be the topic of the lecture session tomorrow.
Today we will follow this simple approach:
Page 52 AIUB
Since we do not store residual les in this run, ambiguity parameters may be preeliminated
from the normal equation before the parameters are estimated:
The estimation of troposphere parameters is mandatory for a campaign of this type. We
increase the number of estimated parameters (e.g., to 24 instead of 6 parameters per
station and session). In addition, it is recommended to set up troposphere gradient pa-
rameters.
In order to avoid a format overow in the Troposphere estimates output le that may happen
if a troposphere parameter is estimated based on very few observations concentrated at
one end of the interval of parameter validity, a small relative sigma (e.g., 5 meter) may
help.
In the rst part of the output generated by program GPSEST, the selected options are
echoed. The result part starts with some statistics on the parameters and the observa-
tions:
...
13. RESULTS (PART 1)
--------------------
NUMBER OF PARAMETERS (PART 1):
-----------------------------
PARAMETER TYPE #PARAMETERS #PRE -ELIMINATED #SET -UP ...
------------------------------------------------------------------------------------------ ...
STATION COORDINATES 39 0 39 ...
AMBIGUITIES 1370 1370 (BEFORE INV) 1482 ...
SITE -SPECIFIC TROPOSPHERE PARAMETERS 377 0 377 ...
------------------------------------------------------------------------------------------ ...
TOTAL NUMBER OF PARAMETERS 1786 1370 1898 ...
------------------------------------------------------------------------------------------ ...
NUMBER OF OBSERVATIONS (PART 1):
-------------------------------
TYPE FREQUENCY FILE/PAR #OBSERVATIONS
------------------------------------------------------------------------------------------ ...
PHASE L3 ALL 73606
------------------------------------------------------------------------------------------ ...
TOTAL NUMBER OF OBSERVATIONS 73606
------------------------------------------------------------------------------------------ ...
...
Then the a posteriori RMS error and the results of the initial leastsquares adjustment
are given
...
------------------------------------------
CHI **2/ DOF : 1.28
...
Below you nd the output of the results for coordinates and troposphere parame-
ters:
...
STATION COORDINATES: ${P}/INTRO/STA/FLT10207.CRD
-------------------
--------------------------------------------------------------------------------------------..
71 GANP 11515 M001 X 3929181.4196 3929181.4188 -0.0008 0.0010
Y 1455236.8235 1455236.8224 -0.0011 0.0008
Z 4793653.9446 4793653.9493 0.0048 0.0011
HEIGHT 746.0101 746.0130 0.0028 0.0014 ..
LATITUDE 49 2 4.971198 49 2 4.971328 0.0040 0.0006 ..
LONGITUDE 20 19 22.574559 20 19 22.574521 -0.0008 0.0008 ..
106 JOZ2 12204 M002 X 3664880.4764 3664880.4788 0.0025 0.0006
Y 1409190.6777 1409190.6797 0.0019 0.0006
Z 5009618.5305 5009618.5334 0.0029 0.0006
HEIGHT 152.5285 152.5326 0.0041 0.0007 ..
LATITUDE 52 5 52.211730 52 5 52.211710 -0.0006 0.0005 ..
LONGITUDE 21 1 56.470105 21 1 56.470154 0.0009 0.0006 ..
89 HERT 13212 M010 X 4033460.8501 4033460.8504 0.0003 0.0007
Y 23537.8917 23537.8909 -0.0009 0.0007
Z 4924318.3162 4924318.3190 0.0028 0.0008
HEIGHT 83.3356 83.3380 0.0024 0.0009 ..
LATITUDE 50 52 2.929096 50 52 2.929148 0.0016 0.0005 ..
LONGITUDE 0 20 3.676879 0 20 3.676834 -0.0009 0.0007 ..
...
Page 54 AIUB
5.3 Ambiguity Resolution
...
SITE -SPECIFIC TROPOSPHERE PARAMETERS: ${P}/INTRO/ATM/FLT10207.TRP
------------------------------------
REFERENCE ELEVATION ANGLE OF GRADIENT TERMS : 45.0 DEGREES
MINIMUM ELEVATION ANGLE : 5.0 DEGREES
MAPPING FACTOR AT MINIMUM ELEVATION ANGLE : 11.4
CORRECTIONS (M) RMS ERRORS (M) ...
REQU. STATION NAME NORTH EAST ZENITH NORTH EAST ZENITH ...
---------------------------------------------------------------------------------- ...
1 GANP 11515 M001 -0.00032 -0.00015 0.12264 0.00011 0.00013 0.00228
2 GANP 11515 M001 -0.00029 -0.00010 0.11844 0.00011 0.00012 0.00169
3 GANP 11515 M001 -0.00026 -0.00006 0.12020 0.00010 0.00011 0.00157
4 GANP 11515 M001 -0.00023 -0.00002 0.12353 0.00009 0.00010 0.00162
5 GANP 11515 M001 -0.00020 0.00003 0.12380 0.00009 0.00010 0.00131
...
24 GANP 11515 M001 0.00038 0.00087 0.13859 0.00011 0.00012 0.00184
25 GANP 11515 M001 0.00041 0.00091 0.13005 0.00012 0.00013 0.00226
26 HERT 13212 M010 -0.00138 -0.00197 0.20108 0.00013 0.00015 0.00300
27 HERT 13212 M010 -0.00131 -0.00188 0.19974 0.00012 0.00014 0.00153
28 HERT 13212 M010 -0.00124 -0.00179 0.19108 0.00011 0.00014 0.00188
29 HERT 13212 M010 -0.00117 -0.00170 0.19154 0.00011 0.00013 0.00178
...
Because outliers have been removed in the previous step, the obtained a posteriori RMS
error should decrease (at least not increase). If this is not the case, it is likely that the
observations and the heavily constrained a priori coordinates are inconsistent. A detailed
discussion will be a topic of the terminal session tomorrow.
To resolve the ambiguities, we process the baselines separately one by one using the Quasi
IonosphereFree (QIF) strategy. This baseline processing mode is necessary because of the
tremendous number of parameters. The attempt to resolve the ambiguities in a session
solution might require too much CPU and memory to be feasible (several iterations with
inversions of the full normal equation (NEQ) are necessary).
The theoretical background for the ambiguity resolution will be the topic of the lecture
session on Thursday morning. Nevertheless, you may start the processing already today
if you have time.
5.3.1 Ambiguity Resolution: QuasiIonosphereFree (QIF)
The complete list of baseline observation les of a session (e.g., session 2070 of year 2010)
can be generated by listing all phase singledierence header les in the campaigns ob-
servation directory of your campaign:
bern52@carina :~ > ls ${P}/INTRO/OBS /????2070. PSH
${P}/INTRO/OBS/GAJO2070.PSH
${P}/INTRO/OBS/HEZI2070.PSH
${P}/INTRO/OBS/JOLA2070.PSH
${P}/INTRO/OBS/JOON2070.PSH
${P}/INTRO/OBS/JOWS2070.PSH
${P}/INTRO/OBS/JOWT2070.PSH
${P}/INTRO/OBS/MAZI2070.PSH
${P}/INTRO/OBS/PTZI2070.PSH
${P}/INTRO/OBS/TLZI2070.PSH
${P}/INTRO/OBS/WTWZ2070.PSH
${P}/INTRO/OBS/WTZI2070.PSH
${P}/INTRO/OBS/ZIZM2070.PSH
The rst baseline for this session is from GANP to JOZ2 with the observation lename
GAJO2070. Using the menu time variables this name is specied as GAJO$S+0. The following
options are used for the ambiguity resolution step:
Page 56 AIUB
Only one baseline le is selected. Coordinates and troposphere estimates are introduced
from the previous rst network solution (Section 5.2). Specify a baseline specic output
to prevent overwriting in subsequent runs: GAJO$+0Q. The Q at the end shall indicate
that it is the output from the QIFstrategy.
Because the QIFambiguity resolution strategy is very sensitive to the formal errors of the
ambguity parameters we have to include all measurements with the full sampling of 30 s
into the processing.
The selection of a ZPD model and mapping function (GNSS) is disabled because a tropo-
sphere le has been introduced in panel GPSEST 1.2: Input Files 2. The program uses
the troposphere model from this input le and allows no other selection for consistency
reasons.
In the subsequent panel the Resolution strategy is chosen. Please, do not forget to store
the resolved integer ambiguities in your observation le (mark checkbox at Save resolved
ambiguities).
In case of ambiguity resolution including GLONASS, only one ambiguity per iteration can
be resolved.
Page 58 AIUB
An additional panel with options specic to epochparameters is displayed now be-
cause the Parameter Setup: stochastic ionosphere parameters are pre-eliminated EV-
ERY_EPOCH.
After reporting input options and input data for the current run of GPSEST, the re-
sults are presented in two parts. The rst part refers to the solution where the am-
biguities are estimated as real values whereas the second part reports the results after
resolving the ambiguity parameters to integer values. The realvalued estimates for the
ambiguities may be found below the STATION COORDINATES section of the program
output:
...
--------------------
-----------------------------
------------------------------------------------------------------------------------------ ...
AMBIGUITIES 196 0 242 ...
STOCHASTIC IONOSPHERE PARAMETERS 40364 40364 (EPOCH -WISE) 45454 ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
-------------------------------
------------------------------------------------------------------------------------------ ...
PHASE L1 ALL 37484
PHASE L2 ALL 37484
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
...
...
------------------------------------------
CHI **2/ DOF : 1.09
...
...
-------------------
--------------------------------------------------------------------------------------------..
106 JOZ2 12204 M002 X 3664880.4788 3664880.4787 -0.0002 0.0002
Y 1409190.6797 1409190.6795 -0.0001 0.0002
Z 5009618.5334 5009618.5336 0.0002 0.0002
HEIGHT 152.5326 152.5327 0.0001 0.0002 ..
LATITUDE 52 5 52.211710 52 5 52.211721 0.0003 0.0001 ..
LONGITUDE 21 1 56.470154 21 1 56.470150 -0.0001 0.0002 ..
...
...
AMBIGUITIES:
-----------
REFERENCE
AMBI FILE SAT. EPOCH FRQ WLF CLU AMBI CLU AMBIGUITY RMS TOTAL AMBIGU. DL/L
------------------------------------------------------------------------------------------ ...
1 1 3 2199 1 1 3 - - 1.08 20.96 1747244.08
2 1 11 1 1 1 4 - - 2.15 20.96 -120949.85
3 1 11 2613 1 1 6 - - -3.82 20.96 -120952.82
4 1 14 1 1 1 7 - - 1.76 20.96 -484082.23
5 1 14 1478 1 1 8 - - -0.65 20.96 -484244.65
6 1 14 2569 1 1 9 - - 1.19 20.96 -484299.81
7 1 17 1 1 1 10 - - 3.40 20.96 -1280029.60
8 1 17 1111 1 1 11 - - -1.88 20.96 -1280192.88
9 1 19 1 1 1 13 - - 2.67 20.96 1400087.67
10 1 19 897 1 1 14 - - 0.40 20.97 1400165.40
11 1 19 2337 1 1 15 - - -2.78 20.96 1400190.22
12 1 20 1 1 1 16 - - 2.33 20.96 757891.33
...
Page 60 AIUB
If GLONASS data are processed, singledierence (instead of doubledierence) am-
biguities are resolved and no REFERENCE as in case of GPSonly ap-
pears.
In the next part of the output the result of the QIF ambiguity resolution algorithm is
given:
...
AMBIGUITY RESOLUTION:
--------------------
STRATEGY : QUASI -IONOSPHERE -FREE AMBIGUITY RESOLUTION (QIF)
------------------------------------------------------------------------------------------ ...
AMBIGUITY RESOLUTION ITERATION: 1
------------------------------------------------------------------------------------------ ...
BEST INT. CORRECTIONS IN CYCLES
FILE AM1 CL1 #AM1 AM2 CL2 #AM2 L1 L2 L1 L2 L5 L3 RMS(L3) SA1 SA2
------------------------------------------------------------------------------------------ ...
1 89 106 1 94 112 1 -4 -3 -0.03 -0.04 0.009 0.002 0.003 27 9
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
1 18 22 1 82 97 1 0 1 0.09 0.11 -0.022 0.009 0.003 24 6
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
1 1 3 1 82 97 2 -1 -1 -0.02 -0.03 0.006 -0.002 0.003 3 6
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
1 16 20 1 82 97 3 -4 -2 -0.08 -0.10 0.021 -0.005 0.003 22 6
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
1 11 15 1 82 97 4 -5 -3 0.13 0.18 -0.043 -0.019 0.003 19 6
...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
1 70 82 3 71 83 1 -2 -3 0.22 0.31 -0.085 -0.077 0.008 111 111
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
1 25 29 1 66 77 3 6 5 -0.05 -0.06 0.014 0.001 0.009 105 101
...
The individual iteration steps are rst described (we specied that up to ten ambiguities
may be resolved within each iteration step see panel GPSEST 3.2.4: Quasi-Ionosphere-
Free Ambiguity Resolution Strategy). The following information is listed for each resolved
doubledierence ambiguity:
FILE le number (1 in our case; we process one baseline only),
AM1 rst ambiguity number (singledierence level),
CL1 corresponding ambiguity cluster,
#AM1 number of ambiguities belonging to the same cluster,
AM2, CL2, #AM2
similar information for the second ambiguity.
BEST INT. L1, L2
are the integer corrections to the a priori values (a priori values are computed using
the a priori coordinates and may be rather inaccurate).
CORRECTIONS IN CYCLES
for carriers L1 and L2 gives the information about the fractional parts of the L
1
and
L
2
ambiguities. The CORRECTIONS IN CYCLES L5 and L3 are of greater interest.
The value L5 represents the ionosphereinduced bias expressed in L
5
cycles. These
values may not be greater than the maximum value specied in panel GPSEST 3.2.4:
Quasi-Ionosphere-Free Ambiguity Resolution Strategy (option Search width for pairs of L1
and L2 ambiguities). RMS(L3) is the criterion according to which the ambiguities
are sorted. Ambiguities with L
3
RMS errors larger than the value specied in the
program input panel (in our example 0.03) will not be resolved.
SA1, SA2
rst and second satellite number related to the ambiguities.
Note that in AMBIGUITY RESOLUTION ITERATION: 65 and 66 there are examples
for resolving pairs of ambiguities from the same satellite (pathtopath ambiguity
resolution) GLONASS satellites 114, and 119 .
The results of the ambiguity resolution are summarized in the following ta-
ble:
...
REFERENCE
AMBI FILE SAT. EPOCH FRQ WLF CLU AMBI CLU AMBIGUITY RMS TOTAL AMBIGU. DL/L
------------------------------------------------------------------------------------------ ...
1 1 3 2199 1 1 3 - - -1 1747242. 0.00000
2 1 11 1 1 1 4 - - 1 -120951. 0.00000
3 1 11 2613 1 1 6 - - 0 -120949. 0.00000
4 1 14 1 1 1 7 - - 5 -484079. 0.00000
5 1 14 1478 1 1 8 - - 3 -484241. 0.00000
6 1 14 2569 1 1 9 - - 5 -484296. 0.00000
7 1 17 1 1 1 10 - - 5 -1280028. 0.00000
8 1 17 1111 1 1 11 - - -1.81 21.78 -1280192.81
9 1 19 1 1 1 13 - - 7 1400092. 0.00000
10 1 19 897 1 1 14 - - 0.48 21.79 1400165.48
11 1 19 2337 1 1 15 - - -5 1400188. 0.00000
12 1 20 1 1 1 16 - - 1 757890. 0.00000
13 1 20 2770 1 1 17 - - 6 757842. 0.00000
14 1 22 1 1 1 18 - - 1.32 21.81 -893533.68
15 1 22 1248 1 1 19 - - 6 -893514. 0.00000
16 1 22 2254 1 1 20 - - -4 -893533. 0.00000
17 1 24 1 1 1 21 - - 5 427188. 0.00000
18 1 24 2196 1 1 22 - - 0 427032. 0.00000
19 1 28 1 1 1 23 - - 1.76 21.81 -394055.24
20 1 28 782 1 1 24 - - -4 -394018. 0.00000
...
Page 62 AIUB
The ambiguities for which an RMS is specied could not be resolved (these ambiguities
will be treated as real values by all subsequent program runs). In case of GLONASS, only
ambiguities with the same channel number are resolved in Version 5.2 of Bernese GNSS
Software .
Ambiguity resolution has an inuence on other parameters. Therefore, the results of the
ambiguityxed solution are given in Part 2 of the output:
...
--------------------
-----------------------------
------------------------------------------------------------------------------------------ ...
STOCHASTIC IONOSPHERE PARAMETERS 40364 40364 (EPOCH -WISE) 45454 ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
-------------------------------
------------------------------------------------------------------------------------------ ...
PHASE L1 ALL 37484
PHASE L2 ALL 37484
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
...
...
------------------------------------------
CHI **2/ DOF : 1.18
...
...
-------------------
--------------------------------------------------------------------------------------------..
106 JOZ2 12204 M002 X 3664880.4788 3664880.4785 -0.0004 0.0001
Y 1409190.6797 1409190.6792 -0.0005 0.0001
Z 5009618.5334 5009618.5338 0.0004 0.0002
HEIGHT 152.5326 152.5326 -0.0000 0.0002 ..
LATITUDE 52 5 52.211710 52 5 52.211731 0.0006 0.0001 ..
LONGITUDE 21 1 56.470154 21 1 56.470137 -0.0003 0.0001 ..
...
You may see from the output that from a total of 196 ambiguities 130 ambiguities
could be resolved (compare part 1 AMBIGUITIES with part 2 AMBIGUITIES). Note that
these numbers include reference ambiguities for each GNSS, GLONASS frequency num-
ber and frequency (it means (2 + 12) 2 = 28 out of 66 remaining ambiguities in this
case).
5.3.2 Ambiguity Resolution: Short Baselines
There are two very short baselines in the network where a direct ambiguity resolution for
the L
1
and L
2
signal is possible applying the sigmastrategy. It is also explained in the
lecture on ambiguity resolution on Thursday.
The ultrashort baseline in Ktzting is between WTZR and WTZZ (WTWZ2070.PSH). The
GPSEST input panels should look like follows:
Page 64 AIUB
The program output name is again related to the name of the baseline but contains an
identier 1 at the end to distinguish the les from the output les of the QIFstrategy:
The structure of the program output is the same as it has extensively been described in
the previous section for the QIF ambiguity resolution strategy. It starts with PART 1
for the solution before the ambiguity resolution. Here are the corresponding parameter
statistics:
...
--------------------
-----------------------------
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
-------------------------------
------------------------------------------------------------------------------------------ ...
PHASE L1 ALL 38232
PHASE L2 ALL 38232
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
...
Page 66 AIUB
...
------------------------------------------
CHI **2/ DOF : 1.55
...
After the ambiguity resolution the same statistics is provided in PART 2:
...
--------------------
-----------------------------
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
...
...
------------------------------------------
CHI **2/ DOF : 1.66
...
From the number of ambiguity parameters it can be computed that 162 out of 206 am-
biguities from both GPS and GLONASS have been resolved to their integer numbers.
Please remind, that at least 4 ambiguity parameters must remain as real values because of
one reference ambiguity per GNSS and frequency are needed. Because the two receivers
belong to dierent groups regarding GLONASS ambiguity resolution between dierent frequency
channels only the ambiguities between the same frequency numbers have been resolved.
In addition, depending on the receiver type, not all ambiguities for GPS are allowed to be
resolved too, to prevent problems with the quartercycle bias between the L2P and L2C
signal (see option Consider GPS quarter-cycle biases in panel GPSEST 3.2: General Options 2
and the lecture on ambiguity resolution).
5.3.3 Ambiguity Resolution: BPE
Admittedly, it is cumbersome to process the baselines manually one after the other
you have twelve baselines per session for this small example campaign. On Friday you will
have a lecture on automation of the data processing with the BPE.
In the example BPE RNX2SNX.PCF a sequence for the ambiguity resolution is in-
cluded. For this tutorial lecture a small part of this BPE is extracted into a sepa-
rate TUTORIAL.PCF BPE. The process control le (PCF) is located in the directory
${U}/PCF.
The PCF consists of three parts: the rst part denes the scripts and the option directories
where the programs input les are taken from. In addition the waiting conditions are
dened to keep the correct order for the execution of the scripts. In the second part,
special execution modes are dened, e.g., that the scripts GNSQIF_P with PID 132 and
GNSL12_P with PID 142 may run in parallel for each individual baseline. The preparatory
scripts GNSQIFAP and GNSL12AP dene the list of baselines to be processed. The third part
denes the so called BPE or PCFvariables that can be used within the scripts or in the
input elds of the menu. A detailed introduction to the BPE will be the topic of a lecture
on Friday.
The TUTORIAL.PCF is responsible for the following tasks:
011 TUT_COP :
Copies the les from the previous processing steps of the tutorial to the lenames
used in the RNX2SNX.PCF example BPE. It uses the PCF and time variables for
that purpose:
copy le from ../STA/APR${yyddd}.CRD to ../STA/APR${yyssss}.CRD
copy le from ../STA/FLT${yyddd}.CRD to ../STA/FLT${yyssss}.CRD
copy le from ../ATM/FLT${yyddd}.TRP to ../ATM/FLT${yyssss}.TRP
copy le from ../ORB/COD${yyddd}.STD to ../ORB/COD${yyssss}.STD
copy le from ../ORB/COD${yyddd}.ERP to ../ORB/COD${yyssss}.ERP
where ${yyddd} stands for the twodigit year and the day of year. The new lename
contains ${yyssss} the twodigit year together with the session (in our case day of
year plus the zerocharacter 0).
If you are not in the Bernese Introductory Course environment, you have to copy
these les manually to run the ambiguity resolution sequence of RNX2SNX.PCF .
101 SATMRK :
All previously resolved ambiguities are reinitialized to start for all les from unre-
solved ambiguities (otherwise the interpretation of the statistic of resolved ambigui-
ties may becomes dicult).
131 GNSQIFAP and 132 GNSQIF_P :
Applies the QIF ambiguity resolution strategy to all baselines of the example in a
baselinebybaseline mode, where several baselines may be processed at the same
time in parallel.
141 GNSL12AP and 142 GNSL12_P :
Applies the SIGMA ambiguity resolution strategy directly to the original observa-
tions on the L
1
and L
2
frequency for both short baselines in the example network:
Ktzting (WTZR and WTZZ) and Zimmerwald (ZIM2 and ZIMM). These scripts
also run in a baselinebybaseline mode, allowing for a parallel processing.
In the Bernese Introductory Course environment the TUTORIAL.PCF BPE can be
started for one session (e.g., day 207 of year 2010) using "Menu>BPE>Start BPE process-
ing":
Page 68 AIUB
#
# ============================================================================
# TUTORIAL.PCF
# ============================================================================
#
# Purpose: Run the ambiguity resolution for one session in the
# "Terminal Session" of the
# Bernese Software Introductory Course
#
# ----------------------------------------------------------------------------
#
# Author : R. Dach
# Created : 23-Jan -2012 Last modified: 23-Jan -2012
#
# Changes :
#
# ============================================================================
#
#
#
PID SCRIPT OPT_DIR CAMPAIGN CPU P WAIT FOR ....
3** 8******* 8******* 8******* 8******* 1 3** 3** 3** 3** 3** 3** 3** 3** 3** 3**
#
# Copy input files
# ----------------
011 TUT_COP R2S_GEN ANY 1
#
# Resolve phase ambiguities
# -------------------------
101 SATMRK R2S_GEN ANY 1 011
131 GNSQIFAP R2S_QIF ANY 1 101
132 GNSQIF_P R2S_QIF ANY 1 131
141 GNSL12AP R2S_L12 ANY 1 132
142 GNSL12_P R2S_L12 ANY 1 141
#
# End of BPE
# ----------
999 DUMMY NO_OPT ANY 1 142
#
#
PID USER PASSWORD PARAM1 PARAM2 PARAM3 PARAM4 PARAM5 PARAM6
...
3** 12********** 8******* 8******* 8******* 8******* 8******* 8******* 8*******...
#
# Resolve phase ambiguities
# -------------------------
131 $131
132 PARALLEL $131
141 $141
142 PARALLEL $141
#
#
#
#
VARIABLE DESCRIPTION DEFAULT
8******* 40************************************** 16**************
V_A A priori information APR
V_B Orbit/ERP , DCB , CLK information COD
V_C Preliminary (ambiguity -float) results FLT
V_CRDINF Project related station filenames EXAMPLE
V_GNSSAR GNSS to be used for ambiguity resolution ALL
V_BL_QIF Maximum baseline length for QIF AR 2000
V_BL_L12 Maximum baseline length for L1&L2 AR 20
V_PCV Absolute/relative PCV model I08
V_SATINF Satellite information file SATELLIT
V_PCVINF PCV information file PCV
V_SATCRX Satellite problem file SAT_$Y+0
V_BLQINF BLQ FILE NAME , CMC CORRECTIONS EXAMPLE
V_ATLINF ATL FILE NAME , CMC CORRECTIONS EXAMPLE
V_HOIFIL Ionosphere model COD$YD+0
#
# DO NOT USE V_D , V_J , V_M , V_Y VARIABLES!
# (they are used already by the menu)
#
If you follow the tutorial outside from the environment of the Bernese Introductory Course
you can select RNX2SNX in option Process control le and skip all scripts apart from
PID 401 SATMRK and the range from PID 431 GNSQIFAP to PID 442 GNSL12_P (option Skip
scripts).
Page 70 AIUB
Run the BPE once for each session. Please do not start more than one session at the time
as courtesy to the other participants in the tutorial lecture.
If the BPE stops with an error you can inspect the les ARyyddd0_...PRT and ARyyddd0_
...LOG belonging to your current session. They are located in the BPE directory of your
campaign. These les notice for instance if an input le is missing. This might be the
case if you did not follow the naming convention proposed in the tutorial. In that case
you have to copy the le from your naming to the expected one.
5.3.4 Ambiguity Resolution: Summary
For each observation le a corresponding program output le is generated. Using
the program GPSXTR ("Menu>Processing>Program output extraction>Parameter estimation/stacking")
you can generate a summary of the ambiguity resolution for all baselines of the ses-
sion:
All program output les related to the QIF ambiguity resolution method have been speci-
ed with program output lenames tting in the shape ${P}/INTRO/OUT/????$S+0_Q.OUT
and can, therefore, easily be selected in the input eld GPSEST/ADDNEQ output les.
This summary (${P}/INTRO/OUT/QIF10207.SUM) reports among others how many ambi-
guities are resolved for each baseline
1
:
File Sta1 Sta2 Length Before After Res Sys
(km) #Amb (mm) #Amb (mm) (%) ...
-------------------------------------------------------------- ... -------
GAJO2070 GANP JOZ2 344.407 102 1.0 24 1.1 76.5 G ... #AR_QIF
GAJO2070 GANP JOZ2 344.407 90 1.0 38 1.1 57.8 R ... #AR_QIF
GAJO2070 GANP JOZ2 344.407 192 1.0 62 1.1 67.7 GR ... #AR_QIF
HEZI2070 HERT ZIM2 685.151 120 1.0 46 1.1 61.7 G ... #AR_QIF
HEZI2070 HERT ZIM2 685.151 98 1.0 62 1.1 36.7 R ... #AR_QIF
HEZI2070 HERT ZIM2 685.151 218 1.0 108 1.1 50.5 GR ... #AR_QIF
JOLA2070 JOZ2 LAMA 201.183 118 0.9 36 1.0 69.5 G ... #AR_QIF
JOLA2070 JOZ2 LAMA 201.183 96 0.9 38 1.0 60.4 R ... #AR_QIF
JOLA2070 JOZ2 LAMA 201.183 214 0.9 74 1.0 65.4 GR ... #AR_QIF
JOON2070 JOZ2 ONSA 829.775 136 1.0 56 1.0 58.8 G ... #AR_QIF
JOON2070 JOZ2 ONSA 829.775 104 1.0 68 1.0 34.6 R ... #AR_QIF
JOON2070 JOZ2 ONSA 829.775 240 1.0 124 1.0 48.3 GR ... #AR_QIF
JOWS2070 JOZ2 WSRT 981.243 106 1.0 30 1.1 71.7 G ... #AR_QIF
JOWT2070 JOZ2 WTZR 663.182 104 1.3 28 1.4 73.1 G ... #AR_QIF
JOWT2070 JOZ2 WTZR 663.182 98 1.3 46 1.4 53.1 R ... #AR_QIF
JOWT2070 JOZ2 WTZR 663.182 202 1.3 74 1.4 63.4 GR ... #AR_QIF
MAZI2070 MATE ZIM2 1013.811 122 1.2 54 1.2 55.7 G ... #AR_QIF
MAZI2070 MATE ZIM2 1013.811 94 1.2 58 1.2 38.3 R ... #AR_QIF
MAZI2070 MATE ZIM2 1013.811 216 1.2 112 1.2 48.1 GR ... #AR_QIF
PTZI2070 PTBB ZIM2 640.077 114 1.2 26 1.3 77.2 G ... #AR_QIF
TLZI2070 TLSE ZIM2 596.848 120 1.2 20 1.2 83.3 G ... #AR_QIF
TLZI2070 TLSE ZIM2 596.848 90 1.2 58 1.2 35.6 R ... #AR_QIF
TLZI2070 TLSE ZIM2 596.848 210 1.2 78 1.2 62.9 GR ... #AR_QIF
WTZI2070 WTZR ZIM2 475.909 116 1.4 44 1.4 62.1 G ... #AR_QIF
WTZI2070 WTZR ZIM2 475.909 92 1.4 56 1.4 39.1 R ... #AR_QIF
WTZI2070 WTZR ZIM2 475.909 208 1.4 100 1.4 51.9 GR ... #AR_QIF
-------------------------------------------------------------- ... -------
Tot: 10 643.159 1158 1.1 364 1.2 68.6 G ... #AR_QIF
Tot: 8 601.283 762 1.1 424 1.2 44.4 R ... #AR_QIF
Tot: 10 643.159 1920 1.1 788 1.2 59.0 GR ... #AR_QIF
1
You may check the impact of introducing the ionosphere model (COD$YD+0 in Ionosphere models of
panel GPSEST 1.1: Input Files 1) by cleaning this input eld. Repeat the ambiguity resolution
(without saving the resolved ambiguities into the observation le: unmark option Save resolved am-
biguities in panel GPSEST 3.2: General Options 2) and compare the a posteriori RMS and the
number of resolved ambiguities.
Page 72 AIUB
5.4 Daily Goals
An analogue statistics can be produced for the short baseline ambiguity resolution. Ex-
change the entry for the input le selection (GPSEST/ADDNEQ output les) to catch all
les of the shape ${P}/INTRO/OUT/????$S+0_1.OUT. It is recommended to change also
the name of the resulting summary (Ambiguity res. summary) and the identication string
in the summary (e.g., L12 for Ambiguity resolution: #AR_ID) in panel GPSXTR 2: Output
Files .
File Sta1 Sta2 Length Before After Res Sys
(km) #Amb (mm) #Amb (mm) (%) ...
-------------------------------------------------------------- ... -------
WTWZ2070 WTZR WTZZ 0.002 108 1.2 16 1.3 85.2 G ... #AR_L12
WTWZ2070 WTZR WTZZ 0.002 94 1.2 20 1.3 78.7 R ... #AR_L12
WTWZ2070 WTZR WTZZ 0.002 202 1.2 36 1.3 82.2 GR ... #AR_L12
ZIZM2070 ZIM2 ZIMM 0.019 108 1.1 2 1.1 98.1 G ... #AR_L12
-------------------------------------------------------------- ... -------
Tot: 2 0.010 216 1.2 18 1.2 91.7 G ... #AR_L12
Tot: 1 0.002 94 1.2 20 1.3 78.7 R ... #AR_L12
Tot: 2 0.010 310 1.2 38 1.2 87.7 GR ... #AR_L12
The solutions from the BPE are identical to the two manually processed solutions. You
can compare the following two les for each strategy (e.g., with tkdiff):
Filenames from
Manual processing processed by the BPE
Strategy: QIF: GAJO207Q.OUT GAJO2070_Q.OUT
Strategy: direct L
1
/L
2
: WTWZ2071.OUT WTWZ2070_1.OUT
If you compare the number of ambiguity parameters in the GPSEST program output
with the number of ambiguities in the GPSXTR summary les, the number of reference
ambiguities that needs to be kept unresolved are considered.
5.4 Daily Goals
At the end of todays session, you should have:
1. used GPSEST for residual screening, created les: EDT10207. OUT ,
EDT10207. RES in your campaigns OUT directory,
2. screened the residual les from the above run using RESRMS: created les
RMS10207. SUM , RMS10207. LST , RMS10207. EDT , and RMS10207. OUT ,
3. used SATMRK to mark the identied outliers,
4. used GPSEST for a rst coordinate and troposphere estimation, created les:
FLT10207. CRD and FLT10207. TRP ,
5. used GPSEST for QIF ambiguity resolution, created les: GAJO207Q. OUT ,
6. used GPSEST for direct SIGMA ambiguity resolution, created les:
WTWZ2071. OUT ,
7. apply the ambiguity resolution to all baselines running a BPE,
8. used GPSXTR to create a summary of the ambiguity resolution, created le:
QIF10207. SUM
Proposal for Further Activities
Even if it is not needed for the processing progress of the regional network you may use
some time in this terminal session to have a look into the examples for Epoch Parameter
Processing (sections 7.2 for Kinematic Positioning and 7.3 for Zero Dierence Processing
for Clock Estimation).
Note that some panels assume the availability of the nal solution for regional network
processing (FIN$YD+0) that will be generated in the terminal session of tomorrow only. You
may replace these les by the results from the rst network solution before the ambiguity
resolution (FLT$YD+0) for this exercise.
Page 74 AIUB
6 Terminal Session: Thursday
Finish the work of yesterday by resolving the ambiguities for all baselines of all
four days. To save time you may do this for one day of each year (e.g. day 207
year 2010, and day 205 year 2011.
1. compute a nal network solution of the day (GPSEST),
2. check the coordinates of the ducial sites (ADDNEQ2, HELMR1),
3. check the daily repeatability (COMPAR),
4. recompute nal solution and generate reduced size normal equation les
(ADDNEQ2),
5. (optional) compute velocities (ADDNEQ2),
for all four days of the processing example. Compare the nal coordinate results
of the daily solutions.
6.1 Final Network Solution
The resolved ambiguities may be introduced from the Bernese observation les into the
nal network solution. To start the program GPSEST in the session mode you have to
select all single dierence les of the corresponding session. In panel GPSEST 1.1: Input
Files 1:
If the grid les for the coecients of the VMF1 are available (downloaded from
http://ggosatm.hg.tuwien.ac.at/DELAY/GRID/VMFG/ and the ve grid les of the
Page 75
day are concatenated), we can introduce them into panel GPSEST 1.1: Input
Files 1.
We do not introduce Troposphere estimates anymore from the previous solutions.
In panel GPSEST 2.1: Output Files 1 we request the normal equation le as the only output
le.
Page 76 AIUB
For the nal run of GPSEST we consider the correlations between the observations cor-
rectly:
If the VMF1 grid les are available we can switch now from DRY_GMF to DRY_VMF to use
the VMF1 instead of the Global Mapping Function (GMF). In the Bernese Introductory
Course environment these les are available. Remember that you need to specify the grid
les with the coecients in the input eld Gridded VMF1 coecients in panel GPSEST 1.1:
Input Files 1.
Ambiguities which have been resolved in the previous runs of program GPSEST are intro-
duced as known.
The checkbox in option Stop program after NEQ saving reduces the task of GPSEST only
to setup the NEQ but not to solve it. This may save a lot of computing time because the
solution for the session will be computed later on by ADDNEQ2 anyhow.
Since this is the nal run of GPSEST, it is worthwhile to add some additional information
about the observation les into the program output. This is useful if you archive the
program output of this run together with the observation les and the resulting normal
equation les.
We do not x any stations on their a priori position, i.e., the coordinates of all stations will
be estimated. This retains the exibility for later changes in the realization of the reference
frame (station constraints) with program ADDNEQ2. Because no solution in GPSEST is
computed you can select here all types of datum denition apart from Coordinates xed
(the normal equations are always stored without any constraints):
Page 78 AIUB
The unresolved ambiguities are preeliminated. In addition we may setup additional
parameters of interest.
The selection of the mapping function has to be consistent with the selection of the tro-
posphere model in ZPD model and mapping function (GNSS) in panel GPSEST 3.2: General
Options 2.
The output of the GPSEST contains only the input parameter and ends with the parameter
statistics:
--------------------
-----------------------------
------------------------------------------------------------------------------------------ ...
AMBIGUITIES 668 668 (BEFORE INV) 780 ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
-------------------------------
------------------------------------------------------------------------------------------ ...
PHASE L3 ALL 73606
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
SOLUTION SKIPPED ...
-----------------------------------------------------------------
>>> CPU/Real time for pgm "GPSEST": 0:01:03.110 / 0:01:03.286
After running GPSEST in session mode for all four days of the example the following normal
equation les should be available in the directory ${P}/INTRO/SOL
FIX10207.NQ0, FIX10208.NQ0, and
FIX11205.NQ0, FIX11206.NQ0.
In the environment of the Bernese Introductory Course these les are provided in
the archive ${S}/RNX2SNX/2010/SOL/ and ${S}/RNX2SNX/2011/SOL/ respectively. If
you did not processed all four days so far you may copy these les into your cam-
paign.
6.2 Check the Coordinates of the Fiducial Sites
To check the consistency of our network solution with respect to the coordinates available
in the IGb08 reference frame we generate a minimum constraint solution for the network
using program ADDNEQ2 ("Menu>Processing>Combine normal equation systems") with the following
options:
No further input les in the next panel are needed.
Page 80 AIUB
A troposphere SINEX le may be generated in this solution by adding an output le-
name to the Troposphere estimates (SINEX) input eld in panel ADDNEQ2 2.1: Output
Files 1.
In the following three panels, all parameter types supported by ADDNEQ2 are listed. You
may specify whether a parameter shall be pre-eliminated or not. An empty entry means
that the parameter is not expected in the input NEQ les.
Please note that an automated preselection is not possible for technical reasons. If a
parameter with an empty input eld is detected in the input NEQ les, the program will
stop with an error. In the opposite case, a warning message is issued.
For the validation of the datum stations we choose the Minimum constraint solution. Because
it is a regional network, we only apply the notranslation condition. The other conditions
are suciently dened by the satellite orbits.
Page 82 AIUB
The following panel allows to change the parameter spacing. We do not need this feature
at the moment and leave, therefore, all input elds empty.
The relative constraints applied to the vertical troposphere and gradient parameters are
so loose that they do not aect the solution. As in GPSEST, they simply protect a format
overow in the output troposphere le in case of very weakly observed parameters due to
gaps in the observation scenario.
The ADDNEQ2 program output starts with some information about the parameters con-
tained in the input NQ0 le(s). The input options for the program run follow. An important
part is the statistics for the current ADDNEQ2 solution:
...
SUMMARY OF RESULTS
------------------
Number of parameters:
--------------------
Parameter type Adjusted explicitly / implicitly Deleted
------------------------------------------------------------------------------------------ ...
Station coordinates / velocities 39 39 0 0 ...
Site -specific troposphere parameters 377 377 0 0 ...
------------------------------------------------------------------------------------------ ...
Previously pre -eliminated parameters 651 651
------------------------------------------------------------------------------------------ ...
Total number 1067 416 651 0
...
...
Statistics:
----------
Total number of authentic observations 73606
Total number of pseudo -observations 341
Total number of explicit parameters 416
Total number of implicit parameters 651
Total number of observations 73947
Total number of adjusted parameters 1067
Degree of freedom (DOF) 72880
A posteriori RMS of unit weight 0.00115 m
Chi **2/ DOF 1.32
Total number of observation files 12
Total number of stations 13
Total number of satellites 0
...
Below this part the program output reports the results of the parameter estimation in a
standardized format for all parameter types:
...
Station coordinates and velocities:
----------------------------------
Sol Station name Typ Correction Estimated value RMS error A priori value ... Abb
------------------------------------------------------------------------------------- ... ----
1 GANP 11515 M001 X 0.00117 3929181.42075 0.00055 3929181.41958 ... #CRD
1 GANP 11515 M001 Y -0.00077 1455236.82279 0.00027 1455236.82356 ... #CRD
1 GANP 11515 M001 Z 0.00657 4793653.95114 0.00066 4793653.94457 ... #CRD
1 HERT 13212 M010 X -0.00028 4033460.84981 0.00058 4033460.85009 ... #CRD
1 HERT 13212 M010 Y -0.00045 23537.89131 0.00020 23537.89176 ... #CRD
1 HERT 13212 M010 Z 0.00197 4924318.31814 0.00062 4924318.31618 ... #CRD
1 JOZ2 12204 M002 X 0.00226 3664880.47860 0.00047 3664880.47635 ... #CRD
1 JOZ2 12204 M002 Y 0.00122 1409190.67895 0.00023 1409190.67774 ... #CRD
1 JOZ2 12204 M002 Z 0.00266 5009618.53320 0.00057 5009618.53054 ... #CRD
1 LAMA 12209 M001 X -0.00516 3524522.82700 0.00055 3524522.83217 ... #CRD
...
Site -specific troposphere parameters:
------------------------------------
Station name Typ Correction Estimated value RMS error A priori value ... Abb
------------------------------------------------------------------------------------- ... ----
GANP 11515 M001 N -0.00038 -0.00038 0.00007 0.00000 ... #TRP
GANP 11515 M001 E 0.00009 0.00009 0.00009 0.00000 ... #TRP
GANP 11515 M001 U 0.13637 2.25048 0.00134 2.11411 ... #TRP
GANP 11515 M001 U 0.13105 2.24538 0.00101 2.11433 ... #TRP
GANP 11515 M001 U 0.13337 2.24792 0.00095 2.11456 ... #TRP
GANP 11515 M001 U 0.13971 2.25449 0.00097 2.11478 ... #TRP
GANP 11515 M001 U 0.13540 2.25040 0.00085 2.11500 ... #TRP
GANP 11515 M001 U 0.13552 2.25074 0.00098 2.11522 ... #TRP
GANP 11515 M001 U 0.13119 2.24663 0.00095 2.11545 ... #TRP
GANP 11515 M001 U 0.13392 2.24975 0.00082 2.11584 ... #TRP
GANP 11515 M001 U 0.13232 2.24854 0.00089 2.11623 ... #TRP
GANP 11515 M001 U 0.13391 2.25053 0.00084 2.11662 ... #TRP
GANP 11515 M001 U 0.13336 2.25037 0.00083 2.11701 ... #TRP
GANP 11515 M001 U 0.13709 2.25449 0.00083 2.11740 ... #TRP
GANP 11515 M001 U 0.14045 2.25825 0.00077 2.11779 ... #TRP
GANP 11515 M001 U 0.14172 2.25980 0.00086 2.11809 ... #TRP
GANP 11515 M001 U 0.13817 2.25655 0.00103 2.11838 ... #TRP
GANP 11515 M001 U 0.13784 2.25651 0.00096 2.11867 ... #TRP
GANP 11515 M001 U 0.13340 2.25237 0.00101 2.11897 ... #TRP
GANP 11515 M001 U 0.13867 2.25793 0.00092 2.11926 ... #TRP
GANP 11515 M001 U 0.13912 2.25867 0.00088 2.11955 ... #TRP
GANP 11515 M001 U 0.13974 2.25935 0.00088 2.11960 ... #TRP
GANP 11515 M001 U 0.13954 2.25919 0.00101 2.11965 ... #TRP
GANP 11515 M001 U 0.13492 2.25462 0.00102 2.11970 ... #TRP
GANP 11515 M001 U 0.14121 2.26096 0.00094 2.11975 ... #TRP
GANP 11515 M001 U 0.14091 2.26071 0.00107 2.11980 ... #TRP
GANP 11515 M001 N 0.00021 0.00021 0.00007 0.00000 ... #TRP
GANP 11515 M001 E 0.00082 0.00082 0.00009 0.00000 ... #TRP
GANP 11515 M001 U 0.13840 2.25825 0.00140 2.11985 ... #TRP
HERT 13212 M010 N -0.00102 -0.00102 0.00007 0.00000 ... #TRP
HERT 13212 M010 E -0.00226 -0.00226 0.00010 0.00000 ... #TRP
HERT 13212 M010 U 0.20556 2.50946 0.00162 2.30390 ... #TRP
HERT 13212 M010 U 0.19813 2.50203 0.00095 2.30390 ... #TRP
...
Page 84 AIUB
The coordinate solution for the session (${P}/INTRO/STA/FIN10207.CRD) may be com-
pared with the a priori coordinates for the IGS core sites. The program HELMR1 ("Menu
>Service>Coordinate tools>Helmert transformation") is used for this purpose:
For our example we get the following output. The Mag for some stations indicates that
they are not used to compute the transformation parameters. For these sites, only the
residuals are printed to the program output.
===============================================================================
Bernese GNSS Software , Version 5.2
-------------------------------------------------------------------------------
Program : HELMR1
Purpose : Helmert Transformation
-------------------------------------------------------------------------------
Campaign : ${P}/INTRO
Default session: 2070 year 2010
Date : 21-Aug -2014 17:05:17
User name : bern52
===============================================================================
EXAMPLE: Session 102070: Check fiducial coordinates
-------------------------------------------------------------------------------
FILE 1: EXAMPLE.CRD: IGb08 coordinates
FILE 2: FIN10207.CRD: EXAMPLE: Session 102070: Final coordinate/troposphere res
RESIDUALS IN LOCAL SYSTEM (NORTH , EAST , UP)
---------------------------------------------------------------------
| NUM | NAME | FLG | RESIDUALS IN MILLIMETERS | |
---------------------------------------------------------------------
| | | | | |
| 71 | GANP 11515 M001 | P A | -3.50 0.96 -5.65 | M |
| 89 | HERT 13212 M010 | I W | -1.55 0.39 -1.26 | |
| 106 | JOZ2 12204 M002 | I W | 0.11 -0.82 -3.59 | |
| 123 | LAMA 12209 M001 | P A | -5.03 -1.34 1.83 | M |
| 136 | MATE 12734 M008 | I W | 2.68 0.84 -1.63 | |
| 174 | ONSA 10402 M004 | I W | -1.15 -1.19 -0.43 | |
| 193 | PTBB 14234 M001 | P A | -5.09 0.73 -0.13 | M |
| 236 | TLSE 10003 M009 | I W | 0.55 -0.13 3.32 | |
| 258 | WSRT 13506 M005 | I W | -1.06 1.25 1.69 | |
| 259 | WTZR 14201 M010 | I W | 0.32 0.15 1.22 | |
| 260 | WTZZ 14201 M014 | P A | 7.00 -0.28 -6.33 | M |
| 270 | ZIM2 14001 M008 | P A | 7.72 0.43 -0.54 | M |
| 272 | ZIMM 14001 M004 | I W | 0.10 -0.50 0.69 | |
| | | | | |
---------------------------------------------------------------------
| | RMS / COMPONENT | | 1.33 0.83 2.18 | |
| | MEAN | | -0.00 -0.00 -0.00 | |
| | MIN | | -1.55 -1.19 -3.59 | |
| | MAX | | 2.68 1.25 3.32 | |
---------------------------------------------------------------------
NUMBER OF PARAMETERS : 3
NUMBER OF COORDINATES : 24
RMS OF TRANSFORMATION : 1.55 MM
BARYCENTER COORDINATES:
LATITUDE : 49 23 24.75
LONGITUDE : 9 45 16.60
HEIGHT : -43.098 KM
PARAMETERS:
TRANSLATION IN N : 0.00 +- 0.55 MM
TRANSLATION IN E : 0.00 +- 0.55 MM
TRANSLATION IN U : -0.00 +- 0.55 MM
NUMBER OF ITERATIONS : 1
NO OUTLIER DETECTED
-----------------------------------------------------------------
>>> CPU/Real time for pgm "HELMR1": 0:00:00.010 / 0:00:00.010
Page 86 AIUB
6.3 Check the Daily Repeatability
We can conclude that no problems concerning the stations used for the datum denition
were detected.
If there were problems, the ADDNEQ2 run needs to be repeated with the problematic
station either removed from the le ${P}/INTRO/STA/IGB08.FIX or with manual selection
of the stations used for the datum denition in panel ADDNEQ2 5.1: Datum Denition for
Station Coordinates.
6.3 Check the Daily Repeatability
If the minimum constraint solutions of the four sessions are available, the repeatability
of the coordinate solutions may be checked using the program COMPAR ("Menu>Service
>Coordinate tools>Coordinate comparison").
The program computes the arithmetic mean for all station coordinates. The dierence of
each individual coordinate set to this mean value and the overall RMS are reported in the
following section of the program output:
NUM STATION #FIL C RMS 1 2 3 4
------------------------------------------------------------
71 GANP 11515 M001 4 N 8.47 -6.77 -7.87 6.95 7.69
E 11.51 -9.89 -10.03 10.55 9.37
U 2.45 1.20 1.99 0.35 -3.54
89 HERT 13212 M010 4 N 8.73 -7.34 -7.77 7.50 7.61
E 9.47 -8.70 -7.67 8.05 8.33
U 3.30 -2.59 -0.45 -1.73 4.77
106 JOZ2 12204 M002 4 N 8.08 -6.81 -7.17 7.09 6.90
E 12.48 -10.36 -11.25 11.03 10.58
U 3.77 2.46 3.94 -2.67 -3.74
123 LAMA 12209 M001 4 N 8.38 -7.25 -7.22 6.44 8.02
E 11.80 -10.32 -10.11 10.20 10.23
U 2.61 2.91 0.71 -0.22 -3.39
136 MATE 12734 M008 4 N 11.67 -10.26 -9.91 10.88 9.29
E 13.91 -11.89 -12.19 11.80 12.29
U 1.76 -0.32 -0.28 2.41 -1.81
174 ONSA 10402 M004 4 N 8.18 -7.03 -7.10 6.31 7.82
E 10.30 -8.67 -9.15 8.52 9.30
U 4.37 -2.75 -4.30 5.30 1.74
193 PTBB 14234 M001 4 N 9.07 -6.96 -8.70 8.03 7.63
E 11.35 -9.75 -9.91 9.52 10.14
U 1.55 -1.83 0.36 -0.40 1.88
236 TLSE 10003 M009 4 N 9.21 -8.58 -7.34 7.65 8.27
E 11.39 -10.13 -9.58 9.63 10.09
U 2.18 -0.65 -2.70 0.98 2.37
258 WSRT 13506 M005 4 N 9.76 -8.36 -8.54 8.87 8.03
E 10.30 -8.69 -9.15 8.85 8.98
U 2.14 0.68 -1.48 -1.91 2.72
259 WTZR 14201 M010 4 N 8.99 -7.84 -7.73 7.52 8.05
E 11.43 -10.13 -9.66 9.58 10.21
U 2.22 0.31 2.55 -0.02 -2.85
260 WTZZ 14201 M014 4 N 8.91 -7.69 -7.73 7.34 8.08
E 13.18 -11.43 -11.39 11.00 11.82
U 2.35 -2.97 -0.07 2.78 0.26
270 ZIM2 14001 M008 4 N 9.40 -7.99 -8.27 7.63 8.63
E 11.46 -9.86 -9.99 9.86 9.99
U 1.05 -1.36 -0.29 0.73 0.92
272 ZIMM 14001 M004 4 N 9.46 -8.20 -8.18 8.31 8.08
E 10.97 -9.55 -9.44 9.68 9.31
U 0.36 0.38 -0.27 0.23 -0.35
------------------------------------------------------------
While interpreting this output, keep in mind that the rst two columns and the last two
columns refer to dierent epochs (see warning message). The dierence between these
epochs is about one year. Obviously, station velocities need to be estimated (this will be
done in the next step described in Section 6.5).
Page 88 AIUB
6.4 Compute the Reduced Solution of the Sessions
If reliable velocities for all stations are available they can be introduced:
You may check the inuence on the repeatability by your own.
This output may be used for quality assessment. Stations with a problem in one
or more sessions can be identied and excluded from the nal ADDNEQ2 solution by
adding them to section TYPE 003: STATION PROBLEMS in the station information le
(${P}/INTRO/STA/EXAMPLE.STA). All parameters of these stations will be preeliminated
before the normal equations are stacked and, therefore, also before the solution is com-
puted.
If one or more stations have to be excluded from the session solution or if the datum
denition of the solution is still not acceptable, the nal solution of the session has to be
recomputed by repeating the ADDNEQ2 in Section 6.2. Finally, the result les for the
nal solution of the session are:
${P}/INTRO/SOL/FIN$YD+0.NQ0,
${P}/INTRO/STA/FIN$YD+0.CRD, and
${P}/INTRO/ATM/FIN$YD+0.TRP.
It is preferable for the velocity estimation to have smaller normal equation les containing
only the coordinate parameters for each session. In addition, we generate a coordinate
Solution INdependent EXchange format (SINEX) le (in NEQ representation) as the nal
solution of the day, so the troposphere parameters have to be preeliminated before the
solution is computed. We introduce the station coordinates (${P}/INTRO/STA/FIN$YD+
0.CRD) obtained with the minimum constraint solution in the previous run of ADDNEQ2
and constrain the solution to these coordinates.
To generate these reduced NQ0 les and the SINEX le, the execution of ADDNEQ2 has
to be repeated with the following changes in the input options:
Please note that the output SINEX le includes a skeleton from ${X}/GEN/SINEX. . We
propose to derive individual SINEX skeletons for dierent tasks that you can include a
specic description how the product has been generated. The skeleton is provided in the
input eld SINEX general input le in panel ADDNEQ2 1.3: General Files.
Page 90 AIUB
Because you are storing a SINEX le in NEQ representation (see option Content of SINEX)
no regularization is necessary.
The troposphere parameters are preeliminated:
To keep the a priori and estimated sets of coordinates in the resulting SINEX le consistent,
we introduce the coordinate solution of the session in Station coordinates in ADDNEQ2 1.1:
Input Files 1 and constrain all coordinate parameters to these values.
The normal equation le (${P}/INTRO/SOL/RED10207.NQ0) contains only the station co-
ordinate parameters. The following section of the program output documents the pre
elimination of the troposphere parameters:
...
SUMMARY OF RESULTS
------------------
Number of parameters:
--------------------
Parameter type Adjusted explicitly / implicitly
------------------------------------------------------------------------------------------ ...
Station coordinates / velocities 39 39 0 ...
Site -specific troposphere parameters 377 0 377 (before st ...
------------------------------------------------------------------------------------------ ...
Previously pre -eliminated parameters 651 651
------------------------------------------------------------------------------------------ ...
Total number 1067 39 1028
...
...
Statistics:
----------
Total number of authentic observations 73606
Total number of pseudo -observations 377
Total number of explicit parameters 39
Total number of implicit parameters 1028
Total number of observations 73983
Total number of adjusted parameters 1067
Degree of freedom (DOF) 72916
A posteriori RMS of unit weight 0.00115 m
Chi **2/ DOF 1.32
Total number of observation files 12
Total number of stations 13
Total number of satellites 0
...
You can also see that the number of explicit parameters in the NQ0 le was dramatically
reduced (from 416 to 39). This is an advantage for the combination of a big number of
normal equation les for the estimation of station velocities.
Page 92 AIUB
6.5 Velocity Estimation
The velocity estimation in program ADDNEQ2 is easy. Introduce the normal equation
les containing only the station coordinate parameters. The normal equation les have to
cover a reasonable time interval to reliably estimate velocities (in this case one year)
a
:
Station velocities are set up by marking the checkbox:
a
If you have not been nished the processing of the four days in the Bernese Introductory Course environ-
ment you may copy the necessary les from ${S}/RNX2SNX/2010/SOL/RED10*NQ0 and ${S}/RNX2SNX/
2011/SOL/RED11*NQ0 into ${P}/INTRO/SOL/ directory.
Furthermore, we check the repeatability of the daily solutions after the velocity estimation.
The coordinates in the resulting le will refer to the epoch 2005 01 01.
The input NEQ les do only contain coordinates:
The realization of the geodetic datum is done for positions and velocities separately in the
following panels:
Page 94 AIUB
The following panel provides options to detect bad daily solutions based on the repeata-
bility:
After the velocity estimation the repeatability of the coordinate solutions from the indi-
vidual normal equations look like:
...
Helmert Transformation Parameters With Respect to Combined Solution:
-------------------------------------------------------------------
Translation (m) Rotation (")
Sol Rms (m) X Y Z X Y Z Scale (ppm)
-----------------------------------------------------------------------------
1 0.00060 0.0002 0.0000 0.0001 ---- ---- ---- ----
2 0.00058 -0.0002 -0.0000 -0.0001 ---- ---- ---- ----
3 0.00105 -0.0003 -0.0001 -0.0001 ---- ---- ---- ----
4 0.00101 0.0003 0.0001 0.0001 ---- ---- ---- ----
Statistics of individual solutions:
----------------------------------
File RMS (m) DOF Chi **2/ DOF #Observations authentic ...
------------------------------------------------------------------ ...
1 0.00115 72883 1.32 73944 ...
2 0.00121 72877 1.46 73859 ...
3 0.00123 75380 1.51 76338 ...
4 0.00122 75401 1.48 76413 ...
Comparison of individual solutions:
----------------------------------
GANP 11515 M001 N 0.41 0.44 -0.45 -0.25 0.20
GANP 11515 M001 E 0.51 0.06 -0.04 0.62 -0.62
GANP 11515 M001 U 1.38 -0.19 0.25 1.78 -1.57
HERT 13212 M010 N 0.11 0.09 -0.11 0.08 -0.10
HERT 13212 M010 E 0.42 -0.48 0.46 -0.21 0.19
HERT 13212 M010 U 2.95 -0.89 0.89 -3.48 3.53
JOZ2 12204 M002 N 0.21 0.07 -0.06 0.24 -0.26
JOZ2 12204 M002 E 0.40 0.43 -0.41 0.26 -0.27
JOZ2 12204 M002 U 0.51 -0.55 0.59 0.28 -0.25
LAMA 12209 M001 N 0.52 -0.13 0.15 -0.62 0.62
LAMA 12209 M001 E 0.11 -0.13 0.13 0.03 -0.02
LAMA 12209 M001 U 1.50 1.29 -1.25 1.32 -1.32
MATE 12734 M008 N 0.76 -0.25 0.25 0.90 -0.90
MATE 12734 M008 E 0.21 0.14 -0.14 -0.23 0.21
MATE 12734 M008 U 1.50 0.15 -0.20 1.89 -1.76
ONSA 10402 M004 N 0.48 -0.09 0.12 -0.58 0.59
ONSA 10402 M004 E 0.38 0.25 -0.24 -0.39 0.41
ONSA 10402 M004 U 1.47 0.96 -0.93 1.55 -1.53
PTBB 14234 M001 N 0.68 0.74 -0.76 0.36 -0.35
PTBB 14234 M001 E 0.27 0.09 -0.09 -0.32 0.32
PTBB 14234 M001 U 1.37 -0.93 0.91 -1.43 1.37
TLSE 10003 M009 N 0.60 -0.73 0.69 -0.21 0.20
TLSE 10003 M009 E 0.29 -0.25 0.21 -0.29 0.27
TLSE 10003 M009 U 1.28 1.26 -1.21 -0.97 0.96
WSRT 13506 M005 N 0.47 -0.02 0.04 0.62 -0.53
WSRT 13506 M005 E 0.22 0.26 -0.25 -0.06 0.12
WSRT 13506 M005 U 2.34 1.27 -1.24 -2.75 2.40
WTZR 14201 M010 N 0.17 -0.17 0.16 -0.12 0.13
WTZR 14201 M010 E 0.32 -0.23 0.23 -0.33 0.30
WTZR 14201 M010 U 1.21 -0.96 0.92 1.20 -1.08
WTZZ 14201 M014 N 0.20 -0.09 0.09 -0.22 0.24
WTZZ 14201 M014 E 0.33 -0.02 0.02 -0.40 0.40
WTZZ 14201 M014 U 1.31 -1.29 1.24 1.01 -0.99
ZIM2 14001 M008 N 0.31 0.04 -0.03 -0.37 0.38
ZIM2 14001 M008 E 0.10 0.10 -0.08 -0.09 0.09
ZIM2 14001 M008 U 0.41 -0.35 0.32 -0.41 0.32
ZIMM 14001 M004 N 0.22 -0.12 0.11 0.24 -0.25
ZIMM 14001 M004 E 0.13 -0.04 0.03 0.13 -0.18
ZIMM 14001 M004 U 0.43 0.51 -0.53 -0.00 -0.04
Variance -covariance scaling factors:
-----------------------------------
Parameter type Component Scaling factor wrt RMS / variance DOF
------------------------------------------------------------------------------------------
Station coordinates N 1.42042 2.01759 52
Station coordinates E 1.29083 1.66625 52
Station coordinates U/vertical 1.51341 2.29042 52
Station coordinates Horizontal 1.35717 1.84192 104
Station coordinates All 1.41118 1.99142 156
------------------------------------------------------------------------------------------
Total 1.41118 1.99142 156
...
Page 96 AIUB
Below this table all bad daily solutions according to the settings in panel ADDNEQ2 7:
Comparison of Individual Solutions are summarized if bad daily solutions are detected. In this
example we have no additional section and, therefore, no outliers.
If you compare the velocities obtained for the two sites in Ktzting (WTZR and WTZZ)
and Zimmerwald (ZIM2 and ZIMM) you will nd small dierences:
...
----------------------------------
Reference epoch: 2005 -01 -01 00:00:00
Station name Typ A priori value Estimated value Correction RMS error ...
---------------------------------------------------------------------------------------- ...
...
WTZR 14201 M010 VX -0.01605 -0.01788 -0.00183 0.00050
VY 0.01713 0.01635 -0.00078 0.00021
VZ 0.01009 0.00800 -0.00209 0.00055
VU -0.00011 -0.00297 -0.00286 0.00071 ...
VN 0.01555 0.01566 0.00011 0.00022 ...
VE 0.02028 0.01992 -0.00035 0.00018 ...
...
WTZZ 14201 M014 VX -0.01605 -0.01463 0.00142 0.00055
VY 0.01713 0.02022 0.00309 0.00023
VZ 0.01009 0.01242 0.00233 0.00060
VU -0.00011 0.00301 0.00312 0.00078 ...
VN 0.01555 0.01551 -0.00004 0.00025 ...
VE 0.02028 0.02297 0.00269 0.00020 ...
...
...
ZIM2 14001 M008 VX -0.01353 -0.01329 0.00024 0.00057
VY 0.01807 0.01841 0.00034 0.00021
VZ 0.01205 0.01243 0.00038 0.00059
VU 0.00123 0.00170 0.00047 0.00078 ...
VN 0.01632 0.01637 0.00005 0.00024 ...
VE 0.01967 0.01998 0.00030 0.00020 ...
...
ZIMM 14001 M004 VX -0.01353 -0.01450 -0.00097 0.00084
VY 0.01807 0.01739 -0.00068 0.00028
VZ 0.01205 0.01120 -0.00085 0.00081
VU 0.00123 -0.00011 -0.00134 0.00112 ...
VN 0.01632 0.01650 0.00018 0.00033 ...
VE 0.01967 0.01913 -0.00054 0.00026 ...
...
You can constrain the velocity estimates for the pairs of receivers at one location in the sta-
tion information le. Copy the original station information le ${P}/INTRO/STA/EXAMPLE.
STA and add the following lines to part TYPE 004: STATION COORDINATES AND VE-
LOCITIES (ADDNEQ) of this copy.
TYPE 004: STATION COORDINATES AND VELOCITIES (ADDNEQ)
-----------------------------------------------------
REL. CONSTR. POSITION RELATIVE CONSTR. VELOCITY
STATION NAME 1 STATION NAME 2 ... EAST UP NORTH EAST UP
**************** **************** ... **.***** **.***** **.***** **.***** **.*****
WTZR 14201 M010 WTZZ 14201 M014 ... 0.00001 0.00001 0.00001
ZIM2 14001 M008 ZIMM 14001 M004 ... 0.00001 0.00001 0.00001
(Pay attention to the number of blank lines before the next section
starts.)
When introducing this information, the program ADDNEQ2 will issue the following mes-
sage:
### SR AOPTNET: You are going to use relative constraints for station
coordinates/velocities from station info file.
Please keep in mind that you will NOT constrain the
estimated results but only the improvements of the
apriori values.
If only the improvements (column Correction) for the velocities are constrained, you must
make sure that also the a priori values (column A priori value) for the velocities are identical
to obtain (column Estimated value) the same velocities for a group of stations. You can
verify this in the input velocity le ${P}/INTRO/STA/EXAMPLE.VEL:
...
253 WTZR 14201 M010 -0.01605 0.01713 0.01009 Ib08 EURA
254 WTZZ 14201 M014 -0.01605 0.01713 0.01009 NNR EURA
...
264 ZIM2 14001 M008 -0.01353 0.01807 0.01205 NNR EURA
266 ZIMM 14001 M004 -0.01353 0.01807 0.01205 Ib08 EURA
...
If this is not the case, you should unify the a priori values.
The relative constraining of the velocity estimates is conrmed in the section of the in-
put parameters (below the a priori coordinates and velocities) of the ADDNEQ2program
output:
...
Relative constraints between stations:
... relative constraints for velocities
Station names ... N (m/year) E (m/year) U (m/year)
----------------------------------------------- ... --------------------------------------
WTZR 14201 M010 WTZZ 14201 M014 ... 0.00001 0.00001 0.00001
ZIM2 14001 M008 ZIMM 14001 M004 ... 0.00001 0.00001 0.00001
Introducing this modied station information le instead of the original one you will get
the following estimates for the station velocities in Ktzting and Zimmerwald:
...
----------------------------------
Reference epoch: 2005 -01 -01 00:00:00
Station name Typ A priori value Estimated value Correction RMS error ...
---------------------------------------------------------------------------------------- ...
...
WTZR 14201 M010 VX -0.01605 -0.01657 -0.00052 0.00038
VY 0.01713 0.01797 0.00084 0.00016
VZ 0.01009 0.00983 -0.00026 0.00042
VU -0.00011 -0.00051 -0.00040 0.00055 ...
VN 0.01555 0.01561 0.00007 0.00017 ...
VE 0.02028 0.02122 0.00094 0.00014 ...
...
WTZZ 14201 M014 VX -0.01605 -0.01657 -0.00052 0.00038
VY 0.01713 0.01798 0.00085 0.00016
VZ 0.01009 0.00983 -0.00026 0.00042
VU -0.00011 -0.00051 -0.00040 0.00055 ...
VN 0.01555 0.01561 0.00007 0.00017 ...
VE 0.02028 0.02122 0.00094 0.00014 ...
...
Page 98 AIUB
...
ZIM2 14001 M008 VX -0.01353 -0.01391 -0.00038 0.00045
VY 0.01807 0.01778 -0.00029 0.00017
VZ 0.01205 0.01170 -0.00035 0.00046
VU 0.00123 0.00069 -0.00054 0.00062 ...
VN 0.01632 0.01638 0.00007 0.00019 ...
VE 0.01967 0.01943 -0.00024 0.00015 ...
...
ZIMM 14001 M004 VX -0.01353 -0.01391 -0.00038 0.00045
VY 0.01807 0.01778 -0.00029 0.00017
VZ 0.01205 0.01170 -0.00035 0.00046
VU 0.00123 0.00069 -0.00054 0.00062 ...
VN 0.01632 0.01638 0.00007 0.00019 ...
VE 0.01967 0.01943 -0.00024 0.00015 ...
...
The nal results are contained in the les ${P}/INTRO/STA/FINAL.CRD
EXAMPLE: Estimate final solution - coordinates and velocities 11-JAN -14 15:41
--------------------------------------------------------------------------------
LOCAL GEODETIC DATUM: IGb08 EPOCH: 2005 -01 -01 00:00:00
NUM STATION NAME X (M) Y (M) Z (M) FLAG
71 GANP 11515 M001 3929181.53149 1455236.74590 4793653.91343 A
89 HERT 13212 M010 4033460.90810 23537.80257 4924318.25472 W
106 JOZ2 12204 M002 3664880.60318 1409190.59773 5009618.51621 W
123 LAMA 12209 M001 3524522.94119 1329693.63397 5129846.37671 A
136 MATE 12734 M008 4641949.56717 1393045.42114 4133287.46492 W
174 ONSA 10402 M004 3370658.52877 711877.13353 5349786.93668 W
193 PTBB 14234 M001 3844059.95641 709661.31300 5023129.55136 A
236 TLSE 10003 M009 4627851.81499 119640.01796 4372993.54267 W
258 WSRT 13506 M005 3828735.86062 443304.95523 5064884.70493 W
259 WTZR 14201 M010 4075580.54964 931853.79219 4801568.13049 W
260 WTZZ 14201 M014 4075579.43019 931853.10674 4801569.04137 A
270 ZIM2 14001 M008 4331299.87666 567537.32521 4633133.72555 A
272 ZIMM 14001 M004 4331297.06556 567555.87986 4633133.93711 W
and ${P}/INTRO/STA/FINAL.VEL
EXAMPLE: Estimate final solution - coordinates and velocities 11-JAN -14 15:41
--------------------------------------------------------------------------------
NUM STATION NAME VX (M/Y) VY (M/Y) VZ (M/Y) FLAG PLATE
69 GANP 11515 M001 -0.01975 0.01387 0.00679 A EURA
87 HERT 13212 M010 -0.01030 0.01607 0.01155 W EURA
104 JOZ2 12204 M002 -0.02223 0.01458 0.00317 W EURA
121 LAMA 12209 M001 -0.02061 0.01401 0.00528 A EURA
134 MATE 12734 M008 -0.01955 0.01922 0.01533 W EURA
170 ONSA 10402 M004 -0.01202 0.01552 0.01327 W EURA
189 PTBB 14234 M001 -0.01526 0.01702 0.01044 A EURA
231 TLSE 10003 M009 -0.00938 0.01925 0.01353 W EURA
252 WSRT 13506 M005 -0.01521 0.01599 0.01066 W EURA
253 WTZR 14201 M010 -0.01657 0.01797 0.00983 W EURA
254 WTZZ 14201 M014 -0.01657 0.01798 0.00983 A EURA
264 ZIM2 14001 M008 -0.01391 0.01778 0.01170 A EURA
266 ZIMM 14001 M004 -0.01391 0.01778 0.01170 W EURA
6.6 Daily Goals
At the end of todays session, you should have:
1. used GPSEST to compute a nal solution of the day, created les:
FIX10207. OUT , FIX10207. NQ0 (for all sessions),
2. checked the coordinates of the ducial sites using ADDNEQ2 and
HELMR1, created les: FIN10207. CRD , FIN10207. TRP , FIN10207. OUT ,
and HLM10207. OUT ,
3. used COMPAR to check the daily repeatabilities, created le: COMPAR. OUT ,
4. used ADDNEQ2 to create a nal session solution, and reduced size NEQs,
created les: RED10207. NQ0 and RED10207. SNX ,
5. if possible, used ADDNEQ2 for velocity estimation, created les: FINAL. CRD
and FINAL. VEL ,
Page 100 AIUB
7 Additional Examples
In the previous terminal sessions you have estimated coordinates, velocities, and
troposphere parameters. This is the standard application of the Bernese GNSS
Software for most users.
If you have nished this work or if you want to follow more examples at home,
this document provides some suggestions to practice:
generation of a combined GPS/GLONASS orbit from IGS,
kinematic positioning for a station,
zero dierence processing to estimate clocks, and
simulation of GNSS observations.
7.1 Preparing Combined GPS and GLONASS IGSOrbits
In this section the dierences to the standard procedure using CODE products contain-
ing GPS and GLONASS orbits with respect to IGS products are demonstrated. The
IGS uses independent combination procedures for GPS and GLONASS orbits resulting in
two sets of precise orbit les. Thats why the orbits for the two GNSS rst need to be
merged.
On the opposite, CODE (and other AC) uses a rigorous combined multiGNSS processing
scheme, hence producing a single precise orbit le.
7.1.1 Prepare Pole Information
For the IGS precise orbit les (PRE) the consistent EOP need to be available in the ORB
directory (which is the case in the Bernese Introductory Course environment). As for
the use of CODE products in Sect. 3.1, the EOP information has to be converted from
the IERS/IGS standard format (le extension within the Bernese GNSS Software is IEP)
to the internal Bernese EOP format (le extension within the Bernese GNSS Software is
ERP) This is the task of the program POLUPD ("Menu>Orbits/EOP>Handle EOP files>Convert IERS
to Bernese Format"). Simply specify IGSrelated lenames other settings are analogue to
Sect. 3.1 .
Page 101
The messages
### PG POLUPD: NUTATION MODEL NOT SPECIFIED IN INPUT ERP FILE
USING NUTATION MODEL NAME : IAU2000R06
### PG POLUPD: SUBDAILY POLE MODEL NOT SPECIFIED IN INPUT ERP FILE
USING SUBDAILY POLE MODEL NAME : IERS2010
just inform you that the nutation and subdaily pole models from the les in the input
panel are written to the output le because no Bernese formatted ERP le was used as
input. This is dierent to importing the EOP from CODE products because here the
information on the nutation and sub daily pole model is also available in the international
format (with the extension IEP).
7.1.2 Merging Precise Orbit Files
Before we can prepare the orbits from the IGS for a combined GPS+GLONASS pro-
cessing we need to merge the two separate les IGS15941.PRE and IGL15941.PRE.
This is the task of the program CCPREORB ("Menu>Orbits/EOP>Concatenate/merge precise orbit
les"):
Page 102 AIUB
The resulting lename consists of the solution identier (First four characters) and the
session of the rst epoch (if Reference epoch for output les is empty). The reference
epoch may also be specied by the user as the above example shows. Using the input
options from above panel we expect the result le named as ${P}/INTO/ORB/GNSS2070.
PRE .
In the next panel you may specify the time window for which the satellite positions shall
be included in the resulting precise orbit le.
7.1.3 Generating Standard Orbit Files
The subsequent steps to create the socalled standard orbit les from precise orbit
les are again analogue to the standard procedure using CODE products as detailed in
Sect. 3.2 .
The rst step is the conversion into tabular orbit les (TAB) using the program PRETAB
("Menu>Orbits/EOP>Create tabular orbits"). The merged GPS/GLONASS precise orbit le is cho-
sen as input and IGSrelated output les are recommended.
It is important to enable the option Exclude sat. with accuracy code 0 if you process orbits
that are not provided by CODE (label COD).
The precise GLONASS orbit les from the IGS contain the GLONASS broadcast clock
information (instead of no clock corrections for GLONASS as in the CODE product
les). This leads to two dierences with respect to the use of the standard products
from CODE:
The messages on missing GLONASS satellites clocks are not displayed (at least not
for all GLONASS satellites).
Because the Bernese GNSS satellite clock les contain also clock corrections for
the GLONASS satellites, the program CODSPP may compute the intersystem bias
between IGSFtime scale (GPS satellite clocks in the IGS nal product les) and
GLONASS broadcast time system.
Both dierences have no impact on the obtained results.
For some days a message like this may appear:
SATELLITE : 1
FILE NUMBER: 1
FILE NAME : ${P}/INTRO/ORB/GNSS2080.PRE
Page 104 AIUB
It reports that for a specic satellite no clock information is provided in the IGS les. As
long as this message lists only a limited number of satellites, the synchronization of the
receiver clocks in CODSPP is still possible with the remaining satellites. It is therefore not
critical.
To generate the standard orbits (extension STD) from the tabular orbits the pro-
gram ORBGEN ("Menu>Orbits/EOP>Create/update standard orbits") has to be used. Introduce
the IGSrelated tabular orbit le together with the consistent ERP le (as well as
the consistent nutation, and the subdaily pole model in panel ORBGEN 1.1: General
Files):
The name of the resulting orbit le should also be related to IGS:
The other options can be used as given in Sect. 3.2. The resulting program output is
expected to look like
...
-------------------------------------------------------------------------------
RMS ERRORS AND MAX. RESIDUALS ARC NUMBER: 1 ITERATION: 4
-------------------------------------------------------------------------------
QUADRATIC MEAN OF O-C (M) MAX. RESIDUALS (M)
SAT #POS RMS (M) TOTAL RADIAL ALONG OUT RADIAL ALONG OUT
--- ---- ------- ----------------------------- --------------------
1 96 0.002 0.002 0.001 0.001 0.003 0.004 0.004 0.007
2 96 0.002 0.001 0.001 0.001 0.002 0.003 0.003 0.005
3 96 0.004 0.004 0.004 0.003 0.004 0.009 0.006 0.007
4 96 0.001 0.001 0.001 0.001 0.001 0.003 0.002 0.003
5 96 0.002 0.002 0.002 0.001 0.002 0.003 0.005 0.010
6 96 0.003 0.003 0.003 0.003 0.004 0.008 0.006 0.007
7 96 0.002 0.002 0.002 0.002 0.002 0.005 0.004 0.004
8 96 0.002 0.002 0.001 0.001 0.002 0.003 0.003 0.006
9 96 0.002 0.002 0.002 0.001 0.003 0.004 0.003 0.006
10 96 0.002 0.002 0.002 0.002 0.003 0.006 0.005 0.005
11 96 0.002 0.002 0.001 0.001 0.002 0.004 0.003 0.007
12 96 0.003 0.003 0.003 0.002 0.003 0.007 0.005 0.006
13 96 0.003 0.003 0.003 0.002 0.003 0.013 0.006 0.006
14 96 0.003 0.003 0.004 0.003 0.002 0.011 0.006 0.009
15 96 0.002 0.002 0.002 0.002 0.002 0.009 0.004 0.005
16 96 0.004 0.003 0.004 0.003 0.004 0.007 0.008 0.008
17 96 0.002 0.002 0.002 0.002 0.002 0.005 0.004 0.007
18 96 0.003 0.002 0.002 0.002 0.003 0.006 0.004 0.007
19 96 0.002 0.002 0.002 0.002 0.003 0.005 0.004 0.005
20 96 0.002 0.002 0.002 0.001 0.003 0.004 0.003 0.006
21 96 0.002 0.002 0.001 0.001 0.003 0.003 0.002 0.006
22 96 0.003 0.003 0.003 0.002 0.003 0.005 0.005 0.006
23 96 0.003 0.003 0.003 0.002 0.003 0.011 0.005 0.005
24 96 0.001 0.001 0.001 0.001 0.002 0.003 0.002 0.005
25 96 0.002 0.002 0.002 0.001 0.003 0.004 0.004 0.007
26 96 0.004 0.003 0.005 0.003 0.003 0.010 0.006 0.005
27 96 0.002 0.002 0.002 0.001 0.003 0.004 0.002 0.006
28 96 0.002 0.002 0.002 0.002 0.002 0.004 0.005 0.007
29 96 0.003 0.003 0.003 0.003 0.003 0.005 0.006 0.007
30 96 0.002 0.002 0.002 0.002 0.002 0.006 0.005 0.005
31 96 0.002 0.002 0.002 0.002 0.003 0.005 0.005 0.009
32 96 0.002 0.002 0.002 0.001 0.003 0.005 0.003 0.006
101 96 0.002 0.002 0.002 0.002 0.002 0.006 0.004 0.007
102 96 0.002 0.002 0.002 0.002 0.002 0.006 0.005 0.005
103 96 0.002 0.002 0.002 0.001 0.002 0.005 0.005 0.006
104 96 0.002 0.001 0.002 0.001 0.002 0.004 0.003 0.004
105 96 0.001 0.001 0.001 0.001 0.002 0.002 0.007 0.004
107 96 0.002 0.002 0.001 0.001 0.002 0.003 0.006 0.005
108 96 0.002 0.002 0.002 0.001 0.002 0.005 0.003 0.004
110 96 0.002 0.002 0.001 0.001 0.003 0.007 0.003 0.005
111 96 0.001 0.001 0.001 0.001 0.002 0.003 0.010 0.006
113 96 0.002 0.002 0.002 0.001 0.002 0.004 0.005 0.005
114 96 0.002 0.002 0.002 0.002 0.002 0.005 0.012 0.003
115 96 0.002 0.002 0.002 0.001 0.002 0.003 0.008 0.004
117 96 0.002 0.002 0.003 0.002 0.002 0.010 0.009 0.003
118 96 0.002 0.002 0.002 0.001 0.002 0.005 0.006 0.006
119 96 0.003 0.002 0.002 0.002 0.003 0.005 0.006 0.006
120 96 0.002 0.002 0.002 0.001 0.003 0.004 0.004 0.006
121 96 0.002 0.002 0.002 0.002 0.003 0.006 0.004 0.014
122 96 0.002 0.002 0.002 0.002 0.002 0.004 0.006 0.004
123 96 0.002 0.002 0.001 0.001 0.002 0.003 0.004 0.004
124 96 0.002 0.002 0.001 0.002 0.001 0.003 0.017 0.003
-------------------------------------------------------------------------------
...
The RMS error for the orbit t for precise IGS orbits should be below 5 mm (for older
orbits it may also achieve 10. . . 15 mm).
The le ${P}/INTRO/OUT/IGS10207.LST contains the same results as displayed on page 25
but contains also the GLONASS satellite orbits:
-------------------------------------------------------------------------------
----------------------------- ... ---------------------- ... ---------------------------- ...
ECL .. .. .. .. .. .. .. E. E. E. .. .. .. .. .. .. .. ..
DOY 1 2 3 4 5 6 ... 12 13 14 15 16 ... 32 101 102 103 104 105 107 ...
----------------------------- ... ---------------------- ... ---------------------------- ...
207 2 1 4 1 2 3 ... 3 3 3 2 3 ... 2 2 2 2 1 1 2 ...
----------------------------- ... ---------------------- ... ---------------------------- ...
ALL 2 1 4 1 2 3 ... 3 3 3 2 3 ... 2 2 2 2 1 1 2 ...
----------------------------- ... ---------------------- ... ---------------------------- ...
If you want to use these orbit les in the processing programs, you simply have to re-
place the CODErelated by the IGSrelated lenames for the standard orbit and EOP
les.
Page 106 AIUB
7.2 Kinematic Positioning
7.2.1 Estimating Kinematic Positions in a DoubleDierence Solution
The example campaign contains no really roving stations. You can, however, dene one
of them to be kinematic (e.g., station GANP). Introduce the coordinates from the nal
solution (\$\{P\}/INTRO/STA/FIN10207.CRD) for all other sites.
Remove the name of the resulting Normal equations le in panel GPSEST 2.1: Output Files 1
if there is any entry in this input eld. Store the kinematic coordinates in an output le
(Kinematic coordinates in panel GPSEST 2.2: Output Files 2).
Because the number of parameters for the kinematic positioning may become very
large, we select only a short data interval of one hour for this kinematic position-
ing:
Page 108 AIUB
The option Enable extended program output may be disabled now:
Fix all station coordinates apart from GANP in the panels GPSEST 4: Datum Denition for
Station Coordinates (choose MANUAL in panel GPSEST 4: Datum Denition for Station Coordi-
nates and select all stations except GANP in panel GPSEST 4.2).
Enable the kinematic coordinates option without any preelimination in a rst run:
An additional panel for options related to epoch parameters is displayed where you can
accept the default values:
Let us assume only horizontal movements for this site:
Page 110 AIUB
7.2.2 Extracting the Program Output from a Kinematic Positioning
As expected you will get only small estimates for the kinematic coordinates since GANP
was not moving:
KINEMATIC COORDINATES: ${P}/INTRO/STA/KIN10207.KIN
---------------------
EPO: EPOCHS SINCE 2010 -07 -26 02:00:00 (SAMPLING 300 SEC)
CORRECTION AND RMS IN METER ...
EPO EPOCH(MJD) #OBS STA LATITUDE LONGITUDE HEIGHT ...
---------------------------------------------------------------------------------------- ...
GANP 11515 M001 49 2 4.971317 20 19 22.574505 746.0157
1 55403.083333 15 GANP -0.0051 +- 0.004 -0.0037 +- 0.004 0.0000 +- 0.000 ...
2 55403.086806 14 GANP 0.0046 +- 0.004 -0.0047 +- 0.004 0.0000 +- 0.000 ...
3 55403.090278 14 GANP 0.0015 +- 0.004 -0.0005 +- 0.004 -0.0000 +- 0.000 ...
4 55403.093750 14 GANP 0.0003 +- 0.004 0.0013 +- 0.004 -0.0000 +- 0.000 ...
5 55403.097222 13 GANP -0.0028 +- 0.004 0.0015 +- 0.004 0.0000 +- 0.000 ...
6 55403.100694 13 GANP -0.0049 +- 0.004 0.0032 +- 0.004 0.0000 +- 0.000 ...
7 55403.104167 13 GANP -0.0035 +- 0.004 0.0025 +- 0.004 0.0000 +- 0.000 ...
8 55403.107639 13 GANP 0.0007 +- 0.005 0.0041 +- 0.004 -0.0000 +- 0.000 ...
9 55403.111111 14 GANP -0.0067 +- 0.005 0.0021 +- 0.004 0.0000 +- 0.000 ...
10 55403.114583 14 GANP -0.0033 +- 0.005 0.0034 +- 0.005 0.0000 +- 0.000 ...
11 55403.118056 14 GANP -0.0014 +- 0.005 0.0023 +- 0.005 0.0000 +- 0.000 ...
12 55403.121528 13 GANP -0.0054 +- 0.005 -0.0013 +- 0.005 -0.0000 +- 0.000 ...
With the program GPSXTR ("Menu>Processing>Program output extraction>Parameter
estimation/stacking") a comprehensive summary of the estimates for the kinematic solu-
tion can be extracted:
The resulting summary le looks like:
--------------------------------------------------------------------------------
*XEPO 12 0 12
*INI 0.0000 0.0000 0.0000
*EST 0.0000 0.0000 0.0000
*DIFXYZ 0.0000 0.0000 0.0000
*DIFNEU -0.0022 0.0009 0.0000
-------------------------------------------------------------------------------
EPOCH DN DE DU
1 -0.0051 -0.0037 0.0000
2 0.0046 -0.0047 0.0000
3 0.0015 -0.0005 -0.0000
4 0.0003 0.0013 -0.0000
5 -0.0028 0.0015 0.0000
6 -0.0049 0.0032 0.0000
7 -0.0035 0.0025 0.0000
8 0.0007 0.0041 -0.0000
9 -0.0067 0.0021 0.0000
10 -0.0033 0.0034 0.0000
11 -0.0014 0.0023 0.0000
12 -0.0054 -0.0013 -0.0000
-------------------------------------------------------------------------------
*AVG -0.0022 0.0009 0.0000
*SIG 0.0039 0.0028 0.0000
*RMS 0.0034 0.0028 0.0000
*RMSTC 0.0011
-------------------------------------------------------------------------------
STATION: GANP
PARAMS : 96 12 0 509 (AMB , CRD , CLK , TOT)
OBSERV : 0 1592 1592
The dierent components of the summary are described in the online help.
7.2.3 Further suggestions
Introduce the result le with kinematic coordinates as an input le for another run of
GPSEST. If the estimates become zero it is a conrmation that the le was correctly
considered as the a priori kinematic positions for the station GANP.
Use the preelimination EVERY_EPOCH for the Kinematic coordinates (they are back
substituded by the program in order to get a solution also for those parameters).
Compare the results with the rst solution.
Switch the Varcovar wrt epoch parameters in panel GPSEST 3.2: General Options 2
from SIMPLIFIED to CORRECT. Compare the results again with the rst solution.
Compute kinematic coordinates for the full day using the epochwise preelimination
and backsubstitution algorithm. To save computing power we recommend to sample
the data to 300 s.
Repeat the kinematic solution considering only one of the two GNSS at the time
(choose either GPS or GLONASS in option Satellite system of panel GPSEST 3.1:
General Options 1).
7.3 Zero Dierence Processing for Clock Estimation
For the clock estimation we have to use code and phase data together. The data is analyzed
at zero dierence level.
Page 112 AIUB
7.3.1 Preprocessing
There are two ways for preprocessing zero dierence observations in the Bernese GNSS
Software, Version 5.2 available:
Precise satellite clocks are available for all satellites with the same sampling as the
RINEX observations to be processed (typically 30 s):
1. RNXSMT to screen and smooth code measurements based on a consistency
check between the code and phase observations
2. RXOBV3 to import the screened smoothed code together with the original phase
data into Bernese observation le format
3. CODSPP to synchronize receiver clocks with respect to the GNSS system time
4. MAUPRP to screen the phase measurements
5. GPSEST, RESRMS, SATMRK to screen residuals from a zero dierence network
solution
Precise satellite clocks are not available:
1. RNXSMT to screen phase and code measurements based on a consistency check;
smooth the code observations
2. RXOBV3 to import the screened phase and smoothed code data into Bernese
observation le format
3. CODSPP to synchronize receiver clocks with respect to the GNSS system time
4. GPSEST, RESRMS, SATMRK to screen residuals from a zero dierence network
solution iteratively with a descreasing threshold
In this text book we follow the second approach.
The preprocessing of zero dierence data starts with program RNXSMT, available from
"Menu>RINEX>RINEX utilities>Clean/smooth observation les". In the rst panel select all RINEX les
of the active session:
The default input options perform well in most cases:
In the last panel it is decided whether to Preprocess phase observations or not by checking
the box, or not:
Page 114 AIUB
The resulting smoothed RINEX les look like usual RINEX les but the line
### PG RNXSMT: RINEX FILE CHANGED COMMENT
indicates that the numbers in the le result from RNXSMT. The S/N indicators have the
following meaning:
1 considered by RNXSMT as bad data
5 data have only been copied from the original le by RNXSMT
9 considered by RNXSMT as good data
The cycle slip ags in a smoothed RINEX le indicate the epochs/satellites where new
ambiguities are needed according to the evaluation of RNXSMT.
In order to import the smoothed RINEX observation les into the Bernese format you
have to select them in the rst input panel of program RXOBV3 (note that you will
overwrite your zero dierence observation les from the previous processing example by
doing this):
If you have preprocessed the phase measurementents already in RNXSMT you can resample
the observations already in RXOBV3: set the Sampling interval in panel RXOBV3 2: Input
Options 1, e.g., to 300 seconds.
Furthermore, you have to consider the SIGNAL STRENGTH REQUIREMENTS for smoothed
RINEX les (see above):
After importing the data into the Bernese format you have to repeat the receiver clock
synchronization with program CODSPP. The options are identical to the settings in Sec-
tion 4.2.1. The only dierence is the option Mark outliers in obs. les in the last input panel:
depending on your preprocessing chain it is recommended to select:
BOTH if you have screened phase and code data in RNXSMT, because it is assumed that
the corresponding phase measurement is also bad if a problematic code data record
has passed RNXSMT.
CODE if you have used RNXSMT to only screen and smooth code observations so far.
From problems in the code data cannot be deduced the quality of the corresponding
phase measurements.
If you have not yet cleaned the phase observations in RNXSMT (approach with pre-
cise highrate clocks available), you have to run MAUPRP now ("Menu>Processing>Phase
preprocessing"). You need for this purpose a precise satellite clock corrections for all satellites
and with the full sampling of 30 seconds (or even higher). Select Zero-dierence observation
les instead of Single-dierence observation les and introduce a consistent set of GNSS stan-
dard orbits, Pole le, and Satellite clocks in panel MAUPRP 1: Input Files. An additional
panel MAUPRP 7: Clock Events will be displayed (see online help for further details). It is
Page 116 AIUB
receommended to disable the cycle slip corrections by checking the box for option Do not
accept cycle slip corrections in panel MAUPRP 8: Cycle Slip Detection/Correction. All other
settings can remain as described in Section 4.2.3
. You may skip this step if you have

preprocessed the phase data already in RNXSMT.
7.3.2 Residual Screening
Now you are ready to run GPSEST ("Menu>Processing>Parameter estimation") in the zero dierence
mode to store resdiduals for screening. You also have to include a DCB le when processing
code observations.
In the subsequent two panels, the output les for residuals and clock estimates are specied:
Take care to specify Correlation strategy with CORRECT and to store NORMALIZED residuals
Page 118 AIUB
The options in the following panel are only relevant to zero dierence processing. They
dene, e.g., the source clocks used as a priori for satellites and receivers if more than one
potential source is available:
The datum denition shall be consider according to the information in the a priori coor-
dinate le given in panel GPSEST 1.1: Input Files 1:
Clock parameters are setup and preeliminated EVERY_EPOCH:
For the residual screening, a reduced set of troposphere parameters can be estimated:
Page 120 AIUB
The following panel asks for the options regarding the clock estimation. If you include
GLONASS you need to choose Rclk.o: Parameter setup dierent from NONE. See online
help for additional information.
The program output le should report the clock parameters:
...
--------------------
-----------------------------
------------------------------------------------------------------------------------------ ...
RECEIVER CLOCK BIASES / TIME BIASES 200 0 200 ...
EPOCH WISE STATION CLOCKS 3739 3739 (EPOCH -WISE) 3744 ...
EPOCH WISE SATELLITE CLOCKS 5842 5842 (EPOCH -WISE) 6059 ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
-------------------------------
------------------------------------------------------------------------------------------ ...
PHASE L3 ALL 54384
CODE L3 ALL 54393
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
------------------------------------------
CHI **2/ DOF : 2.38
...
The residuals are stored in the le ${P}/INTRO/OUT/CLK02143.RES. Use program RESRMS
("Menu>Service>Residual les>Create residual statistics") to screen for outliers bigger than 2 cm for
code and phase data (remember that code residuals are scaled to phase residuals 2 cm
in the input eld correspond to a 2 m threshold for code residuals):
Page 122 AIUB
Mark the corresponding code and phase zero dierence observations using program
SATMRK ("Menu>Service>Bernese observation les>Mark/delete observations":
Repeat the GPSESTrun and store again the residuals.
...
------------------------------------------
CHI **2/ DOF : 0.79
...
In the second iteration we screen for residuals bigger than 6 mm in RESRMS and mark
these observations with SATMRK, too.
If you have done the screening of phase observations in MAUPRP instead of RNXSMT you
can skip the rst iteration and you only need to run once through the residual screening
procedure (sequence of GPSEST, RESRMS, SATMRK) using the nal threshold for the
residuals of 6 mm.
7.3.3 Generate Clock Solutions
Repeat the run of GPSEST with the clean observation les to get the denitive clock
estimates. You may introduce the estimated coordinates and troposphere parameters
1
from the nal doubledierence solution for the session (e.g., FIN$YD+0). You also have
to include a DCB le when processing code observations.
1
If you introduce a troposphere result le based on VMF1, you also need to introduce the same Grid-
ded VMF1 coecients in panel GPSEST 1.1: Input Files 1 as you have used to generate the
Troposphere estimates.
Page 124 AIUB
Store also the coordinate results that correspond to the clock estimates.
In the nal run the clock results for satellites and receivers shall be stored in a Clock
RINEX result le in panel GPSEST 2.2: Output Files 2.
The input eld for ZPD model and mapping function (GNSS) in panel GPSEST 3.2: General
Options 2 is inactive because a le with Troposphere estimates is introduced. The same
troposphere model is used in this program run.
The datum denition shall be reconsidered when introducing a solution for the coordinates:
The sampling of troposphere parameters for those stations where you cannot introduce a
complete set of estimates in the le from Troposphere estimates given in panel GPSEST 1.2:
Input Files 2 shall be identical with those in the input le:
Page 126 AIUB
If you have selected a Clock RINEX result le in panel GPSEST 2.2: Output Files 2 you are
asked for the header information. Please replace the placeholders by the information for
your institution and give a description for your results.
...
-----------------------------
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
-------------------------------
------------------------------------------------------------------------------------------ ...
PHASE L3 ALL 54188
CODE L3 ALL 54390
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
------------------------------------------
CHI **2/ DOF : 0.65
...
The estimated interfrequency biases caused by dierent hardware delays in the receiver
for each GLONASS satellite due to the individual frequency are reported in the following
section in the program output:
...
RECEIVER CLOCKS / TIME BIASES:
-----------------------------
REQUEST STATION NAME OFFSET (USEC) RMS (NSEC)
----------------------------------------------------------------------------------------------
1 GANP 11515 M001 0.000000 --- 0.000000 --- SAT GPS
1 GANP 11515 M001 0.000000 -0.244907 -0.244907 0.135 SAT 101
1 GANP 11515 M001 0.000000 -0.251354 -0.251354 0.144 SAT 102
1 GANP 11515 M001 0.000000 -0.236973 -0.236973 0.153 SAT 103
1 GANP 11515 M001 0.000000 -0.229242 -0.229242 0.151 SAT 104
1 GANP 11515 M001 0.000000 -0.243823 -0.243823 0.129 SAT 105
1 GANP 11515 M001 0.000000 -0.241615 -0.241615 0.118 SAT 107
1 GANP 11515 M001 0.000000 -0.226129 -0.226129 0.131 SAT 108
1 GANP 11515 M001 0.000000 -0.250174 -0.250174 0.130 SAT 110
1 GANP 11515 M001 0.000000 -0.248058 -0.248058 0.129 SAT 111
1 GANP 11515 M001 0.000000 -0.249851 -0.249851 0.131 SAT 113
1 GANP 11515 M001 0.000000 -0.250245 -0.250245 0.130 SAT 114
1 GANP 11515 M001 0.000000 -0.245288 -0.245288 0.128 SAT 115
1 GANP 11515 M001 0.000000 -0.243093 -0.243093 0.133 SAT 117
1 GANP 11515 M001 0.000000 -0.249621 -0.249621 0.131 SAT 118
1 GANP 11515 M001 0.000000 -0.244722 -0.244722 0.131 SAT 119
1 GANP 11515 M001 0.000000 -0.243062 -0.243062 0.126 SAT 120
1 GANP 11515 M001 0.000000 -0.242500 -0.242500 0.113 SAT 121
1 GANP 11515 M001 0.000000 -0.250259 -0.250259 0.127 SAT 122
1 GANP 11515 M001 0.000000 -0.242287 -0.242287 0.149 SAT 123
1 GANP 11515 M001 0.000000 -0.242737 -0.242737 0.140 SAT 124
2 HERT 13212 M010 0.000000 --- 0.000000 --- SAT GPS
2 HERT 13212 M010 0.000000 0.065866 0.065866 0.131 SAT 101
2 HERT 13212 M010 0.000000 0.069644 0.069644 0.136 SAT 102
...
The report of the clock estimates looks like:
...
EPOCH WISE STATION CLOCKS: ${P}/INTRO/OUT/CLK10207.CLK
--------------------------
STATION CLOCK VALUES (USEC)
TYPE STAT EPOCH(MJD) A PRIORI CORRECTION TOTAL RMS(NSEC) #OBS STAT.
----------------------------------------------------------------------------------------------
23 1 55403.000000 -0.021195 0.000021 -0.021174 0.003 34 R # GANP
23 2 55403.000000 -0.002502 -0.000812 -0.003314 0.003 29 R # HERT
23 3 55403.000000 0.001765 -0.000196 0.001569 0.003 35 R # JOZ2
23 4 55403.000000 -0.000373 0.000180 -0.000193 0.003 35 R # LAMA
23 5 55403.000000 -0.027919 0.001131 -0.026788 0.003 30 R # MATE
23 6 55403.000000 -31.022105 -0.000123 -31.022228 0.003 30 R # ONSA
23 7 55403.000000 0.528880 0.000344 0.529225 0.005 11 R # PTBB
23 8 55403.000000 -0.035301 -0.000351 -0.035652 0.003 28 R # TLSE
23 9 55403.000000 0.138358 0.000244 0.138602 0.004 20 R # WSRT
23 10 55403.000000 -0.008743 -0.000340 -0.009083 0.003 33 R # WTZR
23 11 55403.000000 -219.054898 0.000225 -219.054673 0.004 18 R # WTZZ
23 12 55403.000000 -0.031312 -0.000150 -0.031462 0.003 30 R # ZIM2
23 13 55403.000000 0.028262 -0.000173 0.028089 0.004 18 R # ZIMM
23 1 55403.003472 -0.022298 0.000084 -0.022214 0.003 34 R # GANP
23 2 55403.003472 -0.000918 -0.000892 -0.001810 0.003 29 R # HERT
23 3 55403.003472 0.001663 -0.000150 0.001513 0.003 34 R # JOZ2
...
...
EPOCH WISE SATELLITE CLOCKS: ${P}/INTRO/ORB/CLK10207.CLK
----------------------------
SATELLITE CLOCK VALUES (USEC)
TYPE SAT EPOCH(MJD) A PRIORI CORRECTION TOTAL RMS(NSEC) #OBS
------------------------------------------------------------------------------------------
24 3 55403.000000 586.451514 -0.000475 586.451039 0.013 15
24 6 55403.000000 559.025665 0.001505 559.027170 4.093 1 *
24 9 55403.000000 20.468252 0.007585 20.475837 7.738 1 *
24 11 55403.000000 -78.075202 0.000860 -78.074343 0.002 26
24 14 55403.000000 71.688147 0.000898 71.689046 0.003 26
24 17 55403.000000 163.652097 0.000763 163.652860 0.010 22
24 19 55403.000000 -52.512921 0.000602 -52.512319 0.003 26
24 20 55403.000000 52.929104 0.000204 52.929308 0.004 26
24 22 55403.000000 166.687820 0.002015 166.689835 0.014 12
24 24 55403.000000 307.451136 0.000213 307.451349 0.007 25
Page 128 AIUB
24 28 55403.000000 -9.425636 0.000243 -9.425393 0.007 22
24 31 55403.000000 -21.952063 0.000400 -21.951663 0.084 2 *
24 32 55403.000000 -46.318216 0.000391 -46.317825 0.003 26
24 104 55403.000000 0.000000 -79.261441 -79.261441 7.817 1 *
24 105 55403.000000 0.000000 -153.329765 -153.329765 0.004 18
24 107 55403.000000 0.000000 -292.763000 -292.763000 0.011 18
24 113 55403.000000 0.000000 -276.613680 -276.613680 0.023 9
24 114 55403.000000 0.000000 -168.480117 -168.480117 0.010 15
24 115 55403.000000 0.000000 23.463570 23.463570 0.028 6
24 120 55403.000000 0.000000 -73.657589 -73.657589 0.004 18
24 121 55403.000000 0.000000 -200.316163 -200.316163 0.003 18
24 122 55403.000000 0.000000 -10.570535 -10.570535 0.006 18
24 3 55403.003472 586.452934 -0.001007 586.451927 0.015 13
24 6 55403.003472 559.021364 0.001906 559.023270 5.001 1 *
...
The character indicates satellites where the satellite clock correction has been com-
puted from a limited number of stations.
Because this section can become very long, it can also be skipped in the GPSEST pro-
gram output by checking the box Printing: Suppression of output concerning epoch param-
eters in panel GPSEST 3.2.1.1: Extended Program Output Options (enabled only if the
checkbox Enable extended program output in panel GPSEST 3.2: General Options 2 is
checked).
Dierences of clocks and Allan deviations for dierences of clocks can be extracted from the
GPSEST program output by the program GPSXTR ("Menu>Processing>Program output extraction
>Parameter estimation/stacking"). The pair of clocks (receiver or satellites) are dened by a
baseline le (extension BSL).
The baseline le might, e.g., be generated via the "Menu>Campaign>Edit station files>Baseline
denition le":
The clock solution is nalized by selecting the reference clock using program CCRNXC
("Menu>Service>Clock tools>Combine/manipulate clock RINEX les"):
Page 130 AIUB
The table at the end of the program output provides an overview of the clock quality:
...
REFERENCE CLOCK SELECTION FOR OUTPUT FILE
-----------------------------------------
Selected reference station: WTZR 14201 M010
...
STATISTICS ON THE CLOCKS IN THE OUTPUT FILE
-------------------------------------------
# per file rms of poly. fit (ns)
Clock name out 001 n = 0 n = 1 n = 2
-------------------------------------------------------------------
WTZR 14201 M010 288 288 1.473 0.000 0.000
WSRT 13506 M005 288 288 4.522 0.030 0.030
MATE 12734 M008 288 288 29.164 0.054 0.052
PTBB 14234 M001 288 288 0.398 0.058 0.043
ONSA 10402 M004 284 284 5.625 0.081 0.076
LAMA 12209 M001 288 288 2.928 2.933 2.932
JOZ2 12204 M002 288 288 3.062 3.067 3.069
HERT 13212 M010 288 288 3.317 3.322 3.328
ZIMM 14001 M004 288 288 4.277 4.091 3.833
TLSE 10003 M009 288 288 5.174 4.892 4.735
ZIM2 14001 M008 287 287 5.297 5.021 4.712
GANP 11515 M001 288 288 6.752 6.689 6.629
WTZZ 14201 M014 288 288 0.3E+06 0.3E+06 0.3E+06
G01 59 59 21.052 0.132 0.133
G02 113 113 53.422 0.141 0.125
G29 93 93 40.743 0.154 0.132
G18 111 111 42.206 0.159 0.160
G20 83 83 14.258 0.174 0.174
G07 105 105 3.159 0.186 0.141
G11 87 87 89.780 0.192 0.190
G19 103 103 91.491 0.192 0.137
G25 83 83 32.991 0.199 0.064
G13 86 86 10.746 0.220 0.173
G15 102 102 104.649 0.221 0.197
G23 98 98 32.848 0.228 0.111
G12 86 86 37.991 0.234 0.156
G14 111 111 111.496 0.240 0.235
G16 108 108 87.316 0.242 0.237
G31 113 113 71.218 0.264 0.160
G22 110 110 14.928 0.268 0.243
G21 102 102 45.147 0.289 0.253
G05 111 111 65.893 0.356 0.310
R02 98 98 44.931 0.370 0.271
G06 93 93 248.956 0.371 0.342
R13 103 103 22.465 0.377 0.343
R04 99 99 4.507 0.409 0.382
G32 87 87 299.992 0.419 0.270
R05 124 124 19.777 0.577 0.500
R19 100 100 20.052 0.590 0.313
...
7.3.4 Further suggestions
Switch the Var-covar wrt epoch parameters in panel GPSEST 6.7: General Options for
Epoch Parameters from SIMPLIFIED to CORRECT.
Compute a PPP for one of the stations in the zero dierence network solution.
Compare the coordinates and clocks from the PPP with the results from the net-
work solution. Exchange the orbits, EOP, and satellite clock corrections from your
solution by products from other sources (e.g., CODE or IGS).
Use the PPP approach to screen the residuals of the Bernese zero dierence ob-
servation les. This has to be done station by station. Make sure that you use a
consistent set of orbits, EOP, and satellite clocks (e.g., IGS nal products or CODE
nal solution).
Page 132 AIUB
7.4 Simulation of GNSS Observations
The Bernese GNSS Software provides the simulation tool GPSSIM ("Menu>Service>Generate
simulated observation data"). It generates synthetic GNSS (i.e., GPS and GLONASS) obser-
vations for terrestrial static or kinematic stations as well as for LEO. Code and phase
zero dierence observation les can be created based on an observation scenario dened
by
GNSS satellite geometry given by a standard orbit and
a set of receivers with positions from a coordinate le, kinematic positions, or a LEO
standard orbit le.
7.4.1 Simulation of GNSS Observations
It is important that you remove all previously existing observation les for this session from
the OBS directory of your campaign before your start to simulate observations. Otherwise
you run into the danger of mixing your current set of simulated observations with other
measurements:
bern52@carina :~ > rm ${P}/INTRO/OBS /????2070.CZ?
bern52@carina :~ > rm ${P}/INTRO/OBS /????2070.PZ?
The input les for the generation of synthetic GNSS observations with program GPSSIM
("Menu>Service>Generate simulated observation data") are dened in the rst input panel:
Select EXAMPLE.ABB in option Abbreviation table in the next panel GPSSIM 1.1: General
Files.
In the second panel, the interval for data simulation is dened and the list of stations
selected from all sites in the input Coordinate le:
The meta data for each station is specied in this panel:
The Receiver for each station must start with SIMULA to indicate that this is a simulated
station. In the input eld you may only extend this string by a user input. Note that
the receiver and antenna types you are dening here must be registered in the Receiver
information and Phase center eccentricities les given in panel GPSSIM 1.1: General Files.
Page 134 AIUB
Please check the completeness for each involved GNSS which is not dened by the receiver
type connected to the antenna but by the list of satellites in the GNSS Standard orbit.
If you would use the real antenna names for the stations as they are given in Tab. 1.1
GPSSIM would fail and issue a message like
*** SR SEARCH_OFF: No offset values found for
satellite system R of
Antenna: ASH700936E SNOW
Number: 0
which indicates deciencies that need to be xed manually or with the support of the
program ATX2PCV ("Menu>Conversion>ANTEX to Bernese format"). In that case you need to dene
some antenna phase center corrections for this antenna type for GLONASS. If there is
no need for any other antenna naming convention it is proposed to use the antenna name
SIMULA with radome type NONE what seems to be sucient for most of the simulation
purposes.
In the subsequent panels some basic characteristics, assumptions on the ionospheric con-
ditions, and the noise level are introduced. Even cycle slips may be simulated.
The observations are generated without noise to check the consistency with the processing
program in the subsequent sections.
Keep in mind, that you may overwrite les from your previous processing if you start the
program GPSSIM now.
7.4.2 Zero Dierence Solution from Simulated GNSS Observations
The simulated observations can directly be introduced in program GPSEST for an analysis
on zero dierence level (if you have not simulated cycle slips). Please take care on the
consistency of all input les:
Page 136 AIUB
Result les can be specied to compare the results with the inputs for GPSSIM. A residual
le might also be useful.
The processing models also have to be consistent with the simulation or to contain well
dened dierences which are the subject of your investigation:
No constraints for datum denition are needed because these are noisefree simulated
data:
Only the receiver and satellite clocks are estimated:
Page 138 AIUB
The resulting program output le looks like the usual output from GPSEST but with
perfect observations without any noise:
...
--------------------
-----------------------------
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
-------------------------------
------------------------------------------------------------------------------------------ ...
PHASE L3 ALL 68024
CODE L3 ALL 68024
------------------------------------------------------------------------------------------ ...
------------------------------------------------------------------------------------------ ...
------------------------------------------
CHI **2/ DOF : 0.00
...
No improvements for the station coordinates and other parameters are expected:
...
-------------------
------------------------------------------------------------------------------------------- ..
71 GANP 11515 M001 X 3929181.4207 3929181.4207 -0.0000 0.0000
Y 1455236.8227 1455236.8227 0.0000 0.0000
Z 4793653.9510 4793653.9510 0.0000 0.0000
HEIGHT 746.0154 746.0154 0.0000 0.0000 ..
LATITUDE 49 2 4.971316 49 2 4.971316 0.0000 0.0000 ..
LONGITUDE 20 19 22.574503 20 19 22.574503 0.0000 0.0000 ..
...
The intersystem and interfrequency biases have been assumed to be zero during the
simulation (what is equivalent to any other constant number):
...
RECEIVER CLOCKS / TIME BIASES:
-----------------------------
REQUEST STATION NAME OFFSET (USEC) RMS (NSEC)
----------------------------------------------------------------------------------------------
1 GANP 11515 M001 0.000000 --- 0.000000 --- SAT GPS
1 GANP 11515 M001 0.000000 -0.000000 -0.000000 0.000 SAT 101
1 GANP 11515 M001 0.000000 -0.000000 -0.000000 0.000 SAT 102
1 GANP 11515 M001 0.000000 -0.000000 -0.000000 0.000 SAT 103
1 GANP 11515 M001 0.000000 -0.000000 -0.000000 0.000 SAT 104
1 GANP 11515 M001 0.000000 -0.000000 -0.000000 0.000 SAT 105
1 GANP 11515 M001 0.000000 0.000000 0.000000 0.000 SAT 107
1 GANP 11515 M001 0.000000 0.000000 0.000000 0.000 SAT 108
1 GANP 11515 M001 0.000000 -0.000000 -0.000000 0.000 SAT 110
1 GANP 11515 M001 0.000000 0.000000 0.000000 0.000 SAT 111
1 GANP 11515 M001 0.000000 0.000000 0.000000 0.000 SAT 113
1 GANP 11515 M001 0.000000 -0.000000 -0.000000 0.000 SAT 114
1 GANP 11515 M001 0.000000 0.000000 0.000000 0.000 SAT 115
1 GANP 11515 M001 0.000000 -0.000000 -0.000000 0.000 SAT 117
1 GANP 11515 M001 0.000000 -0.000000 -0.000000 0.000 SAT 118
1 GANP 11515 M001 0.000000 -0.000000 -0.000000 0.000 SAT 119
1 GANP 11515 M001 0.000000 -0.000000 -0.000000 0.000 SAT 120
1 GANP 11515 M001 0.000000 0.000000 0.000000 0.000 SAT 121
1 GANP 11515 M001 0.000000 0.000000 0.000000 0.000 SAT 122
1 GANP 11515 M001 0.000000 0.000000 0.000000 0.000 SAT 123
1 GANP 11515 M001 0.000000 0.000000 0.000000 0.000 SAT 124
...
The same holds for the epochwise clocks.
The residuals in the optional residual output le of such a dataset is well below the 1 m
level.
7.4.3 DoubleDierence Solution from Simulated GNSS Observations
As in the beginning of the simulation, you should make sure that no other base-
line observation les for the current session exist in the OBSdirectory of your cam-
paign to prevent any interencies and mixtures of simulated measurements with other
ones.
bern52@carina :~ > rm ${P}/INTRO/OBS /????2070. PS?
Page 140 AIUB
The simulated measurements can also be processed in the doubledierence mode. In that
case you have to start with forming baselines using the program SNGDIF ("Menu>Processing
>Create baseline les") in nearly the same shape as in Sect. 4.2.2 for real observations:
The main dierence is that you should also keep all ambiguities from the zero dierence
in the baseline observation les, what is managed by checking the box for option Merge
ambiguities from input les:
The resulting baseline les from simulated observations can now be analysed with program
GPSEST:
Page 142 AIUB
The models are selected to be fully consistent with the simulation:
No other parameters than station coordinates and ambiguities are esti-
mated:
The results are analogue to the zero dierence case previously de-
scribed:
...
------------------------------------------
CHI **2/ DOF : 0.00
...
The ambiguities are set up in a way that the correct resolution for all ambigui-
ties is zero in any case. This is an easy way to verify ambiguity resolution strate-
gies.
7.4.4 Final Remarks
There are many opportunities to use this simulation tool. It depends on your needs and
the concrete target of the simulation study to dene the experiment. As it was just
demonstrated the full consistency between the processing and the simulation programs is
guaranteed by the Bernese GNSS Software.
The big advantage of a simulation is that the correct solution is known a priori. On the
other hand, you have to keep in mind that the simulated data can only contain eects
included in the simulation model. If a receiver for instance introduces a signicant vari-
ation of the intersystem bias between GPS and GLONASS data an eect that is not
considered in the simulation model the inuence of such an eect on the results cannot
be evaluated by the simulation.
Page 144 AIUB

Tutorial Bernese PDF

Uploaded by

Copyright:

Available Formats

Tutorial Bernese PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Tutorial Bernese PDF

Uploaded by

Copyright:

Available Formats

Bernese GNSS Software

RECEIVER. Receiver information Introducing new receiver

IONEX.PPP . . . for the PPP example

. You may skip this step if you have

You might also like