Post pics of difficult shots

Matt Johnson

Well-Known Member
5PLS

Darren Clemons

Well-Known Member
The current engine in Justin deals the correct solution and is within 0.07' horizontally of your RTK solution:

View attachment 7224

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
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?
 

Shawn Billings

Shawn Billings
5PLS
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.
 

Darren Clemons

Well-Known Member
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....
 

Alexey Razumovsky

Well-Known Member
Staff member
5PLS
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.
 

Darren Clemons

Well-Known Member
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!
 

Matt Johnson

Well-Known Member
5PLS
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.
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?
 

Matt Johnson

Well-Known Member
5PLS
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.
I processed it with the default settings and Auto engine mode in Justin 2.123.161.53 and got a good solution.

upload_2018-2-12_8-36-26.png


Is this different than how DPOS is processing it?
 

Alexey Razumovsky

Well-Known Member
Staff member
5PLS
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 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!
 

Alexey Razumovsky

Well-Known Member
Staff member
5PLS
I processed it with the default settings and Auto engine mode in Justin 2.123.161.53 and got a good solution.

View attachment 7228

Is this different than how DPOS is processing it?
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).