Did you ever wonder how we draw our station icons () on Google Maps? We simply convert our Earth-centered Earth-fixed cartesian station coordinates (X-Y-Z) to geodetic coordinates (latitude-longitude-height) using the WGS84 ellipsoid implemented in Google Maps (and using as many decimals as possible!) Then we use the Google Maps API to render the icon at the desired location.

But when we zoom in at the maximum level in Google Maps using satellite imagery we observe that most of the times the icon does not coincide with the actual position of the station antenna on the image. The image below shows the “gien” station antenna on the roof of INRiM, the Italian metrological institute in Turin. The station icon is around 5 meters away from the actual antenna!

How is this possible? Didn’t we say in a previous post that our coordinates have an accuracy of a couple of centimeters? The answer is that satellite images on Google Maps are in general georeferenced with an accuracy of just a few meters, which is of course enough for most users. For example if you use a normal handheld GPS receiver you get a positioning error of several meters, which is usually good enough to navigate through streets and roads without the need of a perfectly georeferenced map.

As from today we are moving to a new core station data management approach. We realize that in general for the user it is more useful to have recent data from many stations and with as little latency as possible. Unfortunately keeping old data from many stations on the magicGNSS server takes a lot of disk space (typically each station takes around 80 Mb of uncompressed RINEX data per day).

Until now we kept on the server core station data starting from July 1st 2008, to current time. As from now we will keep a moving window of one-month duration, i.e., the last 30 days of data will be always available on the server, and older data will be automatically deleted.

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!

Read the rest of this entry »

Today we are at the GIOVE Workshop in ESTEC, the European Space Agency technology center in Noordwijk, The Netherlands. The experimentation results of GIOVE-A and GIOVE-B, the first two experimental Galileo satellites, are being presented to the media. GIOVE-B carries a Passive Hydrogen Maser (PHM) on board, the most accurate atomic clock ever flown in space. This clock has an awesome stability that allows to predict its evolution within just one nanosecond after one day.

GMV has been involved in the different Galileo test beds since the early stages of the mission. In particular, we had the privilege to observe for the first time the behaviour of GIOVE-B’s PHM clock from ground using our EOSPF (Experimental Orbit and Synchronization Processing Facility), the operational software for GIOVE experimentation developed by GMV for ESA.

To celebrate the GIOVE Workshop and the success of the GIOVE Mission, magicGNSS is wearing a new “dress” today: go to the main web page and you will be able to see a colour map showing the geographical coverage of the 13 GPS+GIOVE dual stations that have been deployed by ESA worldwide.

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.

Read the rest of this entry »