If that doesn't resolve the discrepancy, try discarding L2 observations as well. There might be differences in the way each implementation treats iono delay.
On Sun, Dec 22, 2013 at 9:52 PM, Felipe G. Nievinski <[email protected]>wrote: > You have a mixed-type RINEX. > I'm not sure how each PPP implementation > treats SBAS, Glonass, etc. > So I'd discard non-GPS observations, > using RINEX. > > > > On Sun, Dec 22, 2013 at 6:54 PM, Anders Wallin < > [email protected]> wrote: > >> >> I posted the PPP solutions I got so far on my blog: >> http://www.anderswallin.net/2013/12/comparing-gps-ppp-solutions/ >> >> 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. >> 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. >> 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 :( >> >> I could not get the other online PPP services to work: >> AUSPOS works but I do not get a time-series of position/clock-offset as >> output >> OPUS works but I do not get a time-series of position/clock-offset as >> output >> GAPS and magicGNSS rejected my RINEX file and gave an error message. >> >> >> Anders >> >> >> >> >> On Sat, Dec 21, 2013 at 11:47 PM, Felipe G. Nievinski < >> [email protected]> wrote: >> >>> Might want to try http://gaps.gge.unb.ca/ >>> And the multi-solution comparison centre: >>> http://gge.unb.ca/Resources/PPP/Purpose.html >>> >>> Another comparison: >>> >>> http://gpsworld.com/a-comparison-of-free-gps-online-post-processing-services/ >>> >>> >>> >>> >>> On Sat, Dec 21, 2013 at 1:51 PM, Anders Wallin < >>> [email protected]> wrote: >>> >>>> >>>> Thanks for the tip! >>>> By extracting the receiver clock bias from the status-file, and playing >>>> around with the RTKPOST settings I now get better results: >>>> http://imagebin.org/283266 >>>> >>>> There's still a 4 ns offset between the CSRS and RTKLib solutions - I >>>> don't know where it comes from?? >>>> >>>> ESA gLAB arrives at the same result as CSRS, so maybe I will look >>>> closely at the gLAB settings next. >>>> >>>> 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) >>>> >>>> Anders >>>> >>>> >>>> >>>> On Sat, Dec 21, 2013 at 12:07 AM, Felipe G. Nievinski < >>>> [email protected]> wrote: >>>> >>>>> I don't think you should use the time tag in the .pos file. >>>>> I'd use instead the CLK records in the .stat file. >>>>> See Appendix B.3 in the docs, "Solution Status File": >>>>> >>>>> *Receiver Clockâbias States* >>>>> *Estimated receiver clock bias parameters. The format of a record is >>>>> as follows.* >>>>> *$CLK,week,tow,stat,rcv,clk1,clk2,clk3,clk4* >>>>> *week/tow : gps week no/time of week (s)* >>>>> *stat : solution status* >>>>> *rcv : receiver (1:rover,2:base station)* >>>>> *clk1 : receiver clock bias GPS (ns)* >>>>> *clk2 : receiver clock bias GLONASS (ns)* >>>>> *clk3 : reserved* >>>>> *clk4 : reserved* >>>>> >>>>> >>>> >>> >> >
_______________________________________________ This message is sent to you from [email protected] mailing list. Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
