I have uploaded the DPOS chart screen as well as my project archive in the original post.
I have uploaded the DPOS chart screen as well as my project archive in the original post.
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?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
Oh absolutely. I don’t either. Never have even thought about using only one individual PPK solution.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.
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.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.
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.
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 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.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?
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).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?
Thanks Nate....I attached that quickly this morning and didn’t even notice it came in sideways