[FOSS-GPS] PPP with RTKLib: RINEX O- and N- files?

Felipe G. Nievinski fgnievinski at gmail.com
Sun Dec 22 15:54:49 PST 2013


I meant to say, use teqc to discard.


On Sun, Dec 22, 2013 at 9:53 PM, Felipe G. Nievinski
<fgnievinski at gmail.com>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 <
> fgnievinski at gmail.com> 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 <
>> anders.e.e.wallin at gmail.com> 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 <
>>> fgnievinski at gmail.com> 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 <
>>>> anders.e.e.wallin at gmail.com> 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 <
>>>>> fgnievinski at gmail.com> 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*
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/foss-gps/attachments/20131222/bb7186bb/attachment.html>


More information about the FOSS-GPS mailing list