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)
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!
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.
July 30th, 2012 by Ricardo Píriz
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 »