GLONASS correction fails with new igv* product of CDDIS

[georgmichel]

The experimental igv* product delivers precise ephemerides for GPS and GLONASS simultaneously. When I use this product for GPS it gives the same corrrection as the igu product as it should.

When I use igv for GLONASS correction, then the correction gives a 100km (=10e5m) offset.

I will check with precise igl data in two weeks.

[tomojitakasu]

Current IGL or IGV does not provide GLO satellite clocks. So you cannot use IGL or IGV for GLO-PPP. Use ESA instead.

[georgmichel]

Now where the precise ephemeris is available I made some more calculations. The point is that GLONASS PPP behaves very different when used with precise ephemeris compared to broadcast ephemeris. GPS PPP works as expected (20cm deviation after 1 hour with precise ephemeris and IONEX data). In the following I refer exclusively to GLONASS-only calculations with esa ephemeris.

The point cloud of the single solution with precise ephemeris is closer to the true position than the point cloud of the single solution with broadcast ephemeris. So the precise ephemeris is likely to be correct.

The picture below shows the PPP forward solution with broadcast ephemeris and without ionosphere or troposphere corrections. The origin is the true position (an officially surveyed reference point with clear sky view). The solution is plausible as it moves towards the true position. With IONEX corrections it is better.

In the next picture the only change I made was to switch from broadcast to precise ephemeris (again no iono/tropo corrections). The few single solutions (4%) are more or less at the true position.

When I use IONEX corrections the curve looks much different but still very wrong.

I also tried with precise ephemeris from gfz (Germany) and iac (Russia). The error of these results is in the same range. However, the curves look different from esa. But they look almost identical to one another.

GLONASS only RTK works as expected. So the GLONASS phase processing itself seems to be OK.

Concurrent GPS/GLONASS PPP is also OK but worse than GPS only PPP.

The whole thing is for 2.4.2p11 with uBlox M8T.

[johanez]

Dear georgemichel, that is indeed disappointing. I work in Africa with no CORS operating, so I I would like to also test L1 ppp with GLONASS and GPS. I did get quite reasonable results using real time PPP (IGS03, GPS+GLONASS), within 50cm after 20 minutes. I'm quite a newbie to PPP, maybe you could share the exact IGS and ESA products you use, and the settings in RTKPOST? Thata would be greatly appreciated? (Sorry for asking this here, no other way to contact you here...)

[georgmichel]

Hi johanez,

as mentioned in the original post, the problem occurs only with precise ephemeris data, not with broadcast data (I guess this is what you mean with real time PPP). I got the corrections from IAC and NASA. Just follow the links on these pages. In the NASA products area you can also find the IONEX correction data.

For the settings you can choose the default settings by just replacing broadcast with precise ephemeris.

Unfortunately my understanding of RTKLIB is too little in order to figure out the point where the difference between broadcast and precise ephemeris is made and what causes this difference to be that large for GLONASS. For GPS everything is OK. Maybe you can do such an experiment with another module (anything GLONASS capable except u-blox). This could help Tomoji to pinpoint the problem.

[johanez]

Thanks for the reply! I used the Real time service of IGS, which uses their ultra rapid orbit and clock solutions. http://igs.org/rts/products This I used in realtime in RTKNAVI, you need a user account which is free e.g. through www.euref-ip.net

For the post procerssing of only GPS in RTKPOST, do I need all of those? Or can I leave out the clocks? orbits .sp3 clocks .ckl ephermis .erp ionospheric map *.16i

Using all this in pst gave me far worse (>1m error) results than the real time stream, but that might also be related to observation conditions, whcih were not the same.

[coandrei]

There are two ways to do PPP:

1. post-processing using precise orbits (.sp3) and clocks (.clk) together with other error corrections (see the links)
2. real-time using real-time correction streams from various providers. Please notice that in general these streams include satellite orbit and clock corrections to the broadcast ephemeris. In addition, difference between satellite centre of mass (CoM) and satellite antenna phase centre (APC) should be considered as different force models are used for orbit modelling. Usually, the former is associated with precise orbits, whereas the later is associated with broadcast orbits.

Strictly speaking, it is not a PPP solution if only broadcast information (without corrections to broadcast) is used.

You may read more about PPP here or here. Good luck!

[georgmichel]

Hi johanez,

the second half of the ultra rapid solution is actually a prediction and can be used for PPP, if downloaded beforehand. In addition, there are no GLONASS correction in this ultra fast solution. So it works only for GPS. However, the error due to the ionospheric delay is much bigger compared to the error in teh ephemeris. Tha means you will nee a dual frequency receiver to correct for the ionosphere in real time.

To my knowledge, there is no real time source for ionospheric delay except from RTK signals (the streams from euref-ip). But RTK is another story. With a single frequency receiver which you own (I I guess) you will have to wait with the post processing at least until the IONEX data becomes available. The precise GLONASS ephemeris are available every Thursday for the week before, as far as I remember.

[johanez]

Thank you both! I guess my good solutionwith real live stream from IGS was than only good luck. I will read a bit more into it and see howfar I get with post processing.

[georgmichel]

One more hint: Please consider the correct datum and epoch transformation in conjunction with officially surveyed points. Usually their coordinates are given in reference frames which are fixed to a continent (e.g. ETRS89 for Europe). Due to the continental drift they will drift as well over the years.

[johanez]

Yes, I think I covered this, using the BETA2007 NTV2 transformation grid provided by the German authorities to convert between the local GK3 and WGS84, they claim this gives cm level accuracy.

To summarise the above on PPP, in order to achieve sub meter precision with a L1 reciever, i should - - collect data for some hours,

• wait untill ionex data is avilable, put this in the file section, check IONEX TEC in the options
• use the sp3 and clk files from NASA, select "precise ephermis/clock"
• don't use GLONASS, since there seem to be trouble with this

btw, I'm using a U-blox NEO-M8T reciever with a Tallisman antenna on a metal groundplane

[coandrei]

CODE offers final, rapid and predicted GIM products. See here Look for COPG* files for the predicted GIMs. As mentioned before, L1 PPP has limitations and cannot offer you high precision due to large iono residuals. From my experience, if one gets local/regional/wide-area iono corrections than sub-decimeter precision may be obtained. Otherwise, I would suggest you to get another M8T and do L1 RTK with your own base if the precision is important to you. Alles Gute!