magicGNSS’ Galileo-only PPP among the first 50 Galileo navigation fixes recognized by ESA

August 5th, 2014 by Guillermo Tobías

On May 31st 2013, magicGNSS team computed a 2-hour long Galileo-only batch PPP (the 4 IOVs disposition provided up to 3 hours of common view over Europe) for a TRIMBLE R10 receiver located at GMVs premises. The reference products used were computed by means of magicGNSS’ ODTS tool, based on the MGEX network (http://igs.org/mgex/) .

The obtained receiver coordinates were compared with the reference ones obtained by means of a GPS-only PPP using as reference products IGS final products. The positioning error was below 5 cm in all 3 components!

This Galileo-only PPP has been recently recognized by ESA as one of the first 50 Galileo navigation fixes.(http://www.esa.int/Our_Activities/Navigation/Pioneer_Galileo_navigation_fixes_recognised_by_ESA)

GRIAL replaces TEQC in magicGNSS

July 23rd, 2014 by Guillermo Tobías

GMV has developed a new tool to analyze RINEX, GRIAL (Gmv RInex Analyze).

Up till now, magicGNSS has been using TEQC to validate the incoming RINEX. TEQC is developed and distributed by Unavco. Teqc (http://facility.unavco.org/software/teqc/teqc.html) is a powerful and well-tested tool, but it has two important limitations which affect our platform:

  • It performs a very strict format validation that leads to reject many RINEX usable by the PPP/ODTS.
  • It does not support new RINEX version (3.xx). This is becoming an important problem as most of the multi-GNSS receivers generate RINEX 3 files.

GRIAL has been developed to solve these problems and provide more flexibility to magicGNSS. In this process, the GMV team has tried to adjust the product to the current needs.

Main GRIAL achievements:

  • Increases the flexibility regarding the file format.
  • Accepts more compression types (.zip, .ZIP, .gz, .GZ, .z, .Z).
  • Users can upload several RINEX files compressed in the same file.
  • It provides detailed information about the error type and the location (file and line).
  • It solves the most common errors as: blank lines, RINEX version missing or incorrect, empty interval, missing time of first observation…

We hope that this new tool helps the GNSS user’s community!

New place for our GAP1 files

June 10th, 2013 by Ricardo Píriz

We have now a new ftp address on the GMV server for the RINEX measurement files coming from our GAP1 station. The files can now be downloaded with the following login information:

  • server: ftp.gmv.es
  • user: magicgnssro
  • password: R0gnss06

We are storing hourly files at a 1-second rate and daily files at a 30-second rate. The files can be accessed on a web browser through the following URLs (examples):

ftp://magicgnssro:R0gnss06@ftp.gmv.es/gap1161j.13d.Z (hourly file)

ftp://magicgnssro:R0gnss06@ftp.gmv.es/gap11610.13d.Z (daily file)

Files are kept on the server for the last 45 days, older files are also available upon request.

GAP1 station now contributing to IGS’ MGEX

July 30th, 2012 by Ricardo Píriz

Our GAP1 station is now contributing GPS+GLO data to the IGS’ MGEX experiment (RINEX files and real-time stream). RINEX files are available on the following ftp servers: CDDIS (USA), BKG (Germany), IGN (France). Hourly high-rate files are also available at GMV’s ftp server as usual (see below). A new GAP1 station log is also available. Galileo data is not yet ready due to unavailability of the required receiver firmware.

  • Daily files (@ 30 sec):

ftp://cddis.gsfc.nasa.gov/gnss/data/campaign/mgex/daily/rinex2/

ftp://igs.bkg.bund.de/MGEX/obs

ftp://igs.ign.fr/pub/igs/data/campaign/mgex/daily/rinex2

  • Hourly files (@ 30 sec):

ftp://cddis.gsfc.nasa.gov/gnss/data/campaign/mgex/hourly/rinex2/

ftp://igs.bkg.bund.de/MGEX/nrt

ftp://igs.ign.fr/pub/igs/data/campaign/mgex/hourly/rinex2

  • High-rate files (@ 1 sec):

ftp://cddis.gsfc.nasa.gov/gnss/data/campaign/mgex/highrate/rinex2/

ftp://igs.bkg.bund.de/MGEX/highrate

ftp://igs.ign.fr/pub/igs/data/campaign/mgex/highrate/rinex2

  • Hourly high-rate files (@ 1 sec); example:

ftp://ftp.gmv.es/incoming/gap1212m.12d.Z (only available for the last week or so)

Navigation messages have been discontinued, we recommend using daily “brdc” files from IGS:

GPS; example:

ftp://cddis.gsfc.nasa.gov/gps/data/daily/2012/212/12n/brdc2120.12n.Z

ftp://igs.bkg.bund.de/IGS/BRDC/2012/212/brdc2120.12n.Z

GLONASS; example:

ftp://cddis.gsfc.nasa.gov/gps/data/daily/2012/212/12g/brdc2120.12g.Z

ftp://igs.bkg.bund.de/IGS/BRDC/2012/212/brdc2120.12g.Z

New app for clock synchronization via GPS

September 29th, 2011 by Ricardo Píriz

Time transfer via satellite is nowadays the primary means to synchronize distant atomic clocks on ground. Clock synchronization is fundamental for example for maintaining UTC (Universal Time Coordinated), the official  scale by which the world regulates clocks and time. Computer servers, online services and other entities that rely on having a universally accepted time use UTC for that purpose.

Each national Timing Laboratory contributing to UTC keeps its own independent timescale, normally based on a very stable, temperature controlled, atomic clock or set of clocks. Then, all contributing timescales are inter-compared and combined in order to create an even more stable, international timescale (UTC).

But how to compare clocks located on different continents? One possibility is to use satellites that are in simultaneous view from the different laboratories. Enters GPS. By connecting each clock to a GPS receiver, in such a way that the measurements to the satellites are time-stamped by the external atomic clock instead of the internal receiver clock, and combining satellite measurements (RINEX files) from all these timing receivers in a sophisticated algorithm, it is possible to solve for all the system unknowns (satellite orbits, atmospheric delays, etc.) and compute the relative offsets of all ground clocks involved. This is precisely what the ODTS algorithm (Orbit Determination and Time Synchronization) within magicGNSS does. Read the rest of this entry »