I have a customer that has sent 3 files to DPOS and he is getting an error "Process initialization failed". He submitted the same files to OPUS and was able to get a result.
Is DPOS down?
- Thread starter Matthew D. Sibole
- Start date
We made some repairs at the moment. DPOS may works for the customer.
I can't get DPOS to work either. It goes to 30% and then stops. It then says Wait. CORS data not available.
Last edited:
You might resubmit data tomorrow morning.
I just ran it through DPOS on the website, not through the LS and it processed fine. I need the data today so I will manually move my points I collected with RTK. Thanks!
Nate The Surveyor
Well-Known Member
I've got a job day 2 of Salem ar, that is broke.
Re dpos, (base processing only) and its done in 5 seconds. But does nothing.
It is a small file, maybe 10 shots. 3 hrs or less.
Re dpos, (base processing only) and its done in 5 seconds. But does nothing.
It is a small file, maybe 10 shots. 3 hrs or less.
Nate, did you send the project in that state to support?
Also if you can - try the PreRelease version 2.0.0.254
The problem was in the DPOS session duration (see the screenshot in the post above). It lasted 4 seconds. In the PreRelease I don't use a session duration.
If somebody know how to reproduce the issue with wrong session duration - please tell.
Nate The Surveyor
Well-Known Member
Michael, that's it!!
I'm on TESTING version 2.0.1.523
So, I went to Pre-Release, and found 2.0.0.256
So, is 2.0.0.256 a previous version of what I have, but a later version of what you have?
Should I go back to 2.0.0.256, solve this file, and then go back to what I'm on?
Thanks
N
I'm on TESTING version 2.0.1.523
So, I went to Pre-Release, and found 2.0.0.256
So, is 2.0.0.256 a previous version of what I have, but a later version of what you have?
Should I go back to 2.0.0.256, solve this file, and then go back to what I'm on?
Thanks
N
I don't recommend to use 2.0.1.523. It is old in context of bugs fixing.
Please use PreRelease 2.0.0.256.
Nate The Surveyor
Well-Known Member
OK, thanks. I'm updating now.
Nate
Nate
To clarify.
We have development and release branches of source codes.
The development branch produces a development version which goes to a testing version if there are no unresolved known critical issues.
The release branch produces PreRelease version which goes to Release if it was thoroughly tested.
During period of PreRelease we can move some fixes from development branch to the release branch.
So it can be that some fixes exist in the PreRelease but not exist in Testing version (it depends on when a version was built).
The testing 2.0.1.523 was built on May 12. Since we have a lot of bug fixes in the development branch and some of the fixes was moved to the release branch.
Nate The Surveyor
Well-Known Member
OK, it processed now. Any idea how it got the 4" duration?
For what it is worth, the main point of interest for me, was the points 280, and 281.
I KNEW 280 was RTK bad. I had saved it, with DPOS as the last characters of the point desc. That was my flag that RTK was not good. When PPK processes it, (498 second shot) it is good, and real.
Point 281, was a fully verified, RTK shot, that I had high confidence on. I had it set to 200 seconds, as a parameter. But, DPOS came back with PPK as better, however it's not.
So, for development purposes,
280 is RTK bad, and DPOS good.
281 is RTK good, and DPOS bad.
When looked at like that, they are 0.0435 apart.
Which, is what I expect. I am saying this, so you at development can get feedback, to refine the mechanism of selection between DPOS and RTK.
It's feedback.
Also, FYI, points 284, 285, and 286 are all the same point.
284, RTK and PPK agree well.
but not so for 285 and 286
I am confident that an average of 284 285 and 286, (RTK) are yielding a good solution.
Again, this is feedback.
Nate
For what it is worth, the main point of interest for me, was the points 280, and 281.
I KNEW 280 was RTK bad. I had saved it, with DPOS as the last characters of the point desc. That was my flag that RTK was not good. When PPK processes it, (498 second shot) it is good, and real.
Point 281, was a fully verified, RTK shot, that I had high confidence on. I had it set to 200 seconds, as a parameter. But, DPOS came back with PPK as better, however it's not.
So, for development purposes,
280 is RTK bad, and DPOS good.
281 is RTK good, and DPOS bad.
When looked at like that, they are 0.0435 apart.
Which, is what I expect. I am saying this, so you at development can get feedback, to refine the mechanism of selection between DPOS and RTK.
It's feedback.
Also, FYI, points 284, 285, and 286 are all the same point.
284, RTK and PPK agree well.
but not so for 285 and 286
I am confident that an average of 284 285 and 286, (RTK) are yielding a good solution.
Again, this is feedback.
Nate
DPOS failed at 280 and 281 due to ephemeris leak for some sats(blue coloured at the picture). We will fix it.
Nate The Surveyor
Well-Known Member
Thanks Alexey! I will add that to my list of things that can go wrong! "Ephemeris Leak" did not pop in my head. Is that where the program tries to process "Phantom" data, that's not there? But, because the ephemeris says it it, it tries?
All ephemeris are available at NGS 1 hour later. Seems we should stop base-rover processing until 1 hour elapsed after survey time. In fact, good issue. Thanks, Nate.
Below are results after ephemeris have been well imported. Discrepancy is 0.026 m.
Below are results after ephemeris have been well imported. Discrepancy is 0.026 m.
This would not be good. Right now, in most cases we can process base to rover immediately after download. I would not want to wait until top of the hour if we can avoid this.
Maybe just delay processing only when there is a problem with the ephemeris data in the jps files.