GPS Dancer estimates global parameters and local parameters in routine batch least squares solutions.

Local parameters are pre-eliminated by each Dancer process, so that a normal equation system remains to be solved for the global parameters only. These global parameters are solved collectively over the internet, via a distributed solution method. Each Dancer process can then substitute the global solution vector in its pre-elimination equation to find the local parameters of its CORS station. 

The following parameters are typically adjusted in the Dancer least squares solution process:

  Parameter type occurrence total(*)
Global UT1-UTC offset 2 per arc (third is fixed) 2
  Xp polar motion parameter 3 @ 24 hour intervals 3
  Yp polar motion parameter 3 @ 24 hour intervals 3
  Translation of origin for no-net-rotation condition 3 per arc 3
  Orientation of axes for no-net-rotation condition 3 per arc 3
  Scale in no-net-rotation condition 1 per arc 1
  Initial position of the satellite 3 per arc per satellite 90
  Initial velocity of the satellite 3 per arc per satellite 90
  Empirical solar radiation perturbations of the satellite 6 or 9 per arc per satellite 180 or 270
  Empirical manoeuvre calibration factors in-plane / out-of-plane 2 per manoeuvre ~6
  Satellite clock biases 1 per epoch per satellite 172800
Local Antenna offsets relative to a priori coordinates 3 per arc 3
  Empirical wet troposphere zenith delays 1 @ 1 hour intervals 49
  Empirical troposphere gradient parameters East 2 per arc (start and end, interpolated) 2
  Empirical troposphere gradient parameters North 2 per arc (start and end, interpolated) 2
  Phase ambiguity biases per pass 1 per pass ~150
  Receiver clock biases 1 per epoch 5670

(*) total amount for a process with 30 active GPS satellites, 3 manoeuvres, 150 passes per receiver, 48 hour arc length, 30 second epoch sample intervals. Actual amounts vary depending on network geometry, constellation geometry etc.

As will be clear, the process is dominated by the satellite clock parameters which represent more than 99% of the global parameters, and are therefore responsible for almost all internet data traffic during the distributed solution process. During test phases, GPSdancer reprocesses a single week of data over and over again, and can use the IGS final clock solutions for the satellites as fixed inputs. This reduces the internet traffic to a very small fraction of what is needed in nominal operations.

Polar motion parameters are estimated as constant values at the start and end of the arc, and are interpolated linearly after removal of the sub-daily tidal effects. From the time series of these Dancer polar motion parameters, daily values are derived at midnight UTC, defined in the same way as the polar motion parameters from IERS. Absolute UT1 offsets can not be observed from GPS data alone, so that the first of the two required UT1-UTC offsets is kept fixed in each process.

The Helmert parameters (translation, rotation, scale) are accumulated in a separate 7 x 7 normal matrix from the a priori station coordinates of all participating receivers. The inverse of this matrix is necessary during the application of minimum constraints on the normal matrix, in order to maintain reference frame stability from one solution to the next. Still, the effects of process noise and overall accuracy limitation of the solutions will lead to a "random walk" behaviour of the polar motion parameters - notably, UT1 - without some sort of long-term constraint to a fiducial reference frame. Several options are available to resolve this. For the time being, and probably for several years to come, GPSdancer will constrain the solution to the formal ITRF 2014 solution (position and velocities). This will only work if an adequate number of CORS stations in the solution has formal ITRF 2014 solutions.

Initialization of the global parameters is done on the basis of the previous solution (orbits, polar motion), or on the basis of mean residuals per epoch (new satellite clocks). A new process that enters the solution will request the most recent global parameters from any existing Dancer process in the peer-to-peer network.

Project details

Ultimate Browsers SupportThe GPS Dancer project started in 2007 as a voluntary project of a working group of the International Association of Geodesy.

Read more ...

Square dance algorithm

Great Docs and SupportThe GPS Dancer system was named after its "square dance" exchange algorithm. Of course, it also wants to to make the GPS reference frame denser.


Here, there be pirates

The Dancer on-line network became immune against internet connection problems by leaving the US marines, and becoming a pirate.

Read more ...

Go to top