Discussion in 'General RTK Land Surveying' started by Matthew D. Sibole, Mar 15, 2016.
I have uploaded the DPOS chart screen as well as my project archive in the original post.
The current engine in Justin deals the correct solution and is within 0.07' horizontally of your RTK solution:
The problem is with the current engine being used with DPOS as @Alexey Razumovsky previously mentioned: https://support.javad.com/index.php?threads/unusual-dpos-results.2954/page-2#post-27509
That is great! I did not bother checking with Justin because I had enough confidence with the RTK and the point checking so well to record.
So when is the engine being used in Justin going to replace the engine currently being used for Dpos. Seems to definitively tell us we should be very wary of Dpos results in difficult conditions doesn’t it?
In bad environments I do not trust a single DPOS PPK solution even if fixed. I require some form of redundancy to prove that the PPK solution was correct, either by a second DPOS solution or some record call or taped offset from a point I have confidence in.
Oh absolutely. I don’t either. Never have even thought about using only one individual PPK solution.
It’s just it sounds as if there’s different engines working through Justin as there is in Dpos and if the Justin engine is producing more reliable solutions...then well.
For instance, Matthew “knew” his rtk was good based on other data, but he didn’t get the redundancy he wanted from dpos......he would have if Dpos was using the engine Justin is using....
I resubmitted Matt's project to DPOS and reprocess raw data in Justin. Above mentioned site 108 is really questionable. All others are OK.
Frankly saying, my point is that DPOS/Justin engine which is running in automatic mode should not process such data. I see it as stable and confident service. DPOS does not provide full data control. Justin does. It's possible to process site 108(rover) relative to site 3(base) in Justin. Difference in Justin and DPOS solutions depens on a processing settings.
Until we have no loop closure test there is no way to check PPK solution except multiple site occupations.
Anyway I like the case and I have added site 108 data to my wish list. I will be happy to have more data like this.
Exactly why I preach to users to locate points multiple times! We need a check to verify all coordinates. If we can not repeat it then we can not expect the next guy to be able to repeat it.
Absolutely, I just, without really understanding, thought "If Justin gives a better more thorough solution then why is there a different engine used in Dpos".....then Alexey explained it perfectly as to why that is.
No matter what/where/how you get data, there's nothing better than redundancy!
With long observations like this it is easy to divide the processing into several segments with Justin to compare the results with the solution from the entire observation. This is the best test I have found without loop closure. Alexey are still opposed to DPOS having some verification check by dividing an observation into several segments and comparing to the solution from the entire observation?
I processed it with the default settings and Auto engine mode in Justin 126.96.36.199 and got a good solution.
Is this different than how DPOS is processing it?
I also used to split full observation session into some pieces and compare post processing results. It's a good check if you have enough data to split and you have a tool to analyze results. The question is - do we have enough. As a rule I look at the residual chart, statistics and timeline to decide.
Do you agree that validation/verification interactive tools are very useful in Jfield? Do you want to remove it?
Residual chart, statistics and timeline are so much important for PPK as validation/verification for RTK are.
Shorter - no interactive mode in DPOS then no splitting!
Slightly difference may exists. DPOS process own base-rover vectors in L1&L2 mode(not Auto); second, DPOS result depends on receiver's firmware versions. For firmware 3.7 and higher we use new aproach (L2C, L5 signals, Galilleo).
Separate names with a comma.