Archive for 2012

IGS Workshop 2012

Friday, December 21st, 2012

This past July we held the IGS workshop in Poland at a beautiful location about 3 hours from Warsaw at the university were Copernicus taught, amazing.

The location was beautiful, the organization very efficient and the attendance was very good.

As seen in the image I gave a nice presentation on the state of the IGS network of GNSS stations I highlighted the efforts to maintain station consistency, to recover stations after long outages, to recovering the 20+ stations from the NGA just ahead of the IGS 2nd reprocessing of 2013, the uncalibrated radome experiment, etc.

You can see the full presentation at this link; Network presentation pdf

You can follow the presentation video at the following link;Network presentation video buy kamagra online

IGS MGEX Project

Monday, July 9th, 2012

The IGS has created a new project called MGEX to gather and process multi-GNSS data. IGS MGEX stands for Multi GNSS Experiment and it was proposed and is managed by the IGS GNSS Working Group. The main aim is to collect GNSS data containing more than GPS+GLONASS data. Currently there are a multitude of modern receivers that provide data for GPS, Glonass, Galileo, QZSS, SBAS and even possibly Compass.

The number of participating stations has been increasing over time. Below a plot of a recent day of data files available . These are stations mainly contributing data in Rinex 3 format and some in Rinex 2. Some of these stations are already existing IGS stations.

At ESA/ESOC we are staying well informed of the developments in this IGS project through the participation in the IGS GNSS Working Group. ESA/ESOC hopes to be able to contribute to MGEX with data and analysis results. ESA/ESOC is upgrading its station network (see figure below) during 2012/2013 to full GNSS capabilities with new Septentrio PolarRx4 receivers and Septentrio Choke Ring MC Antennas.

IGS Co-located Station Antenna Tests

Friday, January 13th, 2012

GNSS stations of the IGS are very important, especially when they are located at locations with other space techniques such a Satellite Laser Ranging (SLR) and Very Long Based Interferometry (VLBI), which all provide inputs to the establishment of the Earth’s International Reference Frames. The ‘ties’ between all the different antenna’s reference points is essential to be able to merge all the station position data into a consistent and coherent system.

The problem is when GNSS antennas are covered by uncalibrated Radomes, these are enclosures that cover the top part of the antenna to protect them from rain, snow, animal damage, etc. Below you can see some of the Radomes in use around the IGS network

Most of the Radomes used by station operators around the world are calibrated (more on that in a later post!) like the one pictured on the left. But older stations are still using Radomes that are not calibrated (such a pictured on the right) so we cannot know what effect exists in the signal transmission and the effect on the long term position estimations at these sites.

Covering a GNSS antenna with a radome whose phase center variations (PCVs) have not been calibrated will usually cause an unknown bias in the estimated position for that station. This bias is equivalent to a local tie error for those IGS stations colocated with other techniques and is thus a serious concern for ITRF (International Terrestrial Rotation Frame), which aims for tie accuracies at the 1 to 2 mm level. Radome effects can often be much larger, up to several cm.

At the IGS Infrastructure Committee, which I chair, we have been coordinating with the IGS reference Frame Working group, the IGS Antenna Working group and the IGS Network Coordinator since we think that the net position bias can be measured empirically by comparing solutions with and without the radome present. This requires that the radome can be safely removed temporarily without disturbing the antenna construction and then later be reinstalled. The empirical position offset provides a correction for the local tie vector to other techniques.

Essentially we will organize with each station operator an 8 week period of “radome off” operations over the next 18 months. During this period the station position will continue to be included in the IGS processing and it is hoped that the combined station position before , during and after the radome-off campaign will produce empirical tie corrections to be applied to the ITRF tie vectors.

P1C1 biases from different sources

Thursday, January 12th, 2012

Coming back to this issue we have encountered a significant problem.

As remarked before in this blog P1C1 biases we have to be able to correct the C1 measurements from GPS to mix them correctly with the P1 measurements. This comes from the fact that when the signal is encoded in the satellite there is a delay between the ‘C/A’ and the ‘P’ code encoding.

Of course we detect this offset between signals (differential code bias: DCB) in the RINEX data which is recorded by a receiver after traveling from the satellite to the antenna through the atmosphere, and from the antenna to the receiver through the cable , amplifiers, etc. Internally in the receiver the electronics can also play a role of course. In any case what we see in the IGS is the RINEX data and this is what we have to work with.

As mentioned in the previous blog entry P1C1 biases the Analysis Center CODE (Center for Orbit Determination Europe) at Univ Berne publishes the P1C1 biases as an average over many brands of receivers available in the IGS network, and generally it is accepted that these averages are to be used when doing IGS-type processing or using the IGS products.

We have found that when an IGS-type solution uses a network of receivers with only Trimble receivers (which need the P1C1 bias) the CODE values may not be the best suited since the Trimble receivers do not show the same DCBs as other receiver brands. We have reached this conclusion after MANY internal investigations and testing. It is clear that depending on what receiver types we test the DCBs are slightly different from the accepted CODE averages, but when the receivers are only Trimble then the differences for certain satellites can be very significant:

in the table above you can see the differences of the P1C1 bias from CODE, as calculated using only Ashtech receivers and as calculated using only Trimble receivers, note the differences for satellites such as G07, G12, G29, etc. in plot form this shows the differences more clearly:

This generally means that the clock solutions from using the incorrect P1C1 bias will be biased versus the satellite clock solutions from a mixed network or as published in the IGS clock combination.

Therefore to conclude, be careful when calculating satellite clock solutions when all the receivers are of a certain brands and the data has to be corrected with the P1C1 bias! This is if you are interested in the satellite clock solutions or on resolving the maximum number of ambiguities with fixed satellite clocks!

IGS positioning on phase aligment for GPS L2 data

Monday, January 9th, 2012

The members of the Infrastructure Committee have prepared the following statement which was distributed to the receiver manufacturers late in 2010 by the IGS Governing Board:

We have come to this consensus at the IGS to speak with one voice and to send a clear message that the manufacturers need to provide phase measurements on all frequencies that are aligned so that users of the measurements do not have to second guess what they are using.

It is hoped that this statement and that the IGS relationship within the RTCM sc104 will help to resolve this issue for the benefit of all dual frequency GNSS users. In the end we anticipate that either an agreement will be reached for all manufacturers to provide aligned phases on L2 as they already do for L1 and to provide the amount they align them by so that the original measurement can be reconstructed should anyone need to.

To provide the alignment information the RINEX format has had a compulsory line added to the header as follows:

This has been added to the latest RINEX format versions:

PRN22 Signal Anomaly

Thursday, January 5th, 2012

It has been reported over the last few days of 2010 that satellite PRN22 (G22, SVN 47) has had issues.

Essentially the satellite had an issue with its navigation signal in that the Differential Code bias had changed a whole lot! this meant that the P1C1 biases we were all applying to be able to mix the ‘C1′ and ‘P1′ measurements from the satellites Read more about the differential code bias issue.

After some investigation we finally found that indeed the P1C1 bias for SVN47 has changed from 0.05 ns to -2.6 ns, so from ~1.5 cm to about -80 cm. This huge change made all the G22 clock comparisons and combinations across the IGS contributing solutions very inconsistent for a few weeks until the situation was finally properly analyzed, studied and corrected.

In the end there had been an unreported issue in the satellite on 30 Oct 2010, the satellite was set unhealthy via the navigation message, and later unsuable via NANU 2010133 for a 37 hour period and after reactivation the P1C1 bias was ~2.7 ns off!! This appears to have been caused by the switch on-board the spacecraft to a backup signal generator unit since at the anomaly start a significant signal power reduction was observed of more than 10 dB-Hz , which after the outage was fine.

Our wonderful colleague in the IGS A. Hauschild (DLR) produced the following technical note with all the details of this event. Happy reading!

Rinex Observables

Wednesday, January 4th, 2012

What an issue!!

We are facing a very significant problem in the current Rinex data files , and I need to tell you about it!

The Rinex 2.11 format is defined without regard to where the phase is actually coming from (the C/A or the P code tracking). This has for the longest time not been an issue because it could only be a problem in L1 since it was the only signal with both C/A and P code. But it wasn’t a problem because the receiver manufacturers would align the L1 phase so that a user did not need to know whether the L1 phase came form one tracking or the other.

As the L2C signal spreads through the GPS constellation with the newer satellites we have encountered this pesky problem more and more. Now there are two signals on L2 as well, as we have always had in L1, the ‘P’ code and the ‘L2C’ code … so potentially the L2 phase could come from either signal tracking. In the IGS community we expected that the receiver manufacturers would again align the phase measurement transparently … but they did NOT!

Therefore we are now left with L2 measurements in Rinex 2.11 files that have a 1/4 cycle shift for certain satellites (the IIR-M and IIF ones!) from certain receivers. A clue comes from receivers that do not give you the P2 measurement, only the C2! these data are not useful for the IGS processing and I am pretty sure that the L2 phase reported therein is an L2C phase with a 1/4 cycle offset from the L2P phase. For example:

You can see that for satellites G05, G25, G29 and G15 (all Block IIR-M satellites) there is a C2 measurement but no P2 measurement! Therefore almost half of the data from this sample station cannot be used in IGS processing. We would need to apply a P2C2 bias as we do to C1, but no such agreement exists yet in the IGS to do so.

In the IGS we are working to solve this issue but it will not be easy, at least we have defined a format (not actually used by anyone!! :( ) which includes a compulsory line in the header to report the offset between phases on the same frequency, Rinex 2.12 format.

Solving this problem will involve the Infrastructure Committee and the Real-Time Pilot Project in direct connection with the receiver manufacturers. more to come in a future post!!