# goGPS command language

goGPS have been designed to be flexible and expandable. To allow different types of processing and complex operations a pseudo-language have been created. It allows sequential and parallel operations. On this page, the meaning of all the commands can be found. For a short Help on all the commands available type goHelpCommands in MATLAB command window.

## Index of contents

To be able to understand how goGPS works it is necessary to make a brief recap on the internal organization of the data. goGPS is object-oriented, every receiver is considered a unique GNSS_Station, internally the software stores data in two objects: work, and out. Work is an object of class Receiver_Work_Space and contains the observations and everything is needed for the computation of the results of a single session, out is an object of class Receiver_Output and collects the output of a receiver for all the sessions. The results stored in the work object are pushed to out only when the PUSHOUT command is issued. The following flags select the output to be kept. Note: the data stored in out can take a lot of RAM space, this is the reason for the possibility of selecting what must be kept.

## Minimal script

The goGPS language uses a basic fixed structure to perform commands: an external FOR loop running on the sessions to process, and optionally internal loops on the receivers to process. Without a session loop, goGPS cannot do anything, this loop initializes the receiver work-spaces and prepares the needed resources (e.g. load orbits).

A basic example structure is the following:

FOR S*
<some commands>
PUSHOUT T*
END
<some commands>


Every FOR loop must be terminated with an END. Sessions must be selected according to "How to select sessions" and receivers according to "How to select receivers"

### PUSHOUT

To save the results of the processing in the out part of the receiver PUSHOUT is called on all the target receivers. At least one target receiver must be specified. The results to be copied from the receiver work-space (of a single session) to the receiver output (of multiple sessions) are specified in the processing panel

Command modifiers:

• @ - processing rate in seconds (e.g. @30s, -r=30s)

It is possible to store the date at a different rate of the one used for the processing, use values that are multiplier of the processing rate. This modifier allows saving memory, all the export on the out object of the receiver will be affected. If the modifier is not used the results are exported at the rate of processing.

Usage example:

Pushing results at a rate of 5 minutes

PUSHOUT T* @300s


## How to select sessions

After the keyword FOR the letter S (Session) follows, to indicate the number of the session(s) to process iteratively various options are given to the user:

• S* - the symbol '*' is used to indicate ALL the sessions, and will make goGPS iterate from session 1 (the first) to the last that is set to be processed;
• S1,2,5,6 - separating numbers with the ',' symbol makes goGPS process the session in the selected order;
• S3:6 - using the symbol ':' it is possible to select a list of sessions, in this example, the sessions 3,4,5,6 will be processed;
• S1:7:30 - similarly to the previous case, like in MATLAB syntax it is possible to provide a step to generate the list of sessions to be processed, in this example, the sessions 1,8,22,29 will be processed;
• S10:END - the keyword END or E indicates the last session.

Combinations of the above are possible: e.g. S1:3,6,24:2:30 will select sessions 1,2,3,6,24,26,28,30.

In goGPS language, the user needs to define the receivers that have to be processed or used for particular goals, some commands require different "types" of receivers:

• T* this indicates Target receivers, these are the receivers on which the commands will act directly;
• R* this indicates Reference receivers, these are the receiver used by the commands for special purposes, e.g. reference receiver in a network adjustment, or reference receiver in an interpolation procedure;
• P* this indicates receivers to be Passed as is, in a parallel loop the receiver indicates with the "P" letter will be sent to all the parallel slaves. As for the sessions, the user can apply the same numbering convention of the sessions:
• T* - the symbol '*' is used to indicate ALL the receivers, and will make goGPS iterate from receiver 1 (the first) to the last available;
• T1,2,5,6 - separating numbers with the ',' symbol makes goGPS process the receiver in the selected order;
• T3:6 - using the symbol ':' it is possible to select a list of receivers, in this example, the receivers 3,4,5,6 will be processed;
• T1:7:30 - similarly to the previous case, like in MATLAB syntax it is possible to provide a step to generate the list of receivers to be processed, in this example, the receivers 1,8,22,29 will be processed;
• T10:END the keyword END or E indicates the last receiver.

Combinations of the above are possible: e.g. T1:3,6,24:2:30 will select receivers 1,2,3,6,24,26,28,30.

## Main commands

The minimal commands needed for processing GNSS data are three: LOAD, PREPRO, PPP or optionally NET, knowing these plus the session loop allows processing some data.

An example of PPP processing can be

FOR S*
PREPRO T*
PPP T*
PUSHOUT T*
END


FOR S*
PREPRO T*
NET T* R1
PUSHOUT T*
END


The setting panels are used to define the main options of these parameters but some modifiers can be used in the goGPS language commands.

Here it follows the description of each command.

The load command allows the software to import data from RINEX files. The files that are going to be loaded are selected in Data Sources tab and are relative to the current session. One or multiple targets need to be specified for the command to work. goGPS imports all the data at the rate stored into the RINEX files for all the constellation enabled in Pre-Processing tab unless some modifiers are used

Command modifiers:

• -s= - active constellations (e.g. -s=GRE)
• @ - processing rate in seconds (e.g. @30s, -r=30s)

It is possible to load the data at a different rate (as long as it is a multiple of the data rate stored in the files) and for a subset of constellations. The software read the file in blocks but when these options are enabled goGPS will import only the requested data, i.e. importing a file containing data at 1Hz at a lower rate (e.g. 30s) is faster than importing its original rate.

Usage example:

_Import the observations for the GPS and Galileo constellations @30 seconds rate for the current session for all the receivers

LOAD T* @30s -s=GE


Go back to the Index of contents

### PREPRO

The pre-processing command is a mandatory command to prepare the loaded observations for further operations. In this function goGPS performs different tasks:

1. code positioning - needed for computing a good a-priori position of the receiver, this is done unless a-priori coordinates are provided with a coordinate file in Receiver Info tab;
2. computation of clock delays (from code observations)
3. computation of satellite positions at the time of signals transmission
4. synchronization of the receiver to the nominal epoch of observation - low-cost receivers, and some geodetic ones may read the observations with an incorrect inconstant rate. To avoid problems in network solutions, and to restore a constant observation rate goGPS apply a correction term to all the observations to "move" them to the proper epoch. This term is computed by taking the difference of the synthesized pseudo-ranges at the nominal (transmission) time and at the observed (transmission) time (e.g. shifted by a few milliseconds).
5. computation of a-priori atmospheric delays
6. application of all the PPP corrections enabled in the settings
7. outliers detection

Command modifiers:

• -s= - active constellations (e.g. -s=GRE)

Tip:

It might be useful to speed-up computation to enable the data of a single constellation by using the "s=" modifier. goGPS will only perform a faster a-priori position, but all the other observations of different systems will be pre-processed as if they are enabled. Meaning that PPP corrections, atmospheric delays, and outlier detection will be performed on all the data. The command as written in the following usage example can be adopted even when a multi-constellation final result is wanted.

Usage example:

PREPRO T* -s=G


Go back to the Index of contents

### PPP

Perform a Precise Point Positioning on all the target receivers. The strategy to be adopted for the atmospheric parametrization and for the applied corrections must be pre-selected in the settings and can be changed in the GUI before executing the processing.

Command modifiers:

• -s= - active constellations (e.g. -s=GRE)
• -u - (flag) use the Uncombined engine

When the modifier -U is passed to the command the uncombined PPP engine is selected and uncombined residuals are computed.

Tip:

The uncombined engine for PPP solutions is a bit slower than the combined version, at the moment for most of the usage the combined engine is still the best choice.

Usage example:

PPP T*


Go back to the Index of contents

### NET

Perform a Network adjustment on all the target receivers, using the selected reference receiver(s). This command allows computing individual baselines (e.g. NET T1:2 R1) or full network adjustments with many receivers (e.g. NET T1:10 R*)

Command modifiers:

• -s= - active constellations (e.g. -s=GRE)
• @ - processing rate in seconds (e.g. @30s, -r=30s)
• L - band to be used for single frequency adjustment (e.g. L1)
• --free - when the stations are distant (long baselines) they can be considered uncorrelated, use this flag to compute an absolute coordinate position
• COO_CRD - export coordinates as a .CRD file - this export have been created for debugging testing but it is unsupported, use the EXPORT command instead
• --clk - export the common parameter in network - this export have been created for testing purposes of the combined engine but it is unsupported
• -u - (flag) use the Uncombined engine (the old combined engine for the network adjustment is deprecated, the uncombined version will be always used)

Tip:

The uncombined engine for Network solutions is slower than the combined version but it can perform better and works on long baselines.

Usage example:

NET T* R1


Go back to the Index of contents

Now that the main commands have been described the for loop on receivers can be introduced. To use it the keyword FOR must be followed by the receivers to target and the subset of commands to be executed in the loop must be closed with an END keyword

Usage example:

This example uses the FOR loop to perform PPP sequentially, then computes a Network Adjustment on all the receivers

FOR S*
FOR T*
LOAD T$PREPRO T$ -s=G
PPP T$END NET T* R* -free -iono -U PUSHOUT T* END  Note that the $ symbol is used within the target loop, this symbol indicates the current target. At each iteration, it will assume the value of the current target, in this case: 1,2,...till the number of receivers.

## Parallel execution

goGPS uses a custom implementation of parallelism based on a master-slaves approach. This approach may have different drawbacks but does not require the MATLAB Parallel toolbox. goGPS automatically executes new instances of MATLAB in the background (sometimes on the Windows platform some of them fail to start properly and they are visible), then for each of these new instances, the software will start a function capable of waiting or executing limited tasks. To start a slave manually a user can execute:

gos = Go_Slave.getInstance(); gos.live();


The MATLAB executing goGPS is the Master that dispatches jobs and collects results. All the communications are managed by writing and reading files on a disk, it is important for speed purposes that this folder is created on a fast drive. The "communication" directory path is set in the project ini file and can be modified in the Advanced tab of the GUI.

The class Parallel_Manager have been created to manage the parallel slaves:

• Parallel_Manager.killAll(); run this to kill background slaves
• Parallel_Manager.testSlaves(); run this to test the status of the background slaves
• Parallel_Manager.requestSlaves(<num_of_slaves>); run this to initialize "num_of_slaves" slaves

To simplify the generation and maintenance of the slaves two goGPS commands have been created:

### PINIT

This command is used to initialize or check the existence of parallel slaves running in the background

Command modifiers:

• -n= - this is the only parameter (mandatory) that specify the number of background tasks to be executed in parallel (e.g. PINIT n=7, or alternative syntax PINIT N7)

Usage example:

PINIT -n=7


Go back to the Index of contents

### PKILL

This command has no parameters and allows to kill all the slaves in the background (all the MATLAB instances running slaves will be closed)

Usage example:

PKILL


Note 1: unfortunately due to bugs or unexpected operations some of the background instances may be still alive even after issuing a PKILL command. in this case, it is recommended to manually kill the MATLABs running in the background using a task manager.

Note 2: closing goGPS without issuing this command will leave the slaves running in background alive.

Go back to the Index of contents

### PAR

Once slaves have been created a parallel execution can be used. There are two types of supported parallel executions in goGPS:

1. Parallel session processing
2. Parallel targets processing

It is possible to use only one type of execution at a time. They work just like a FOR loop but with the keyword PAR

Usage example 1: This example uses the PAR loop to perform PPP processing on all the targets parallelizing the sessions

PINIT N5
PAR S*
FOR T*
LOAD T$PREPRO T$ -s=G
PPP T$END NET T* R* -free -iono -U END PKILL  Note: the PAR loop on sessions automatically executes PUSHOUT after loading the data processed by each slave. Slaves only save the work-space of each processed receivers and not the output part. Usage example 2: This example uses the PAR loop to perform parallel PPP processing on all the targets for all the sessions PINIT N5 FOR S* PAR T* LOAD T$
PREPRO T$-s=G PPP T$
PUSHOUT T$END END PKILL  Note: parallel slaves do not receive automatically all the receivers as stored in the Master process; when they start an execution they have empty receivers unless the modifier P is used. On the contrary, the object GNSS_Station (containing both work and out) is imported by the master process as is found in the Slave at the end of its computations. Command modifiers: • P* - work-spaces to be passed to the slaves This means that this code to compute all the baselines with respect to the first receiver is not working: PINIT N5 FOR S* LOAD T1 PREPRO T1 -s=G PPP T1 PAR T2:END NET T1,$ R1   <= the receiver 1 for the slaves is empty
END
PUSHOUT T$END PKILL  while this is ok: PINIT N5 FOR S* LOAD T1 PREPRO T1 -s=G PPP T1 PAR T2:END P1 <= the work-space of receiver 1 is passed to all the slaves NET T1,$ R1
END
PREPRO T$-s=G END SID R1:4 T5 PLANE PPP T* END SHOW T* ZTD  Go back to the Index of contents ### REMIONO This command can be used similarly to SEID it has been created as an experimental Satellite specific Epoch differenced Ionospheric Delay algorithm, in addition to the original approach it tries to smooth the computed geometry-free. Instead of generating a synthetic L2 it removes the ionospheric delay to the phase observations of the target receiver. Without generating the second frequency it generally behaves worse than the previous approaches because outlier rejection works differently and a stronger regularization is required to have a comparable result, for these reasons the command is present but kept as experimental under testing. Go back to the Index of contents ## Multipath management goGPS integrates the possibility of creating and using multipath maps to mitigate the effect of reflections in the GNSS carrier-phase signals. We create our maps by processing a long period of data (10 days minimum are suggested) with the goGPS engine. From the obtained carrier phase residuals we can then generate maps of the common "geographical" errors in the polar coordinate system (e.g. Multipath effects coming from structures are always affecting the signals the same way, so each satellite transmitting from a certain elevation and angle is always affected by the same multipath disturbance). Multipath maps can be then used to mitigate the range errors allowing a better positioning. Our preliminary test shows that coordinates estimated for short sessions (e.g. every 15 minutes/hourly) can be improved by about 15-30% depending on the level of multipath. goGPS can apply multipath maps of RAW observations in the step of PREPRO, if maps of iono-free combinations are present they will be applied in the generation of the static PPP system, combined maps will not modify the observations directly. Before interpolating the residuals these are selected by filtering the worse observations, in particular, in addition to the snooping methods applied in the PPP/NET solutions, a 3sigma threshold is used to discard outliers. Residuals falling in a bin of 1 degree in latitude and 360 in longitude are used to evaluate latitude by latitude the variance of the residuals, all the observation above the 3sigma level are ignored in the interpolation process (about 1-1.5% of the data are usually disregarded). To regularize the solution for each cell of 1x1 degree with less than 2 observations 1 null pseudo-observation is added to the dataset to be interpolated. For each frequency (or combination) present in the receiver, a multi-step procedure is used to generate the goGPS multipath maps 1. Uncombined carrier-phase residuals are all used in a LS solution to compute the Zernike expansion coefficients up to degree 43 (can be changed in the code). These coefficients are then used to synthesize a map of 0.5x0.5 degree in the cartesian coordinate system elevation x azimuth (180x720). Zernike polynomials are good to map low degree changes on the disk (e.g. PCV) but for Multipath maps, a higher degree is preferable. Zernike polynomials are capable of describing changes in the signal depending on the distance from the center of the disk, with a radius close to 1, higher frequencies can be represented. In goGPS we perform 3 analyses at the same degree level using 3 mapping functions to map the elevation to the unitary radius so that we can better describe the undulations due to multipath. The two mapping functions are: After a first analysis, the second is performed on the residuals of the first, and so the third. A synthetic final map is computed by adding the three matrixes. The figures show the maps retrieved from the first two iterations of the Zernike based interpolation for the WTZZ station. 1. Stacking maps can be generated from the residuals of the previous step that provides an interpolation of the lower frequencies. The gridding procedure uses congruent cells, for each cell the mean is taken, each value is converted in polar coordinates and a final grid at the resolution of 0.5 degrees in cartesian coordinate (elevation x azimuth) is created by bi-linear interpolation in the polar coordinate system. These are the third iteration and the final gridding step on the residuals of the WTZZ station. At the end, the maps are summed all together to generate two possible applicable models, the first smoother, and the second containing the higher frequencies of the staking map. The user can decide the map that works best in his project by selecting it in the settings. On the left the smoother solution, on the right the highest details of the staking are preserved In addition to these two grids goGPS will create other four grids starting from the residuasls. This is useful for comparison of the methods and testing. • two Regular grids are estimated. One using only the observation available and another adding zeros observations in cell of 1x1 that are empty and upscaling it linearly to a 0.5x0.5 degree grid. • two Congruent cells grids are estimated. One using only the observation available and another adding zeros observations in cell of 1x1 that are empty and upscaling it linearly to a 0.5x0.5 degree grid. The number of cells of a congruent grid decrease with the increase of the elevation. See also: Fuhrman et al 2015 Example of a congruent grid showing how the number of cells decrease with elevation ### MPEST The command MPEST can be used on a target receiver previously processed in PPP/NET with that still contains phase residuals. It automatically generates six maps for each observation combination (or RAW): one estimated from Zernike interpolation and the second by simple stacking, plus two regular grids and two congruent grids. If multipath mitigation is enabled, and uncombined residuals are present, at the end of the computations, the command applies the corrections to the phase observations contained into the receiver. The result of the command is stored in the obj of class GNSS_Staion in the field ant_mp. Use EXPORT T* MP to export a multipath map. Usage example: Multipath maps creation PAR S* FOR T* LOAD T$ @30s
PREPRO T$-s=G PPP T$ -U
END
PUSHOUT T*
END
MPEST T*
EXPORT T* MP


Go back to the Index of contents

## Other Commands

Additional commands may be used to do minor operations, such as clean part of the objects to free up space, rename receivers, compute simplified positions, or filter observations:

### RENAME

Rename is a simple command that allows setting the Marker Name of a receiver, this may be useful when comparing the same receiver processed with different approaches

Usage example:

Suppose to compare the station ZIMM processed with GPS only, GLONASS only and Galileo only, one may rename the station, loaded tree times from the same RINEX file, as ZIMG, ZIMR, ZIME, to display different labels in the plot

FOR S*
PREPRO T*
PPP T*
RENAME T1 ZIMG
RENAME T2 ZIMR
RENAME T3 ZIME
END
SHOW T* ZTD


Go back to the Index of contents

### EMPTY

This function resets the content of the target GNSS_Station like it was not yet loaded and processed freeing up all of the memory

Usage example:

Computing ZTD for 100 stations freeing the memory after export (one session)

FOR S1
FOR T1:100
LOAD T$PREPRO T$
PPP T$EXPORT T$ TRP_SNX
SHOW T$ZTD -e -c EMPTY T$
END
END


Go back to the Index of contents

### EMPTYWORK

This function resets the content of the Work-space (the current session) of the target GNSS_Station freeing up some of the memory occupied by the receiver

Usage example:

Computing PWV for 100 stations freeing the memory after export (multiple session)

FOR S*
FOR T1:100
LOAD T$PREPRO T$
PPP T$PUSHOUT T$
EMPTYWORK T$END END SHOW T* PWV  Go back to the Index of contents ### EMPTYOUT This function resets the content of the Output object of the target GNSS_Station freeing up some of the memory occupied by the receiver Usage example: Computing two images of PWV comparison, one for the first 10 sessions one for the second 10 sessions FOR S1:10 FOR T* LOAD T$
PREPRO T$PPP T$
PUSHOUT T$EMPTYWORK T$
END
END
SHOW T* PWV -e

FOR S11:20
FOR T*
LOAD T$PREPRO T$
PPP T$PUSHOUT T$
EMPTYWORK T$END END SHOW T* PWV -e  Go back to the Index of contents ### REMTMP Similar to the EMPTYWORK command this function removes from the Work-Space all the data not needed for the push of the results, might be useful in parallel computations to limit the number of data saved on disk and to free some memory. Usage example: Computing ZWD for multiple parallel sessions. Remember that the PAR loop on sessions automatically execute PUSHOUT after loading the data processed by each slave and so it requires the object work to be exportable (EMPTYWORK cannot be used here) PINIT N5 PAR S* FOR T* LOAD T$
PREPRO T$PPP T$
REMTMP T$END END SHOW T* ZWD  Go back to the Index of contents ### AZEL Compute Azimuth and elevation of a receiver, if a position has been computed or it's present in the coordinate file. Usage example: Computing azimuth and elevation to display a polar plot of the SNR of a receiver FOR S1 LOAD T1 AZEL T1 SHOW T1 SNR END  Go back to the Index of contents ### BASICPP Compute a simple but fast code position on a target receiver without applying any range correction Usage example: Creating an a-priori coordinate file for all the receivers FOR S1 LOAD T* BASICPP T* EXPORT COO_CRD END  Go back to the Index of contents ### CODEPP Running this command goGPS will compute a Code Positioning, this command does not perform any outlier rejection and does not apply any desync of the observations, it should not be used without running a pre-processing on the target receives. Usage example: CODEPP T1  Go back to the Index of contents ### OUTDET Perform outlier detection on phases, normally this is done in pre-processing but there are cases when this is useful, in fact, PPP and NET processing modify the status of the outliers. Usage example: In this case OUTDET is used to reset the flagged outliers at each iteration FOR S* LOAD T1 PREPRO T1 -s=G PPP T1 FOR T2:END P1 OUTDET T1 NET T1,$ R1
END
PUSHOUT T\$
END


Go back to the Index of contents

### FIXPOS

This command allows changing the reference coordinate type (by default it set the position as fixed).

Command modifiers:

• FROM_WORK - (flag) use data from Work Space (current session)
• FROM_OUT - (flag) use data from Receiver Output object
• AS_APR - (flag) use position as a new a-priori position (not as fixed)

Usage example:

In this example a PPP solution is computed in the first session, later the other 29 sessions are processed with the fixed position of the first session

FOR S1
PREPRO T1 -s=G
PPP T1
FIXPOS T1
END
FOR S2:30
PREPRO T1 -s=G
PPP T1
END



Go back to the Index of contents

### KEEP

This command can be used to remove some data from the receiver's work-space by telling goGPS what to keep.

Command modifiers:

• @ - Rate in seconds (e.g. @30s, -r=30s)
• **-s= Active constellations (e.g. -s=GRE)
• **-e= Cut-off elevation in degree (e.g. -e=7)
• **-q= SNR threshold in dbHZ (e.g. -q=7)

Usage example:

Keep only observations of GPS satellites having elevation greater than 15deg

KEEP T1 -s=G -e=15


Go back to the Index of contents

### SYNC

Syncronize all the receivers at the same rate, keeping only the epochs between the first and the last among all the receivers.

Command modifiers:

• @ - Rate in seconds (e.g. @30s, -r=30s)

Usage example:

SYNC T* @60s


Go back to the Index of contents

### REMSAT

Remove all the observations of a satellite from a target receiver. The function accepts a single list of satellites to be removed with the first letter of the constellation (GREJCI) and two digits for the PRN number.

format: <1ch sat. sys. (GREJCI)><2ch sat. prn>

Usage example:

_Remove GPS satellite with PRN 4 or PRN 29, and the Galileo satellite with PRN 25.

REMSAT T* G04,G29,E25


Go back to the Index of contents

### REMOBS

Remove some observation types from a target receiver.

format: <1ch obs. type (CPDS)><1ch freq><1ch tracking>

Usage example:

Remove from the first receiver all the doppler observations, the SNR of the second frequency and the second frequency of carrier-phases of the civilian tracking

REMOBS T1 D,S2,L2C


Go back to the Index of contents