I meant to say, use teqc to discard.
On Sun, Dec 22, 2013 at 9:53 PM, Felipe G. Nievinski <[email protected]>wrote: > 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
