We have just made available online the first version of the COMP module. COMP is envisaged to be a flexible tool to compare many types of GNSS data products such as orbits, clocks, and coordinates.
With the current version of COMP you can inter-compare estimated and predicted satellite orbits (in SP3 format) generated by the ODTS algorithm, and also compare them with IGS products.
You can now upload and process your own station data (RINEX files). There are two ways to upload RINEX files: on the web (for all users) or by ftp (for *pro* users only).
On the web, just go to “My Stations” on the upper right corner of your account and then click on “Upload RINEX files” at the bottom of the page. Note that a single compressed file containing multiple RINEX files is supported.
By ftp, just connect to the magicgnss.gmv.com server using your magicGNSS account’s username and password. You can of course do bulk file upload and automate it using ftp. On UNIX, a convenient scheme is to combine NcFTP (ncftpget and ncftpput commands) with cron. Ftp upload is available for *pro* users only. Please note that in case of uploading your RINEX files via ftp on Windows, after logging with your user, command “bin” shall be executed prior to uploading the RINEX files by means of “put” or “mput” commands. (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:
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!
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 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.
