4.  Creating Data Input Files

4.1  Introduction and file organization

The first, and in many ways most difficult step in analyzing GPS data, is organizing the data, both field notes and receiver output, in such a way that it can be handled efficiently by the processing programs.  It is during this process that you must make tentative decisions about how many days to analyze, what stations should be included and over what time span, and how frequently to sample the data.  In short, this is the time to start taking careful notes and to plan your analysis strategy.  This is also the time when you discover that you are missing log sheets, data files, or a priori coordinates for particular stations, and you must send frantic e-mail to fill in the holes.

The main GAMIT modules (beginning with FIXDRV, ARC, and MODEL) require seven types of input:
	•	Raw phase and pseudo-range data in the form of ASCII X-files (one for each station within each session)
	•	Station coordinates in the form of an L-file
	•	Receiver and antenna information for each site (file station.info)
	•	Satellite list and scenario (file session.info)
	•	Initial conditions for the satellites' orbits in a G-file (or a tabulated ephemeris in a T-file)
	•	Satellite and station clock values (I-, J-, and K-files)
	•	Control files for the analysis (sestbl. and sittbl.)
	•	"Standard" tables to provide lunar/solar ephemerides, the Earth's rotation, geodetic datums, and spacecraft and instrumentation information (see below).
The X-files are the key organizational structure because all X-files for a given session are written with the same start and stop times, selection of satellites, and sampling interval.  This imposed rigidity has certain advantages.  The primary one is that the process of creating the X-files (program MAKEX) acts as a filter, catching most of the problems with missing or invalid data, mismatched time tags, and poorly behaved receiver clocks that would cause greater loss of time if discovered later.  After the analysis is complete, X-files become the primary archive for the data, incorporating information about the scenario, site coordinates, and editing performed.

The first step is to create working directories for the processing.  The recommended organization is an "experiment" directory (e.g., gig91, trex17, or VB93), under which you will have "day" directories for each day or session (e.g./312 for day 312 of 1988).  The raw data files (in RINEX or FICA format) for an entire experiment or a several-day subset might be collected in a separate sub-directory parallel to the day directories so that they can be translated into X-files in a single batch; or they may also be in the day directory to allow automatic generation of a site list using the program MAKEXP.  Also in the day directory are the coordinates (L-) file, the station information file (station.info), session information or scenario file (session.info), and the control files for FIXDRV, sittbl. and sestbl.  Some of these files may appear as links to other directories.  Almost always included as links are the global files for geodetic datums (gdetic.dat), lunar and solar ephemerides (luntab. and soltab.), nutations (nuttab.), Earth rotation (ut1. and pole.), leap seconds (leap.sec), and spacecraft, receiver, and antenna characteristics (svnav.dat, antmod.dat, rcvant.dat).  

There are two structures in common use for linking tables to day directories.  The simplest is to put the "global" files in a GAMIT-level directory.  Shell script links.com will create links for gdetic.dat, luntab. soltab., nuttab., ut1., pole., leap.sec, svnav.dat, antmod.dat, rcvant.dat, and (optionally) lfile. from the working directory to ~/gs/tables, where gs is an alias (link defined in your home directory) for a GAMIT-level directory (e.g., /mydisk/stdrel/gamit).  In this scheme, station.info, session.info, sestbl., and sittbl. reside locally or are linked individually.  A more versatile (and recommended) structure is to create a /tables directory for each experiment, at the same level as the day directories and to perform two sets of links.  From within /tables, you execute links.tables, which will create links for the global files to ~/gs/tables.  Then from each day directory you execute links.day, which will create links for global files and experiment-specific files to ../tables.  In this scheme, you can keep copies of station.info, session.info, .sestbl., sittbl., and lfile. that are specific to the experiment in the experiment-level /tables directory, avoiding the possibility of processing different sessions with different input controls.  All of these link scripts are self-documenting—simply type the name with no arguments to see the proper syntax.  

4.2  Preparing the coordinate (L-) file

The L-file contains the coordinates of all the stations to be used in the experiment.  Only geocentric (spherical) coordinates are supported, in the following format:

VLBI FIDUCIALS:    GLB223 (1987.0) + TIES CONVERTED TO SV4 
Created by mhm 10/1/90
END
FTOR FORT7266 	N36	29	8.22850	W121	46	23.7842	 6370574.9754 	noam 1990.238
ONSA ONSAGPS   	N57	13	13.29164	E 11	55	31.84348	6363045.6176 	eura 1990.238
OVRO OVRO7114 	 N37	2	50.52769	118	17	37.65749	6371527.9644 	noam 1990.238

You may include as many comment lines as you wish, terminated by "END".  The format is  (A12,5X,A1,I2,1X,I2,1X,F8.5,1X,A1,I3,1X,I2,1X,F8.5,F12.3).  The plate name and reference epoch at the end of each line are comments and not used by the program.  Within each day directory, the usual name of the L-file is the same as the D-file except for the first character(i.e., lprojy.ddd) , with a link provided to an experiment-wide L-file (lfile.) in ../tables.

It behooves you to exert some effort to get good a priori coordinates for processing.  The first consideration is to generate pre-fit residuals sufficient for AUTCLN to perform robust editing of the data.  For this purpose, errors up to 10 m will usually allow enough data to pass through to allow a decimeter-level solution that can be iterated; errors up to 1 m allow good editing.  The second consideration is linearity of the least-squares adjustment.  The convergence rate for station coordinates is (conservatively) 1/1000, so 1 m errors in the a apriori values contribute no more than 1 mm error to the final value.  The most exacting requirement is the coordinates used for the fiducial stations, which if constrained in the final solution define the reference frame of the network.  If you are using GLOBK for your final solution, then the first two of these requirements (editing and linearity) should be met in the GAMIT L-file, and the last two (linearity and fiducial coordinates) should be met in the GLOBK a priori ( .apr) station file.  GLOBK apr files of ITRF coordinates can be obtained from /updates/tables in the MIT ftp directory.

If precise coordinates of your regional or local stations are not initially available, there are several approaches you can take.  Program RX2APR will search the RINEX headers of all files of a given station name and return the average values of X, Y, Z in the format of a GLOBK .apr file.  You can then use program GLBTOL, described below, to obtain spherical coordinates in L-file format.  The RINEX-header coordinates are usually those written by the receiver, either from values input by the operator or estimated at lock-up.  Their accuracy is highly variable, sometimes as bad as hundreds of meters.  A second option is to use the /kf (i.e., GLOBK) programs SVPOS or SVDIFF, which perform pseudorange solutions using all the data in the RINEX file.  SVPOS uses a single station's data and is thus limited in accuracy to tens of meters by Selective Availability.  SVDIFF uses files from two stations, so by choosing one whose coordinates are well known, you can achieve meter-level accuracy.  The third option, usually to be used in conjunction with one of the others, is perform a preliminary GAMIT solution (or use multiple iterations—see Chapter 5) to update the coordinates of all the new stations in your network. 

Program GLBTOL ("global-a priori-to-L") converts a GLOBK apr file of Cartesian coordinates and velocities to an L-file at a specified epoch.  It is executed using command-line arguments:

	 glbtol <globk.apr> <lfile> <full names> <date>
 
where <globk.apr> is the name of the input GLOBK a priori file,
	<lfile>	is the name of the output -L-file
	<full names> is the name of a file which gives the full site name for each of the 			GAMIT four character site codes. You can usually omit this file by 			substituting using double quotes (" ") since the full site name for 			GAMIT is taken from file station.info, not the L-file
	< date >	is the date to which the L-file coordinates should by referred.  The 			date may be specified in one of three ways:
	(1) If a single value is given, then decimal years is assumed,
	(2) If two values are given, they are assumed to be year and day of year.
	(3) If three values are given, they are assumed to be year, month, day.

(NOTE:  The program will only pick up sites with _GPS in the site name. This convention is used in the GLOBK .apr files in order to distinguish VLBI and GPS sites.  In translating GAMIT h-files to GLOBK binary files, HTOGLB automatically adds the _GPS to the GAMIT site codes.)

4.3  Creating the station information file

All of the receiver and antenna information specific to a particular site occupation is recorded in file station.info, which is read by MAKEXP, MAKEX, and MODEL.  This is the one GAMIT input file which must be created by the analyst through manual editing, using, e.g., a template gamit/tables .  The format of station.info is shown below: 

iap2 brdc
(A4,1X,A4,1X,A16,F7.4,2(1X,F8.4),1X,A6,1X,A6,1x,a5,1X,F5.2,1X,I2,1X,I3,1x,i2,6(1X,I2))
 TRCK SITE Station Name     Ant Ht   Ant N    Ant E  Rcvr   AntCod HtCod  Vers Yr Doy SN 
 WEST WEST Westford         1.3060   0.0000   0.0000 TRMSST TRMSST SLBGP  4.53 92 015  1 
 WEST WEST Westford         1.3060   0.0000   0.0000 TRMSST TRMSST SLBGP  4.53 92 016  1 
 WEST WEST Westford         1.3060   0.0000   0.0000 TRMSST TRMSST SLBGP  4.53 92 017  1 
 WIAP WIAP Westford IAP     0.7920   0.0000   0.0000 TRMSST TRMSST SLBGP  4.53 92 017  1 
 WMIC WMIC Westford Micro   1.3270   0.0000   0.0000 TRMSST TRMSST SLBGP  4.53 92 015  1 
 WMIC WMIC Westford Micro   1.3270   0.0000   0.0000 TRMSST TRMSST SLBGP  4.53 92 016  1 
 WMIC WMIC Westford Micro   1.3270   0.0000   0.0000 TRMSST TRMSST SLBGP  4.53 92 017  1 

The first two columns are redundant for static surveying but describe the receiver track (TRCK) and monument occupation (SITE) for kinematic or dynamic surveying.  The 16-character station name will be written on the X-file and used throughout GAMIT whenever full names are printed.  The antenna height, given in meters, refers to the measured distance (vertical or slant) between the monument and a physical point on the antenna described by the 5-character keyword under AntCod, as described below.  The Ant N and Ant E values refer to the offsets of the center of the antenna from the monument.  The receiver type (Rcvr) and firmware/software version (Vers) are used by MAKEX in filtering the sample time (some receivers have offsets from the even minute) and determining whether a receiver has full- or half-wavelength L2 observations.  In many cases, the version number does not have to be exactly correct (see Section 4.7).  The correspondences between GAMIT receiver/antenna codes and the full (IGS) designations that are written on export SINEX files are given in table rcvant.dat.  

For static surveying, the appropriate entry in station.info is selected by matching the year (Yr) , day-of-year (Doy), and session number (SN) with the values in the X- or C-file header, usually taken from the RINEX file name.  Not shown in the example (due to table width) are the last two columns, giving the Start and Stop times for the session.  These are required entries in all cases but they are not currently used for static surveying; multiple entries on a single day are distinguished by session number.  The GAMIT modules will use the most recent entry for the station information.  Thus, you would normally need to include only a single line per experiment for permanent trackers.  Multiple entries for a station need not be contiguous but most be in chronological order (Release 9.44 will detect this for you, but earlier releases will pick up without warning the last entry before one later than the date of your session).  After the first two lines, any entry with a non-blank character in column one will be treated as a comment, allowing you to document the history of a tracker or experiment.

Most important among the entries are the antenna type and specification of how the height-of-instrument (HI) was measured in the field since this directly affects the estimated heights from the analysis. This information is typed into station.info in the form of keywords and later converted by GAMIT to L1 and L2 phase-center offsets.  The following measurement schemes are currently supported:

	Antenna	Type of measurement	Keywords for HI
	Any instrument	direct height to pre-amp base (ARP)          (e.g.)	TI4100	DHPAB
	Any instrument	L1 phase center                                          (e.g.)	TI4100	L1PHC

	Ashtech L	direct height to top of ground plane	ASHL12	DHTGP
	 		slant height to bevel at bottom edge of ground plane 	ASHL12	SLBGP
			slant height to closed holes in antenna ground plane 	ASHL12	SLHGP
					(  alias	SLAGP)
	Ashtech P  (II)	direct height to top of ground plane	ASHP12	DHTGP
		(28-cm GP)	slant height to bevel at bottom edge of ground plane 	ASHP12	SLBGP
			slant height to open holes in antenna ground plane -	ASHP12	SLHGP
			slant height to bevel at bottom edge of ground plane 	ASHP12	SLBGP
	( The old designation ASHXII is interpreted as a P (II) antenna )
	Ashtech P  III	direct height to top of ground plane	ASHGD3	DHTGP
		(34-cm GP)	slant height to holes in large ground plane	ASHGD3	SLHGP
					(  alias	SLLGP)
	Ashtech 	direct height to bottom of  choke ring	ASHDMR	DHBCR
	   Dorne-Margolin	direct height to top of choke ring	ASHDMR	DHTCR
			slant height to bottom edge of choke ring	ASHDMR	SLBCR
		( ASHDMR [alias DMRASH] is used when the radome is on; ASHDMG if it is off. )

For Topcon antennas, the appropriate Ashtech designations should be used.  However, the P (II) antenna that accompanied the GP-RIDP receiver can be designated TOPP12, and the Geodetic III (34-cm ground plane) antenna that accompanied at least the early GP-RIDY (Ashtech Z-12) receivers can be designated TOPGD3.  The designation TOPCON is no longer supported because of its ambiguity.

The following designations apply to Dorne-Margolin choke-ring antennas used with Rogue receivers:
	Type R (used with Rogue SNR-8):			DMRCHR or ROGSNR
	Type B (Allen Osborn design):  			DMBCHR or ROGAOA
	Type T (used with TurboRogue):			DMTCHR or TRBROG
For any of these, the following measurements are supported:
			direct height to bottom of  choke ring (or baseplate)			DHBCR
			slant height to bottom bottom of choke ring (baseplate)		SLBCR
			direct height to top of choke ring			DHTCR

	FRPA-2	L1-phase center only	FRPA-2	L1PHC

	LEICA with	direct height to bottom of pre-amp base 	LEIGRT	DHPAB
       GRT carrier

	Mini-Mac 2816 AT	direct height to center of pre-amp base (ARP)	MIN6AT	DHPAB

	Sercel TR5S	direct height to center of pre-amp base	SRTR5S	DHPAB
	Sercel NR52	direct height to center of pre-amp base	SRNR52	DHPAB

The following designations apply to TI antennas:
	100 or 2000 series			TI4100	
	4000 series 			TI4000
For either of these, the following measurements are supported:
			slant height to edge of pre-amp base 			SLPAB
			direct height to pre-amp base (ARP)			DHPAB

	Trimble 4000SXD	slant height to corner of pre-amp base	TRMSXD	SLPAC
			slant height to bottom corner of ground plane	TRMSXD	SLCGP
	Trimble 4000SLD	slant height to side of pre-amp base	TRMSLD	SLPAS
			slant height to corner of pre-amp base	TRMSLD	SLPAC
			slant height to bottom edge of ground plane	TRMSLD	SLBGP
			slant height to top edge of ground plane	TRMSLD	SLTGP
	Trimble 4000SST	direct height to center of pre-amp base (RINEX)	TRMSST	DHPAB
			slant height to bottom outer edge of ground plane	TRMSST	SLBGP
			slant height to middle outer edge of ground plane	TRMSST	SLMGP
			slant height to top outer edge of ground plane	TRMSST	SLTGP
			slant height to top of ground plane in notch	TRMSST	SLTGN
	Trimble 4000SSE	(same measurements allowed as for 4000  SST)	TRMSSE

	WM 102	direct height to height hook	WM-102	DHHHK

Entering  L1PHC along with 0.0 for the observer's measurement causes hisub to calculate simply the L2 offset value.  This scheme is used for a fiducial-site antenna that is permanently mounted on a building or tower and not associated with a monument.  Height-code information for most of the world's permanent trackers may be found in /sites/station.info.mit, and /sites/trackers.doc in the MIT ftp/pub/gps directory. 

In release 9.4, the phase-center offsets are computed in two steps.  Library subroutine hisub.f converts the field measurement (e.g. slant height to the bottom edge of the ground plane) to an offset of the IGS-standard antenna reference point (ARP) from the monument.  Then MODEL reads the new table antmod.dat to determine the effective phase center with respect to the ARP, either as a constant or function of elevation (and possibly) azimuth angle of the satellite.  Formulas and diagrams for each of the antennas may be found in lib/hisub.f and are documented in Appendix 7.  Models for the effective phase-center offsets are still under development by several groups.  The standard antmod.dat includes only constant (no elevation- or azimuth-dependent) values and reproduces the offsets in hisub.f in GAMIT release 9.2 except for corrections of 2–4 mm in slant height for the Trimble SLD and SXD and the Ashtech L and P (see Appendix 7). 

Veteran GAMIT users will recognize that station.info contains antenna-height information formerly tabulated in the "raw" file (hi.raw), read by program HI and converted to L1 and L2 offsets for the "site description file" (sited.).    Although MAKEX, FIXDRV, and MODEL can still read a sited. file, it is recommended that this information be transferred to a station.info file, which provides a better record and a more direct connection between the original antenna measurements and the offsets used by MODEL to compute the theoretical observable.  Conversion of a hi.raw file to a station.info file is accomplished using program HI2STNFO, described in Chapter 9.  

4.4  Creating a scenario file

The scenario file (session.info) contains the start time, sampling interval, number of observations, and satellites (PRN #s) to be used in generating the X-files for each day.  It does not correspond to the time-dependent scenarios used to program some receiver software, but rather includes all the satellites that you want to use in the analysis—generally all available from any receiver since you can delete satellites later on in the processing.  To find out what satellites are available on the raw data files, use the shell scripts rxscan and ficascan.  An example of a session.info file is given below:

Yr Day	Int	Max	   HH MM	Satellites
(I2,1X,I3,1X,i2,2X,I4,3X,I4,7X,I2,1X,I2,3X,24I3)
86 278  1	30	900	14 04	3	6	9	11	12	13		
86 350  1	30	900	8 10	3	6	9	11	12	13	
86 351  1	30	900	8 06	3	6	9	11	12	13			
87 144  1	120	225	22 52	3	6	8	9	11	12	13	

(An older version of the scenario file specified the session number with a character format:  (I2,1X,I3,1X,A,1X,I4,1X,I4,7X,I2,1X,I2,3X,24I3).  This version can be read successfully by current releases.)  The session.info file can be specific to a given experiment or contain all of the scenarios used for all the experiments processed at your facility.  An experiment-specific file can be generated automatically by program MAXEXP  (see below) using the input start/stop time and the satellites available on the navigation file.

4.5 Using MAKEXP

Once you have assembled the RINEX observation and navigation files in a single directory and created station.info and (optionally) session.info you can use program MAKEXP to generate most of the additional files you will need to complete preprocessing.  MAKEXP uses the RINEX or X-file names to compile a list of available stations, and the RINEX navigation file to generate a list of satellites.  (New feature in release 9.45:  If you have already a session.info and have ftp'd a global j-file from SOPAC, then the navigation file is not necessary to run MAKEXP.)  MAKEXP then creates the input files for MAKEJ, MAKEX, BCTOT, and FIXDRV.   Setting up these files from templates is not difficult and may be necessary for experiments with multiple sessions or a mixture of RINEX and FICA files.  For large experiments or permanently operating arrays, however, using MAKEXP can save a great deal of time and manual effort.  (Yet one more level of sophistication is provided by the new shell script getready, which runs the complete GAMIT sequence from a small set of input files.  The script, written by Eric Calais while at SIO, is internally well documented and can be found in gamit/com)

To run MAKEXP, type the program name and answer the queries.  You will be asked to enter the year, day-of-year, and session number.  The program will then scan the working directory for RINEX or X-files with the input date, compare the 4-character site names and date with the TRCK codes and dates in station.info, and write to the screen a summary of the available stations.  If a scenario file (session.info) exists, MAKEXP will use it to determine the start and stop times and the satellites to be used in the session.  If the session.info file has only a single entry in it, MAKEXP will "edit" the entry to set the year and day-of-year but keep the start time, sampling interval, number of epochs, and the satellite list intact, a useful mode for automatic processing of continuous arrays.  If there is no scenario file, you will be asked to input the sampling interval, number of epochs, and start time; the program will generate a satellite list from the navigation file.  Days which have only a single session may use either "0" or "1" for the session number in the RINEX filename, session.info, and station.info (internally this value will always be changed to "1").  You can mix "0" and "1" RINEX filenames within a single session, so there is no need to r

The screen output of MAKEXP contains a summary of the stations found (X-files to be created), satellites included, and the session times.  It concludes with instructions for the next steps: 

 Now run, in order:
 
  makej < makej.inp                          OR copy a j-file from SOPAC
  checke < 
  makex < makex.inp
  sh_sp3_to_gt <sp3 file> <proj> <yr> <doy>  OR bctot < bctot.inp 
  fixdrv < fixdrv.inp

Program MAKEJ creates a (J-) file of satellite clock values from the navigation message; program MAKEX creates the GAMIT observation (X-) files; shell script sh_sp3_to_gt creates an orbital ephemeris (T-file); and program FIXDRV reads the analysis controls and creates a batch file for GAMIT processing.  The first three of these steps are described in the remainder of this chapter, and the last step in Chapter 5.  

4.6  Creating satellite (J-) clock -files

In order for MODEL to account properly for clock effects on the phase observations, additional information must be supplied about the behavior of the satellite and station clocks.  How these effects are computed and tabulated depends on the level of "selective availability" (SA) and whether the ground stations are sampling the phase simultaneously.  When executed, MAKEJ will ask you to choose the type of J-file to create:

 Choose source of SV oscillator frequency corrections:
  1  E-file broadcast message. 
  2  Second order fit to C-file from site with H-maser 
 Pick a number.

For networks with simultaneous sampling, it is sufficient to create a satellite clock (J-) file using simply the coefficients transmitted in the broadcast message.  These can be obtained from the RINEX navigation file, or the Block 9s of a TI FICA file (see program FICACHOP), from any station that observed for most of the session or from the combined files distributed by IGS analysis centers.   Select option 1 at the prompt and then enter in response to prompts the name of the output J-file, the name of the RINEX navigation file or GAMIT E-file (RINEX or FICA format),  and the interval at which you want to tabulate the clock values.  Once per hour (3600 s) is usually a sufficient interval.  The input file created by MAKEXP can also be used to run MAKEJ with option 1 (makej < makej.inp ).   Part of a sample J-file is shown below:

SV clock corrections written by king   Program:  6.1 of 90/05/18 01:58:50 (apollo)
YR DOY HR MN  SEC(UTC) WKNO  SOW(GPST)   PRN     XEAF0           XEAF1             XEAF2
(I2,1X,I3,2I3,1X,F5.2,3X,I3,1X,F9.2,2X,I2,2X,3D16.8)
88 	311	17	59	55.00	461	64800.00	3	0.39050030E-03	-0.68212103E-12	0.00000E 00
88	 311	17	59	55.00	461	64800.00	13	0.37502684E-03	0.23874236E-11	0.00000E 00
88 	311	18	59	55.00	461	68400.00	3	0.39049797E-03	-0.68212103E-12	0.00000E 00

The first line is a header constructed by MAKEJ, and the second line contains titles to guide the analyst.  The third line is a format statement used to read the entries that follow.  Each data line contains the coefficients transmitted by the satellite for its own clock.  The formula to be used in computing the SV clock offset is

where ts' is the time read by the satellite's clock and ts is "true" GPS time. The coefficients a(0), a(1), a(2)  are given in the last three columns (XEAF0, XEAF1, XEAF2) and refer to the reference epoch t0(c) given in columns 6 and 7 as GPS week number and seconds of week.  The numbers in the first 5 columns give the reference time in UTC or (from Release 9.28) GPST using conventional units.

The J-file is also used by MAKEX to generate a K-file of station clock offsets, used in turn by FIXDRV to generate an I-file of station clock coefficients for MODEL.

If SA is on, then the difference in the signal propagation time to different sites (up to ~10 ms) or, more seriously, several-second differences in the nominal sampling times can introduce significant errors if the oscillator variations are not modelled on the time-scale of the sampling differences.  A technique for generating such a model using the phase residuals computed for sites with atomic oscillators is described in Feigl et al. [1991] and more extensively in Chapter 2 of Feigl [1991].  Instructions on how to implement this technique using MAKEJ are given in Appendix 8. 

4.7  Running MAKEX

Program MAKEX takes as input the scenario file (session.info), station information file (station.info), satellite clock (J-) file, Broadcast ephemeris (RINEX nav or GAMIT E-) file, site coordinates (L-) file, and raw data files (in RINEX or FICA format), and creates X- and  K-files for input to FIXDRV and MODEL.   K-files, though normally created by MAKEX can be re-created later if necessary by program MAKEK (Section 4.8).

To run MAKEX after running MAKEXP, you need type only makex < makex.inp.  Otherwise, you need to set up a control file with name day.makex.batch, where day is the day of year designating the session to be processed.  The batch file contains pointers to the input files and a list of station-days to be processed.  An example for RINEX  input is shown below:   

infor	1  
sesfo	1 ./session.info
rinex	1 ./
ficaf	0  
coord	1 ../tables/lfile.
stnfo	1 ./station.info
xfile	1 ./x
svclk	1 ./jtrex0.091
clock	1 ./k
extra	0  
rdorb	1 ./vndn0911.90n
extra	0
site		        ver
(A4,A2,A1,1X,A3,2X,,A3,1X,F4.2)
VND2901.091	GES	1.9
YKNF901.091	COR	4.8
MOJM901.091	MIN	1.49
VNDN901.091	TRM	3.25

The first 12 lines indicate which of the input and output files are to be used and the directories on which they reside.  The first six columns are not read by the program but provide hints to the users (all lines must be present in the order given).  A "1" following the name indicates that the file is to be used (input or output), a "0" that it will not be used.  Complete file names are useful for documentation, but if the file is in the working directory (i.e., the one in which MAKEX is being run), an abbreviated filename may be used (see, e.g., the rinex and stnclk entries above).   For the input RINEX or FICA files, no filename is given since MAKEX constructs the filename from the station and day names which follow in the input stream.  FICA files must be named [site][y].[day].fic (note that only the last digit of the year is used, with no session number), and RINEX files [site][day][f].[yr]o, where f is the file sequence number and o indicates that it is an "observation" file.  Similarly, for X- and K- files, only the first letter is given.  In the above example, if the input data file were FICA, the rinex entry would have been "0" and   "./" (or directory path) would appear after ficaf.  The GAMIT E-file (rdorb above) is simply an orbit file in either RINEX nav-file format or FICA Block 9 (TI4100) format (created with FICACHOP).   The first line gives the information file, a log of MAKEX runs written to the current directory with name dd.makex.infor (007.makex.infor in the example given).

Line 13 of the batch input is a comment that provides column headers for the list of site files which follow.  Line 14 gives the format for reading the key characters of the site file name.  The format shown in the example allows reading of a four-character site code (VND2), the year number (90), session number (1), and the day number (091).  Note that the session numbers used here must match those in the station.info (or sited.) and session.info (sceno) files, and those in the FICA and RINEX filenames.  (One exception to this is a RINEX file with sequence number "0", which will be read successfully for session "1".  However, if there is more than one session, you should name the first RINEX file using sequence number "1", not "0".)  The receiver software and version in the last two fields are required in order to have time tags correctly matched.  Designators for software versions currently supported, and their sampling times are listed in Table 4.1.  In several cases, we have arbitrarily added an additional digit to the version number in order to distinguish time tags set by the operator.  See trackers.doc and trackers.station.info in the /sites directory for the history of software versions used at the fixed tracking sites.

To run MAKEX, type the program name and enter a batch file name, or use the input file (makex < makex.inp) created by MAKEXP.  After completing each station, the program will write to the screen and the .infor file a summary of the observations selected:

	Sats	Epochs
	----    ---------
		0		498	! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
		1		1
		2		342	! ! ! ! ! ! ! ! ! ! ! !
		3		152	! ! ! ! !
		4		507	! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !
		5		0
		6		0

Good observations per channel :  Total Number and Maximum Gap
	vndn901.091	PRNS	6	9	11	13	12	3	8

	vndn901.091	OBS	606	511	419	619	240	395	375
	vndn901.091	GAPS	0	1	0	2	0	0	0
	
	35 observations rejected as unreasonable

The upper chart gives the number of epochs for which there are the given number of satellites.  In the example, there are 507 epochs of 4-satellite data.  The minimum number of satellites to be useful is two, since the phases from at least two satellites must be differenced in order to cancel station clock effects.   

If no observations were selected, you should check the MAKEX screen display (or the .infor file) to be sure that 1) there are data within the times requested in the scenario file, and 2) the sampling epoch matches that implied by the software version number given in the MAKEX batch file.  If there is a change in sample time in the middle of the input file (not unheard of) or if the input file begins and ends before the requested time, you may have to examine the RINEX or FICA file with the editor and/or run the utility FICASCAN to determine the problem .  Renaming the input file test.makex.batch will cause MAKEX to write additional information to the screen, a useful feature if you cannot discern the source of a problem using the procedures already described.

Table 4.1	Receiver software designations used by MAKEX
————————————————————————————————————
Receiver	Software	Abbrev.	Version	Sampling time (seconds 
				  after the GPST minute)
————————————————————————————————————
TI 4100	GESAR	GES	1.0-1.9	59.08

	CORE	COR	25.2	59.74
			4.1	59.08
			4.7	59.08
			4.11	59.00
			4.12*	59.08
			4.13	59.00 and 59.08 in same file
			4.8	0.08
			5.7	59.08

	ROM	ROM		59.08
			1.11	59.00
	GSM	GSM		59.08

MACROMETER II		MAC		58.475 - (GPST–UTC)

MINI-MAC		MIN	1.49	0.001
			1.50	0.001 - (GPST–UTC)
			1.59	59.001
			1.61–1.64	0.000
			1.89	59.001 **

TRIMBLE 4000 SDT	NAV+SIG	TRM	3.11–3.25	.variable
               4000 SST/SSE		4.1 ff	0.0

ASHTECH  XII, TOPCON	ASH	1.0, 2.0, 6, 7, 8***	0.0

ROGUE SNR 8		ROG	1.51, 2.30	0.0 – (GPST–UTC)
			2.31 ff	0.0
MINI-ROGUE			1.11, 1.50, 2.31, 
			2.4, 5.5, 5.6, 5.61
			6.11, 7.00ff	0.0
TURBO-ROGUE SNR-8000	TRB	1.0, 2.00–3.20	0.0
.
SERCEL TR5S		SRT		0.0
              NR52		SRN		0.0

* COR 4.12 indicates one of two anomalous frequency plans used during GOTEX and at Yellowknife during March 1990.

** MIN 1.89 indicates MiniMac data sampled at 59.001 but tagged in the RINEX file as 59.000.  The time tags are corrected in MAKEX and software version gets changed to 1.59 in XTORX.

***The Ashtech software designations are somewhat arbitrary:  1.0 indicates a codeless receiver; for the P-XII, 2.0 indicates the alpha verson of the software, 6.0 the beta version, 7.1 the 7A software, and 7.2 the 7B software; for the Z-12, 8.00 is software version 1C00, 8.01 = 1C01, 8.10 = 1D00, 8.20 = 1E00, 8.30 = 1F00, 8.40 = 1G00, 8.70 = 1J00.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

4.8  Description of the X-file

A sample X-file created by MAKEX is shown below:

 GPS Phase & Pseudorange from TI 4100 receivers
 
 MAKEX (Apollo 92-06-01)          run on 1991-06-17 16:50:44
 
                     GESAR/PHASER HEADER INFORMATION
 
 UNPACK 1.3 of 87/10/06    mill7.007a.fic                    1987-10-15 18:04:23
BLK     13    0    3    0
 
END
                     COORDINATE FILE INFORMATION
 STATION_NAME____   LATITUDE   	LONGITUDE   HEIGHT		RCVR  SWVER
                  	_DG MN SS.SSSSS __DG MN SS.SSSSS ____(M).___
 MILLER CADT       	N34 19 50.33849  W120 13 48.02332 6371422.962  GES  1.0
 
 ANT OFFSETS (M) L1    UP     NORTH   EAST   L2   UP     NORTH   EAST
                      	1.491       0.000   0.000         1.466   0.000   0.000
 
  6 SATELLITES		             DATA  TYPES                 1      2       3      4
 CHANNEL  1  PRN# 3 	NAVSTAR	11 	LAMBDA	-1	-1	1	1
 CHANNEL  2  PRN#	6	NAVSTAR	3	LAMBDA	-1	-1	1	1
 CHANNEL  3  PRN#	9	NAVSTAR	6	LAMBDA	-1	-1	1	1
 CHANNEL  4  PRN#	11	NAVSTAR	8	LAMBDA	-1	-1	1	1
 CHANNEL  5  PRN#12	NAVSTAR	10	LAMBDA	-1	-1	1	1
 CHANNEL  6  PRN#	13	NAVSTAR	9	LAMBDA	-1	-1	1	1
 
 FIRST EPOCH (UTC)         GPST-UTC=  4.0
 YR DAY HR MN SECS   INTERVAL(SECS)    DATA INTERVAL   SESSION
 87   7  6 41 55.080    120               30             1
 
 225 EPOCHS

 EPANDED DATA FORMAT STATIC
 EPOCH # FLG CH     L1 PHASE          AMP        L2 PHASE      AMP      L1 PSEUDORANGE        L2 PSEUDORANGE
 
  	1  	0
 
  	2  	1 	87  	7 	6	43	55.080  0 MILL N34 19 50.33849 W120 13 48.02332 6371.422.962 1.4910  0.0000  0.0000     1.466  0.0000  0.0
           0	2 	0.209327782121811E+08 	7 	-0.263626960264358E+08 	6 	0.242673706688020E+08 	0.242673708548210E+08
  
  	3  	2 	87 	7	6	45 	55.080 0  MILL N34 19 50.33849 W120 13 48.02332 6371.422.962 1.4910  0.0000  0.0000     1.466  0.0000  0.00
           0	1	0.283412097505112E+08 	7 	-0.354413610923080E+08 	6 	0.249617918581700E+08 	0.249617931178260E+08
           0	2	0.233529585203629E+08 	8 	 -0.244768413617021E+08	7 	0.238068262469650E+08 	0.238068256365880E+08
 
The first group of records (to END) are header lines, accumulated by the succession of programs that have handled the data up to this point.  These are followed by the name of the station, its coordinates as read from the L-file, and the antenna offsets read from station.info (or sited.) file. The list of satellites given next specifies the order in which they appear in the X-file (not necessarily the channel assignments in the receiver).  DATA TYPES specifies which of the allowable types of observations are present:  

	1  = L1 phase
	2  = L2 phase
	3  = L1 P-code pseudorange
	4  = L2 P-code pseudorange
	5  = L1 C/A code pseudorange

The LAMBDA, or "wavelength" codes given for each channel indicate, for each data type, whether it is ambiguous and whether the ambiguity spacing is full or half wavelength.  All phase observables are converted to full wavelength on the X-file.

	0	=	observable is not present for this channel
	-1	=	ambiguity spacing is one wavelength (e.g., 19 cm for L1 phase)
	-2 	=	ambiguity spacing is one-half wavelength
	1	=	no ambiguity
	2 	=	no ambiguity (original observable was half wavelength) 

The usual value of LAMBDA is -1 (code-correlating receivers) or -2 (L2 from codeless receivers) for phase observations, 1 for pseudo-range observations. X-file data are required to be evenly spaced, so the observation times are specified by a start epoch, an observation interval, and the number of epochs.  INTERVAL is the actual interval on the X-file;  DATA INTERVAL refers to the raw data file interval (usually the receiver sampling interval) and is used by the editing routines to determine if gaps in the X-file are due to sparse sampling or missing data.  The observations at each time are identified by an epoch number, an integer which specifies the number of satellites for which there are data at that epoch, and the UTC or (Release 9.28) GPS time.  The site coordinates and antenna offsets are repeated at each epoch to allow for kinematic processing.  Then for each channel, there are eight numbers given:  a flag indicating whether the data are valid (=0) or have been flagged (set non-zero) by other modules;  the channel number;   the L1 phase (cycles);  the amplitude of the L1 signal using RINEX conventions; the L2 phase;  the L2 amplitude;  the L1 pseudo-range (meters); and the L2 pseudo-range.  Note that phases in the X-files are in the "Doppler" convention (increasing phase is decreasing range), and therefore have the opposite sign to phases in the corresponding RINEX files.

4.9  Creating  station clock (K- and I-) files

The offset from GPS time (or UTC) of each receiver's clock must be accounted for in modeling the theoretical value of the phase observations at each epoch.  If the positions of the receiver and a satellite are known, along with the offset of the satellite's clock, then the pseudorange observation provides a direct measure of the receiver clock offset:

where r  is the calculated range to the satellite, p1 is the observed pseudo-range and c is the speed of light.  Recall (Section 2.1) that an accuracy of about one microsecond in receiver-clock offset is necessary to achieve an accuracy of one millimeter in the estimated baseline vector.  In order to achieve this accuracy, the computation is performed in MODEL using the station and satellite positions (from the L- and T-files) calculated for the theoretical phase observable.  In this case, one microsecond (300 m) in the theoretical values is easily achieved.  Sufficient accuracy in the measured pseudorange is also achieved easily if P-code range is available.  If only C/A code is available, and particularly under conditions of selective availability (SA), some care must be exercised.  At present, MODEL computes the receiver-clock offset using an average of values calculated from all of the satellites visible at each epoch, detecting and removing anomalous values caused by pseudorange outliers or bad SV clock values. 

Strictly speaking, it is not necessary to provide GAMIT with any more information about a receiver's clock than that incorporated in the pseudoranges at each epoch.  There are a few practical reasons, however, why it is useful to generate a more explicit model of the receiver-clock behavior at an earlier stage in the processing.  Doing so provides a way of detecting poor receiver performance, for example.  Also, for receivers with poor and unmodeled clocks numerical problems are sometimes created in SOLVE when there are several-hour gaps between observations.  Hence we input to MODEL tables of coefficients which effectively model these variations.  For the receiver clock, MAKEX generates an estimate of the offset at an epoch interval of 120s for Ashtech and Trimble receivers, whose clocks reset often, and 600s for other receivers, using satellite elements from the broadcast ephemeris.  These estimates are written into the K-file:

 RDRK  14    92  73 19 43  53.0000    0.07132594    0.00018337    0.00007289
 RDRK  18    92  73 19 43  53.0000    0.07109620   -0.00000169    0.00007330
 RDRK  19    92  73 19 43  53.0000    0.07405061    0.00000424    0.00007332
 RDRK  14    92  73 19 45  53.0000    0.07153746    0.00018337    0.00001910
 RDRK  18    92  73 19 45  53.0000    0.07095191   -0.00000169    0.00001955
 RDRK  19    92  73 19 45  53.0000    0.07389223    0.00000424    0.00001934
 RDRK  14    92  73 19 47  53.0000    0.07175308    0.00018337    0.00096434
 RDRK  18    92  73 19 47  53.0000    0.07080949   -0.00000169    0.00096493
 RDRK  19    92  73 19 47  53.0000    0.07373656    0.00000424    0.00096463
 RDRK  14    92  73 19 49  53.0000    0.07197269    0.00018337    0.00090899
 RDRK  18    92  73 19 49  53.0000    0.07066900   -0.00000169    0.00090950
 RDRK  19    92  73 19 49  53.0000    0.07358361    0.00000424    0.00090935

The first column gives the station code, followed by the satellite PRN number, year, day of year, hours, minutes, and seconds (always UTC).   The eighth column is the observed pseudo-range to the satellite at the time given, in units of seconds, followed by the offset of the satellite clock (from GPS time) computed from the transmitted clock corrections.  The final number is the receiver clock correction computed using the formula above. 

Any differences in receiver clock values computed using the data from different satellites at the same time are due to errors in the pseudo-range measurements, the satellite clock models, or the geometrical models (station coordinates and satellite ephemeris).  In the above K-file, for example, the corrections computed at 19h 43m 53.s using data from satellites 14, 10, and 19 differ by up to 0.4 microseconds, equivalent to a radial position error of 120 meters (probably due to errors in the broadcast ephemeris).  Differences between receiver clock values computed for a given satellite at different times could reflect model errors but are usually dominated by actual receiver clock drift.  In our example, there is a change between 19h 43mand 19h 45mof 54 microseconds, indicating a drift in the receiver oscillator of 4.5 parts in 107 (54x10-6 / 120 ).  This high drift rate is typical of the crystal oscillators in many of today's lightweight receivers (the above example was a Trimble 4000 SST).  More stable (thermally controlled) crystals can achieve stabilities of 1 part in 108  (TI 4100) or better (Macrometer II).  Rubidium, cesium, or hydrogen-maser oscillators can achieve even high stabilities (10-11  to 10-15 ).

The ~1 ms jump in clock value at 19h 47m 53.s is a feature of the Trimble 4000 SST and Ashtech P12 receivers, indicating that the clock has been reset to keep it within 1 ms of the nominal sampling time.  Both the recorded sampling time and the pseudorange measurement will show a discontinuity of exactly 1 ms.  Some RINEX translators can be set to remove the discontinuity at translation, but this is not necessary since MODEL will account for it in its epoch-by-epoch estimate of the receiver clock offset, and FIXDRV will remove the discontinuities in fitting the low-order polynomial used in modeling the phase observations.  

It is possible to have anomalous ("bad") values in the K-file—computed clock offsets that are many milliseconds off due to bad pseudorange measurements.  The presence of these anomalous blunder points will be indicated by very large residuals (> 100 microseconds) in the polynomial clock fit done by FIXDRV.  You can tabulate and plot the fit residuals using the script CALCK (which calls program PLOTK.EXE), but usually the quickest way to find the problem is just to scan visually the last column of the K-file; most often the bad values are among the first few of the session. 

FIXDRV will read the K-file for each site and create a session I-file, similar to the J-file for satellite clocks, tabulating the coefficients of a low-order polynomial for each receiver's clock.  If you want to recreate a K-file after running MAKEX, you can do so easily by running MAKEK, which will prompt you for the name of input E-, L-, and X-files and for the tabulation interval.

4.10   Creating T-  and G-files from External  Ephemerides

Once the observations have been organized into X-, J-, and K-files, the next step in processing is the generation of a file describing the motions of the satellites.  In GAMIT this information is always input to MODEL in the form of a tabular ephemeris (T-) file, which contains the positions of all the satellites at 15-minute intervals throughout the observation span, or a G-file of initial conditions which are integrated by ARC to create a T-file.  

If the satellite orbits are to be adjusted to fit the observations, then the T-file must also contain partial derivatives of position (as a function of time) with respect to six "initial conditions" and other parameters describing the orbit of each satellite.  ARC generates the partials by numerically integrating their force equations (termed "variational equations") simultaneously with the equations of motion.  If the G-file of initial conditions was obtained from a global orbit solution performed using GAMIT with a compatible version of ARC (e.g., by SOPAC), it can be used directly in ARC to produce a T-file consistent with the solution.  Integration of instantaneous position and velocity values obtained by evaluating the broadcast message parameters or extracted from an external Earth-fixed ephemeris (in SP #3 format) produced by another software package or an incompatible version of ARC will not reproduce the original accuracy since model differences will cause the orbit to deviate from the original orbit as the integration proceeds away from the initial epoch.  The original accuracy can be obtained, however, by estimating initial conditions for ARC using the broadcast or other externally derived positions and velocities over the full session as pseudo-observations.  The most accurate and reliable method of obtaining a starting T-file is to follow this procedure using the shell script sh_sp3_to_gt and an SP #3 file from an IGS analysis center:

	sh_sp3_to_gt    <sp3 file>    <proj>     <yr>     <doy>

where <sp3 file> is the name of the external file (e.g., igs08523.sp3 for day 3 of week 852).  The remaining three inputs are optional and are used to derive the T-file name:   <proj> is the 4-character project code, <yr> is the 1-, 2- or 4--digit year and <doy> the 3-digit day-of-year.  All three can be omitted if station.info and session.info exist in the directory.  The output of sh_sp3_to_gt will be an inertial (J2000) T-file  (and associated G-file) in the form tprojy.ddd which  may be used as input for GAMIT processing (through the D-file, as described in the next section). The ARC run will also create a yprojy.ddd file of satellite yaw parameters for the orbit span (see Section 7.2).  

The script sh_bcfit, introduced with release 9.4 will invoke programs BCTOT and ORBFIT to perform a similar fitting procedure using an evaluation of the broadcast ephemeris as pseudo-observations.  Unfortunately, our filter for detecting bogus values in the RINEX navigation file is not yet sensitive enough to avoid occasional corruption of the fit and hence the resulting G- or T-file.  When there are no outliers, use of sh_bcfit will produce an initial T-file accurate to a few meters.  A less accurate but more robust procedure is to run program BCTOT directly, as with releases prior to 9.4.  Since BCTOT uses only the broadcast elements at the mid-point of the observation span, there is less likelihood of encountering bad values.  The orbital runoff when integrating ICs obtained from these midpoint values, however, can sometimes reach 100 m over a day. 

To obtain a broadcast T-file by fitting values from a RINEX navigation or GAMIT E-file, type

                                                                                         sh_bcfit  <input file>

where <input file> is the bctot.inp produced by MAKEXP:

b	indicates batch input
epgga4.236	RINEX navigation file
xpver4.236	X-file to determine session scenario
tvent4.236	output T-file
y	'yes' to transform the orbit to an inertial frame
J2000	designation of the inertial frame

If you don't have an X-file or wish to create a T-file for a longer span, you can do so by changing the input file to match an alternate set of questions asked by BCTOT:

b	indicates batch input
epgga4.236	RINEX navigation file
	blank line to indicate no X-file
tvent4.236	output T-file
y	'yes' to input the start and stop epochs
94  8  24  1  0  0.	start epoch yy mm dd hh mm sec. in free format
900	tabular interval of the T-file in seconds
94  8  25  19  0 0.	stop epoch 
y	'yes' to transform the orbit to an inertial frame
J2000	designation of the inertial frame

BCTOT and sh_bcfit  will create four files:  an earth-fixed T-file (tproje.ddd ) obtained by evaluating directly the broadcast elements;  an inertial T-file obtained either by rotating this file to an inertial (B1950 or J2000) (BCTOT) or fitting the ARC model to the broadcast messages (sh_bcfit);  a G-file (gprojy.ddd ) obtained by interpolating from the inertial T-file for the epoch requested; and a Y-file of satellite yaw parameters (see Section 7.2).  

The G-file consists of two formatted header lines, one or more comment lines, and initial conditions and force parameters for one or more satellites.  Shown below is a typical G file: 

86 279 12 00 00                   GPST B1950 IAUT68 SPHRC
8 X    Y    Z    XDOT YDOT ZDOT DRAD YRAD ZRAD
G-file generated from ebrdc6.279    1-10-1987  18:16:20
ANY OTHER COMMENT LINES
END 
PRN 06
-.24748600267000D+05 
0.88024642750000D+04 
0.47948566210000D+04
-.11532236900000D-01
-.18622397472000D+01
0.33736392796000D+01
0.10000000000000D+00
0.00000000000000D+00
0.00000000000000D+00
PRN 09
-.21643530559117D+05
-.15228859494884D+05
-.17710854977416D+04
0.11606424294013D+01
-.12653416265926D+01
-.34787168623116D+01
0.10000000000000D+00
0.00000000000000D+00
0.00000000000000D+00
END

The first line gives the epoch of the ICs in GPST  or UTC (year, day-of-year, hours, minutes, seconds), followed by the time type (GPST or UTC), the inertial frame for the ICs (J2000 or B1950), the precession constant used (IAU76 or IAU68), and the model for non-gravitational ("radiation") accelerations (SPHRC for "spherical" in the example shown (see Section 5.2).  The second line gives the number of ICs plus force-model parameter to be read from the G-file   This is followed by one or more comment lines, terminated by END.  The initial conditions for each of the satellites are given as Cartesian components of the position and velocity vectors in units of km and km/s.  The last three ICs of each group in this example are dimensionless coefficients multiplying the modeled direct solar radiation force (DRAD) and forces along the y- (YRAD) and z- (ZRAD) axes of the spacecraft.  The coefficients RAD2 and RAD3 express these forces as fractions of the nominal direct solar radiation force.