Ocean loading is the deformation of the Earth due to the weight of the ocean masses. The water in the ocean moves due to the gravitational pull of the Moon and the Sun (this is the tides), and causes the Earth, which is not completely rigid, to deform according to the varying load of the ocean’s water. The deformation is periodic, following the relative motion of Earth, Moon and Sun, however such relative motion is rather complex and thus periodicity has to be represented with several harmonic terms of different period.

Periodicity of tides around the world (graphic from NOAA)

Most commonly, the 11 first terms (i.e. those with higher amplitude) are retained to model this effect.

Ocean loading can be perceived as a periodic displacement of the station position (especially in coastal areas), as well as a periodic variation of the Earth’s gravity.

How is ocean loading taken into account in magicGNSS?

(more…)

Have you ever noticed that a satellite you configured in magicGNSS Beta is missing in the ODTS outputs and report? If this is the case, the satellite was likely unavailable during the configured dates.

As a GNSS user, you may be familiar with the NANUs. NANUs are messages published by GPS operators to inform about events occurring to the GPS constellation (such as maneuvers, on-board equipment maintenance, decommissioning, etc) affecting satellite availability.

magicGNSS needs to know about satellite availability, in particular those events that would affect ODTS, namely:

• New satellites declared active
• Existing satellites being decommissioned
• Satellites being manoeuvred

In order to achieve this, magicGNSS automatically gets NANUs as they are issued, parses them, extracts the relevant satellite availability information and stores it in its database. This is not a trivial issue, as there are 12 types of NANUs, according to the information they provide: the type of outage, whether it is scheduled or not, or other type of information. All the historic information is kept, so each ODTS execution will only consider satellites available in the scenario defined by the user no matter the dates selected!

Among the products you get from magicGNSS Beta there are satellite and station clock estimations and predictions. By “satellite and station clocks” we mean the offset of these clock as seen by the ODTS with respect to the clock of the station selected as reference clock in the Settings tab, at every measurement epoch.

What synchronisation performances can we obtain with magicGNSS? The comparison of the satellite clock estimations with the IGS ones is typically within 0.15 ns RMS:  this means that magicGNSS is a very powerful means of synchronising remote clocks, provided they are connected to a GNSS receiver!

(more…)

As explained in the previous entry of this blog, the ODTS algorithm inside magicGNSS is able to calculate precise station coordinates. Another technique that is becoming increasingly propular to calculate receiver coordinates is Precise-Point-Positioning (PPP).

The main difference between ODTS and PPP is that ODTS is a multi-station global solution that calculates also satellite orbits and clocks, and PPP is a single-station technique where satellite orbits and clocks are solved beforehand using an independent software (or are fixed to IGS solutions). ODTS is based on a batch least-squares algorithm whereas PPP is normally based on a sequential filter that solves for the user reciever coordinates, clock, tropo, and phase ambiguities.

(more…)

One of the available scenario settings is the “Refine Station Coordinates” check box. When this is checked, magicGNSS will estimate the station coordinates, yet keeping a constraint to their initial value, as provided by ITRF (or the IGS). This refinement can compensate for some inaccuracies, such as some mismodelling of the Earth motion, thus helping to achieve better performances.

On the other hand, when the observability is not good enough (e.g. when the number of stations/data is insufficient or their distribution is poor) the estimation of the coordinates may be correlated with other parameters and lead to a degradation of performances! So, should one check the box or not?

(more…)