<div dir="ltr">You have a mixed-type RINEX.<div>I'm not sure how each PPP implementation </div><div>treats SBAS, Glonass, etc.</div><div>So I'd discard non-GPS observations, </div><div>using RINEX.</div><div><br></div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Dec 22, 2013 at 6:54 PM, Anders Wallin <span dir="ltr"><<a href="mailto:anders.e.e.wallin@gmail.com" target="_blank">anders.e.e.wallin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><br></div>I posted the PPP solutions I got so far on my blog:<br><a href="http://www.anderswallin.net/2013/12/comparing-gps-ppp-solutions/" target="_blank">http://www.anderswallin.net/2013/12/comparing-gps-ppp-solutions/</a><br>
<br></div>If anyone knows how to reproduce the CSRS-PPP results with either gLAB or RTKLib, let me know. I also posted my RINEX data-file if anyone wants to try it.<br></div>The gLAB solution is already very close to the CSRS-PPP solution, but by default gLAB produces data at 300s intervals (not 30s as CSRS-PPP) so I haven't directly compared the time-series yet.<br>
</div><div>The RTKLib solution is off by ~4ns which is alarmingly much - although I tried to feed RTKLib with the same input as gLAB, and tweak a number of settings - but the 4 ns offset was always there :(<br></div><div>
<br></div><div>I could not get the other online PPP services to work:<br></div><div>AUSPOS works but I do not get a time-series of position/clock-offset as output<br></div><div>OPUS works but I do not get a time-series of position/clock-offset as output<br>
</div><div>GAPS and magicGNSS rejected my RINEX file and gave an error message.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div>Anders<br><div>
<div><br><br></div></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 21, 2013 at 11:47 PM, Felipe G. Nievinski <span dir="ltr"><<a href="mailto:fgnievinski@gmail.com" target="_blank">fgnievinski@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Might want to try <a href="http://gaps.gge.unb.ca/" target="_blank">http://gaps.gge.unb.ca/</a><div>And the multi-solution comparison centre: <a href="http://gge.unb.ca/Resources/PPP/Purpose.html" target="_blank">http://gge.unb.ca/Resources/PPP/Purpose.html</a></div>
<div><br></div><div>Another comparison:</div><div><a href="http://gpsworld.com/a-comparison-of-free-gps-online-post-processing-services/" target="_blank">http://gpsworld.com/a-comparison-of-free-gps-online-post-processing-services/</a><br>
<div><br><div><br></div></div></div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Dec 21, 2013 at 1:51 PM, Anders Wallin <span dir="ltr"><<a href="mailto:anders.e.e.wallin@gmail.com" target="_blank">anders.e.e.wallin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br></div>Thanks for the tip!<br></div>By extracting the receiver clock bias from the status-file, and playing around with the RTKPOST settings I now get better results:<br>
<a href="http://imagebin.org/283266" target="_blank">http://imagebin.org/283266</a><br>
<br></div>There's still a 4 ns offset between the CSRS and RTKLib solutions - I don't know where it comes from??<br><div><br></div><div>ESA gLAB arrives at the same result as CSRS, so maybe I will look closely at the gLAB settings next.<br>
<br>Thanks for your help - I will try to write a blog post about my findings if/when I get at least three methods to agree on the results (CSRS, gLAB, and RTKLIB)<span><font color="#888888"><br><br></font></span></div>
<span><font color="#888888"><div>Anders<br></div><div><br></div></font></span></div><div><div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Sat, Dec 21, 2013 at 12:07 AM, Felipe G. Nievinski <span dir="ltr"><<a href="mailto:fgnievinski@gmail.com" target="_blank">fgnievinski@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">I don't think you should use the time tag in the .pos file.<div>I'd use instead the CLK records in the .stat file.</div><div>See Appendix B.3 in the docs, "Solution Status File":</div><div>
<div><br></div><div><i>Receiver Clock‐bias States</i></div><div><i>Estimated receiver clock bias parameters. The format of a record is as follows.</i></div><div><i>$CLK,week,tow,stat,rcv,clk1,clk2,clk3,clk4</i></div><div>
<i>week/tow : gps week no/time of week (s)</i></div><div><i>stat : solution status</i></div><div><i>rcv : receiver (1:rover,2:base station)</i></div><div><i>clk1 : receiver clock bias GPS (ns)</i></div><div><i>clk2 : receiver clock bias GLONASS (ns)</i></div>
<div><i>clk3 : reserved</i></div><div><i>clk4 : reserved</i></div></div><div><br></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>