Greetings all,
I’m using two reach modules and wanted to test if NTRIP and PPK gives similar results when base and rover were placed at the same points in both processes.
Using NTRIP :
I launched the base using 20 mins reading in single mode.
After that, i used the open source NTRIP caster (rtk2go.com) and a connection between base and rover was achieved and i got a fix status soon.
Then i stared raw (RINEX3.03) logging in both modules and post processed them in rtkpost.
Results:
PPK:
After NTRIP i placed the base and rover at the same place and logged another raw file in RINEX3.30 as well in single mode and post processed these in rtkpost.
Now on comparing results the coordinates of rover came out to be different(you can see at the right bottom in 1st images in both trials)
The baseline in NTRIP mode was 7.143m and in PPK it was 7.1198m.
Anyone got any idea why these test results came out different when the position of both base and rover was not changed throughout the test.
I averaged the base coordinates for 20 mins, and i think the difference in ntrip and ppk is about 5-8 cm, haven’t yet calculated precisely.
Today i will be doing the same test on 2 points of known coordinates, those two points were accurately measured by Trimble when we hired them for a survey.
Will be placing base on one and rover on other point and i will post results afterwards.
I would use continous for this kind of test.
Good luck on Monday then
Edit: Fix&hold stick/holdes longer onto a fix and if bad data gets into the loop, it might affect the average output soultion. My thoughts anyways, not sure they are the right one, hehe
Question: Did you use same Base coordinates in both surveys? That is Average Single Base-1 and Average Single-Base2 or Average Single Base-1 and Manual(Average Single -Base1)?
Any difference will show up as change in GPS coordinates. Processing with ENU solution will show you relation between base and rover. Differing survey times will add small error due to different satellites.
We used different base coordinates in both tests and that should be the main source of this mismatch of coordinates from both tests.
Hence we will be doing a test with manually entering the base station coordinates in both cases next week on monday.
It’s my understanding that if you want to compare FIX coordinates in LLH format at different times, you must use the same BASE coordinates. If you want more precise base location, I think you are using base receiver as Rover when you do your initial determination of base location, so you have to have connection to CORS through network to process base location as FIX or FLOAT , but I’m not sure about this.
In any case, I believe that once you have decided on an LLH value for the BASE on you first survey, you must use the same as Manual entry whenever you subsequently survey using that base as reference. If I have it wrong let me know.
That’s very correct.
I have a very accurately measured ground control point with its coordinates known in LLH format, i will place my base over there and enter the coordinates manually.
Then i will place my rover on another GCP with known coordinates as well to check the accuracy of both processes i.e NTRIP and PPK.
If you want to compare NTRIP and PPK, you don’t really need to measure two sessions.
In the first post you mentioned that you postprocessed the raw-logs of both receivers for your NTRIP-results. Though this is PPK no matter if you used NTRIP while logging or not.
So to compare NTRIP with PPK, set up the base and rover as you mentioned in the last post. Then do the logging with the base configured with the known LLH coordinates. Then postprocess the “raw-logs” (also with the known LLH coordinates for the base) and compare them with the “position-logs” and you got the comparison.
After several attempts to connect via NTRIP, we were unable to make a link between base and rover, so we decided to log the raw files and post process them, we took raw RINEX logs from base and rover, 30 mins each and processed them in Rtkpost using known base coordinates.
The point we recorded by averaging the Fix solutions(Q=1) from the .pos file we got after post processing was 1.2 cm far from the original point, that seems pretty good, our baseline was 390 meters so I’m considering the results excellent.
