Ublox M8P-2 PPP Results Interpretation

I sent a static 12 hr obs file with 4s interval to the Canadian Geodetic Survey of Natural Resources CSRS-PPP site. The summary page is shown in the figure below. The 95% sigma for Latitude is 0.75 m. When I look at the .pos file (also shown below) the 95% sigma after the first couple of hours is .00125 seconds, a couple of inches.

The CSRS sigma plot at the end of 12 hr is also down to less than 0.1 m when expanded. Can someone explain why the CSRS summary error is so much larger than it appears to me from the 12 hr processed data? How does CSRS determine the summary page sigma or maybe the better question is what exactly does it mean?

dLat vs Intervals.jpg

Interesting outcome. I know that the CSRS-PPP has a help email address that is very responsive, I recommend reaching out to them directly; they’ll know more about how that summary sigma is calculated than anyone else.

A really good resource for interpreting CSRS-PPP results:

https://webapp.csrs-scrs.nrcan-rncan.gc … Static.pdf

Some things I noticed from the summary:

You are using NRCAN rapid product type, which is going to have less accurate results than Final. Waiting a few days should give you access to their more refined product type, Final.

Frequency is Single. Which receiver/antenna are you using? I generally use dual band for PPP data (or tri band if available), so I’m not sure how much this would effect your results.

Your a priori location is off by a meter in lat lon, and 7 meters in altitude. Again, not sure how much this plays into the final result. The a priori location is taken from the RINEX header. Which version of RINEX did you use?

Thanks for the help… I thought I should try this forum first as I thought it may be associated with the (single frequency) M8P-2. I am using the Ublox ANN-00 L1/L2 antenna. I looked again at the link you gave… I had not picked up on the comment “incorporates both PPP and epoch transformation uncertainties.” Maybe it is the epoch transformation uncertainties???

I did not intentionally use ultra-rapid so thank you for pointing that out.

No doubt the single frequency and no Galileo sats make a difference but not likely the reason for the error number being much larger than the processed data. THANKS!