We have recently introduced our new algorithm for Precise Point Positioning (PPP). One of the things you can do with PPP is to monitor the displacement of your station(s) over long periods of time. Even if your station is installed on a very stable location, it will unavoidably move a little bit over the years due to the slow but steady displacement of the tectonic plate the station is placed on. The plate motion velocity changes a lot from plate to plate, the following map (from UNAVCO) shows a general view of the Earth:

Read the rest of this entry »

When you upload station data in magicGNSS (see How to upload station data), the station coordinates are read from the RINEX file header and stored in the magicGNSS database. The first time you upload data from a station you will see ‘Coords from: RINEX’  when you click on the station name or icon on My Stations. Coordinates from the database are used as a priori (initial) values by the ODTS and PPP algorithms.

If you want to refine your station coordinates in the database, just upload enough data from that station (one day is recommended), process it in PPP and click on ‘Update My Station Coordinates’ on the PPP Settings: Read the rest of this entry »

We are releasing today a new magicGNSS that features a first version of the long-awaited Precise Point Positioning algorithm (PPP). This new module allows solving for user station coordinates, tropospheric delay and clock by fixing the GPS satellite orbits and clocks to IGS products (ultra-rapid, rapid, or final products). The PPP module and the station data upload mechanism are now available to all magicGNSS users, not only to *pro* users.

Currently the PPP module works in static mode only (we are working hard on the dynamic or kinematic mode) and with dual-frequency code+phase measurements. You can process one or several stations (maximum 10) in the same PPP session. At the moment the maximum data span that can be processed in a single PPP session is limited to one day. More information about the PPP algorithm can be found here. You can also download an example of PPP Report.

We have explained how to upload and process your own station data in magicGNSS (in a previous entry). If you need to download many daily RINEX files from the IGS server and upload them in your magicGNSS account by ftp (for *pro* users only), here are a couple of very simple UNIX scripts that might help you. They are based on the ncftpget and ncftpput tools. The download script is called in this way:

./download yy ddd stations.txt (example: ./download 09 040 mystations.txt)

where stations.txt is a simple file whose rows contain the station names (here is an example of stations.txt file). The daily RINEX files are downloaded onto the current local directory.

The upload script is called like this:

./upload yy ddd stations.txt magicuser.cfg (example: ./upload 09 040 mystations.txt johnsmith.cfg)

where magicuser.cfg is a file that contains your magicGNSS account information (here is an example of magicuser.cfg file). The daily RINEX files are uploaded and then deleted from the current local directory.

Last December we introduced the new module COMP to compare satellite orbits. As from today you can also compare satellite clocks and station coordinates using COMP.

As in the case of orbits, clocks from ODTS (estimated and predicted) can be compared to IGS products (only rapid and final clocks, but not ultra-rapid ones yet, sorry). IGS rapid and final clocks are automatically downloaded and stored on the magicGNSS server. Rapid IGS clocks have a latency of around 2 days and final clocks have a latency of nearly two weeks. When comparing with IGS clocks, COMP tries always to choose the final IGS clock, and if it is not available it chooses the rapid one instead. Read the rest of this entry »