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

[Felipe G. Nievinski]

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/6c913951/attachment-0001.html>