rtklib between 2 GNSS permanent sites about rtklib HOT 8 OPEN

zuliani71:
Rule number one when doing this is to NEVER trust the coordinate you see
published or those sent over the wire until validated.

A painfully true fact is that some of /over the wire /value are
incorrect due to blunders, while other have used slightly different
epochs or datums for the value they send. This is often not an issue to
the plate movement sorts of folks because they are using coordinates
obtained by other means and may not be aware they are sending incorrect
data at all. Our firm has seen differences of over 10cm in this sort of
thing even within the same network of 'aligned' stations. To be fair,
the RTCM standard is rather imprecise on this point.

I would strongly suggest you gather 24 hours of data and submit it to
OPUS or whomever has a post precessing service service you trust for
EACH site and compare that with the RTCM message as a routine practice
for new sites. A quicker way to get perspective on this is simply to
select one site as your rover, then two of more nearby sites as the base
and compare the values you obtain fixed or not, one at a time. By this
mean you can produce a nice RTKLIB plot where you will see different
estimated positions for the same station depending on the reference you
have selected and than can determine which of these results is "truth"
for your own needs.

Regards,
David Kelley

On 7/11/2014 7:52 AM, zuliani71 wrote:

Dear group
currently I'm running an experiment with rtklib which involves 2 GNSS permanent sites.
Both sites are well monumented, they belong to a network devoted to cadastrial RTK services so their coordinates are well known (ad published inside official logsheets).
To summarize the experiment is set as Kinematic Positioning with L1+L2 (GPS+GLONASS), 15deg of el. mask, IONO=Estimate STEC, TROPO=Saastamoinen, Sat ephem=broadcast.
rtklib takes its input from NTRIP servers:
ROVER: RTCM2.3 (from a regional ntrip caster)
BASE:RTCM2.3 (froma a regional ntrip caster)
EPHEM/CLOCK:RTCM3.0 (from igs)
As both Rover and Base are permanent sites I except that when the FIX status is reached the Rover coordinates will fit the coordinates written inside the offcial logsheet.

Well,... having a fix with Min Ratio to Fix Ambiguity=3.0 (default) for me is impossible. I've changed that value to 1.8 and sometimes I get a FIX but usually the ratio is very close to 1 (between 1.1 and 1.2), the naseline is more ore less 25Km. Probably I can get a sable FIX because of the baseline (the saastamoinen tropo modue should be good up to 20Km), but I need some support to this idea. What do you think?

When the FIX is reached the solution is very close to the logsheets values (some cm of difference as expected). Anyway, in this kind of experiment, I can't understand what are the differences among the Positioning Modes: Kinematic, static and fixed. Furthermore I've a problem to chose the right Integer Ambiguity Res. What is the best among the various options (Fix and Hold, Continuous and Istantaneous). Probably for this kind of experiment Fix and Hold will be good but I need some support. Can you help me?

Finally using an Estimate STEC for the Iono correction lead me usually to a more stable FIX state than using Iono-Free LC (which should be the best with L1 and L2 receivers).
What do you think?

Thanks in advance

David

---

Reply to this email directly or view it on GitHub:
#35

from rtklib.

The below illustrates this using three local site in Los Angles and a 4th as the rover. Note the one marked as having a coordinate point error will not resolve (as would be expected as the position offset introduced an error bias into the nav filter) while the other resolve and are fairly well clumped. The longest base line used here was 35km. AR ratio of 2.7 used.

from rtklib.

Hi David, thanks for the answer.
Regarding the coordinates sent by the Ntrip Caster, I personally manage, with my staff, one of the casters and we've been very cerefull in that issue. We also manage the Italian GNNS permanent site nework which yelds the dataset (both for post-processing and RTK issues) in the northest italian area. We work with different post-processing softwares, one of them is GAMIT/GLOBK which is used for our crustal deformation studies too. For the pemanent site coordinates we used a 1 month combination (performed with GLOBK) of daily solutions (calculed with GAMIT). Each daily solution is yelded by combining different daily solutions (h-files) coming from bigger networks (such IGS, or EUREF). Finally we've stabilized over a European frame (ETRF2000(2008)) the results with 2 methods: one using the GLORG module included in the GAMT/GLOBK packet and the second using a memo written by BOUCHER and ALTAMIMI (Memo : Specifications for reference frame fixing in the analysis of a EUREF GPS campaign). The results given by the two methods are very close (1-2cm for the horiz. comp. and 2-3cm for the vert. comp.). To give more reliabilty to the solution obtained we compared our results with other coming from our national geodesy reference instutute (IGM) and from a indipendent Italian University (Padova). All results agree within few cm (anyway everytime less than 5cm among all solutions). I'm very confident the Master coordinates are good. Anyway, during the coordinates assesment phase, I've used the same service you've suggested to me (OPUS). With that I was able to stabilize the solution within one of the IGS0X frame. It was easy than to change from that to the equivalnet european frame, again using the ALTAMIMI memo. Again a good fit also with that solution. I've tried aslo the SCOUT service provided by SOPAC... same results.

Anyway I'll take you hint and I'll try again to check the coordinates yelded by our service. In the mean time I've made another test. I've used agian 2 streams provided by our service. One is prduced by a real GNNS peramnent site, the other one is a Virtual Ref. Site (VRS). The baseline now is calculated by rtklib very fast and I got a fix also with rates bigger than 3. The coordinates calculated for the rover are very good and fit well the ones written in the official logsheets.

Summarizing, I think the problem in fixing the solution, at least in our region, is caused by the baseline length. I'll do some more tests on that. Do ou ahanve any other suggestion on that issue?

Last, I can't understand what are the differences among the Positioning Modes: Kinematic, static and fixed. What does it change in the rtklib calculus if a change those values?

Bye and thnaks for the support.

David

from rtklib.

what are the differences among the Positioning Modes: Kinematic, static and fixed. What does it change in the rtklib calculus if a change those values?

I have problem with that was well. Words like "fixed" mode to my mine
also mean the same as "static" mode and frankly the terms which Tomoji
Takasu uses here still confuse me. As he is the author we need to defer
to him. [The America songwriter James Taylor was once asked in an
interview to comment regarding on what a fan thought some enigmatic song
lyric mean. In replying in to this he stated that, as the author, he
got to ultimately decide what it meant.]

I am a bit reluctant to try and answer that one further as the only good
answer involves walking over the source code and thinking our how you
yourself would have done it. But here goes... For the most part
RTKLIB seems be be a classical design so Kinematic means the platform
motion model is that it can move/accelerate at any time within the
dynamic limits you set on the other tabs while 'static' would imply it's
positional estimate can not (so filter evolution is essentially
constrained to time). As for 'static' vs 'fixed' here, I do not use
that one and a quick review of the manual does not give me further
insight this morning. The other modes seem self explanatory. I will
try and play with those two settings further here.

Perhaps others on this list can give a concise description of these, esp
'static' vs 'fixed' nav modes.

And it sounds like in the below you have a good solid means to cross
check the reference station positions.
Regards, David Kelley

On 7/14/2014 2:06 AM, zuliani71 wrote:

Hi David, thanks for the answer.
Regarding the coordinates sent by the Ntrip Caster, I personally manage, with my staff, one of the casters and we've been very cerefull in that issue. We also manage the Italian GNNS permanent site nework which yelds the dataset (both for post-processing and RTK issues) in the northest italian area. We work with different post-processing softwares, one of them is GAMIT/GLOBK which is used for our crustal deformation studies too. For the pemanent site coordinates we used a 1 month combination (performed with GLOBK) of daily solutions (calculed with GAMIT). Each daily solution is yelded by combining different daily solutions (h-files) coming from bigger networks (such IGS, or EUREF). Finally we've stabilized over a European frame (ETRF2000(2008)) the results with 2 methods: one using the GLORG module included in the GAMT/GLOBK packet and the second using a memo written by BOUCHER and ALTAMIMI (Memo : Specifications for reference frame fixing in the analysis of a EUREF GPS campaign). Th
e results given by the two methods are very close (1-2cm for the horiz. comp. and 2-3cm for the vert. comp.). To give more reliabilty to the solution obtained we compared our results with other coming from our national geodesy reference instutute (IGM) and from a indipendent Italian University (Padova). All results agree within few cm (anyway everytime less than 5cm among all solutions). I'm very confident the Master coordinates are good. Anyway, during the coordinates assesment phase, I've used the same service you've suggested to me (OPUS). With that I was able to stabilize the solution within one of the IGS0X frame. It was easy than to change from that to the equivalnet european frame, again using the ALTAMIMI memo. Again a good fit also with that solution. I've tried aslo the SCOUT service provided by SOPAC... same results.

Anyway I'll take you hint and I'll try again to check the coordinates yelded by our service. In the mean time I've made another test. I've used agian 2 streams provided by our service. One is prduced by a real GNNS peramnent site, the other one is a Virtual Ref. Site (VRS). The baseline now is calculated by rtklib very fast and I got a fix also with rates bigger than 3. The coordinates calculated for the rover are very good and fit well the ones written in the official logsheets.

Summarizing, I think the problem in fixing the solution, at least in our region, is caused by the baseline length. I'll do some more tests on that. Do ou ahanve any other suggestion on that issue?

Last, I can't understand what are the differences among the Positioning Modes: Kinematic, static and fixed. What does it change in the rtklib calculus if a change those values?

Bye and thnaks for the support.

David

---

Reply to this email directly or view it on GitHub:
#35 (comment)

Regards,
David Kelley
ITS Programs Manager
SubCarrier Systems Corp. (SCSC)
1833 East Foothill Blvd. Glendora, CA USA 91741
626-485-7528 (Cell) 888-950-8747 (Main)
626-513-7715 (Office) 888-613-0757 (Fax)
[email protected]

from rtklib.

Hi David, thanks for all the explanations. I hope someone else, may be Tomoji Takasu, could help us for the unsolved issues. What I felt using rtklib was kinematic=static=fixed, but it's just a feeling caused by the manual operations you've to make to setup every experiment. Anyway thanks again and bye.

from rtklib.

Hi all,

not sure if this thread is still open and read.

Let me know opinion about the following approach.

I would like to study GPS (nmea) fix generated by permanent GNSSS against exact geolocation of the GNSSS and usse the same offset
on generic GPS Rover (mobile generic GPS unit) for fix correction.

Pls let me know your opinion.

from rtklib.

From one year ago
zuliani71 : I think I finally learned what 'fixed' means (vs static) in the documentation. This is the term which Tomoji Takasu used when the XYZ position is constrained and only time can evolve (no base needed). In this mode you will clearly see the rover residuals, and the position in question is the rover (not the base). Now I see what the footnote comment "For residuals analysis" means in the documents (bottom of page 34).

manta103g : I am not sure what you are saying here. If you want to subtract the position offset seen by the base from its nominal point and use that to offset the rover, you just reinvented RTCM/DGPS "rev 1" that only worked (and poorly) when all parties tracked the same set of SVs. Useful in early development days when there were but a few SVs (early 1980's) but unused ever since. The problems with this were that in practice any two devices rarely saw the same thing over a reasonable period of movement, or processed it the same, or responded the same when the SV collection changed. This method tried to model a "system" of errors sources that needed to be separated in the "position space" solution. This lead to RTCM Rev2 *DGPS) where code offsets for each individual SV were created and exchanged. After that carrier tracking methods dominated, with their 100x increase is precision. And with the advent of common formats for RTK by early 1990's RTK as we know it became common. Both of these use the "observation space" of each SV to relate the common mode errors. More current RTCM work uses a "state space" where various systems errors are isolated and modeled. But all this is off topic.
If you goal was to subtract one from the other in the position space, then go to it but be aware of the above issues. You certainly would be better off finding a local RTCM Rev2 type one message source and sending that to whatever device you will be using.

from rtklib.

Thank you my dear friend for your kind reply.

I have studied L1 frequency ionospheric error in Australia.
Since access to local RTCM is limited, per request, time limited, by paid
contract, I have to give up RTCM Rev2 high-accuracy solution.

I have build and learnt how to build car navigation GPS based system while
with Nokia Maemo Project.

Early car navigation GPS systems came with GPS fix chart feature
(application).
All I need is to get GPS fix data from a number of GPS units in one place
(multi-chart overlay) to study ionospheric error for the given region.

From time to time I study RTK GPS units live connected to the Internet,
charting RTK corrected GPS fix from a number of RTK GPS units, in seperate
windows.

I am fully aware of the limitations, as mentioned by you above, but modern
smartphones come with standard GPS unit, RTK GPS is to be installed at a
later date, since RTCM Rev2 support is not open and public yet.

In theory, public, open, free RTCM Rev2 service can started as one another
Internet challenge and service at pocket money, to provide RTK corrections
for anyone.

But at this date, only GPS enabled smartphones can share GPS fix for the
given region and if GPS base is not moving, I am interested to get GPS fix
remotely charted from a n7umber of GPS enabled smartphones to study
ionospheric F1 error in my spare time.

Thank you once again for your excellent review on state-of-the-art in RTK
GNSS

Darius

2016-07-31 23:45 GMT+02:00 DC Kelley [email protected]:

From one year ago
zuliani71 : I think I finally learned what 'fixed' means (vs static) in
the documentation. This is the term which Tomoji Takasu used when the XYZ
position is constrained and only time can evolve (no base needed). In this
mode you will clearly see the rover residuals, and the position in question
is the rover (not the base). Now I see what the footnote comment "For
residuals analysis" means in the documents (bottom of page 34).

manta103g : I am not sure what you are saying here. If you want to
subtract the position offset seen by the base from its nominal point and
use that to offset the rover, you just reinvented RTCM/DGPS "rev 1" that
only worked (and poorly) when all parties tracked the same set of SVs.
Useful in early development days when there were but a few SVs (early
1980's) but unused ever since. The problems with this were that in practice
any two devices rarely saw the same thing over a reasonable period of
movement, or processed it the same, or responded the same when the SV
collection changed. This method tried to model a "system" of errors sources
that needed to be separated in the "position space" solution. This lead to
RTCM Rev2 *DGPS) where code offsets for each individual SV were created and
exchanged. After that carrier tracking methods dominated, with their 100x
increase is precision. And with the advent of common formats for RTK by
early 1990's RTK as we know it became common. Both of these use the
"observation space" of each SV to relate the common mode errors. More
current RTCM work uses a "state space" where various systems errors are
isolated and modeled. But all this is off topic.

If you goal was to subtract one from the other in the position space, then
go to it but be aware of the above issues. You certainly would be better
off finding a local RTCM Rev2 type one message source and sending that to
whatever device you will be using.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#35 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ALFU0z-p3F7YuQelHFZZLHEyya1fA7Gjks5qbRdpgaJpZM4CMZ4I
.

from rtklib.