No Common Time Error

Aaron S

Active Member
I'm still learning the limitations of DPOS and what it can and can't do. When I'm operating with a local base in RTK mode, and have good radio connection to the base, is it safe to say that if you don't get the shot at at the rover, DPOS can't fix it later? In other words, what you see at that time you're on point is (essentially) the what you'll get after DPOS?

But here's the main issue: I have a couple points that I sent to DPOS, and I get the error message "No common time". The BP column says "Yes" and the CP says "wait". I think this is because our state CORS network had some kind of glitch and although the data is available on the server, the date code is screwed up and it can't match the two. What are my options to fix this?

Speaking of DPOS not always being the "magic bullet", I have a couple points where I set up the T-1M base about 1000 feet away, and occupied the point for 1 hour continuously, but I couldn't get a verified shot, or even on to phase 2. I tried all 3 engine configurations, but nothing. What are my options - just a longer occupation time and/or different dates? If I set up my spare T2 and just let it cook all day (I'll probably end up with 8 hours of continuous data), then process as static, how do I check that it's a good solution?
 

Nate The Surveyor

Well-Known Member
AaronS
I don't know the answer, but I am intelligent enough to ask you to take panoramic pics of this site! :)
And, a helpful comment. If rtk gets it in 20 min, then ppk needs 25-30 to get it.
My solution to this is strictly MORE TIME on point. The usual culprit is: wrong time of day, for that particular point. If it was a "wash" at 1 to 3 in the afternoon, try again, from 8 to noon. Or at a time when there are lots of birds up.
I am by no means an expert. I'm a desperado!
Nate
 

Alexey Razumovsky

Well-Known Member
Staff member
5PLS
But here's the main issue: I have a couple points that I sent to DPOS, and I get the error message "No common time". The BP column says "Yes" and the CP says "wait". I think this is because our state CORS network had some kind of glitch and although the data is available on the server, the date code is screwed up and it can't match the two. What are my options to fix this?
Good idea is to send a project to Support and to post here about a problem. It would help to make "better" DPOS and it will help to all our community.
 
Last edited:

Aaron S

Active Member
Nate - I'm in the office today, but next time I'll get you some pics. For now, you'll have to imagine a stand of very tall red pines, with maybe 20-30% clear skies. For some reason, red pine is much worse (or better if you like) at cancelling GPS signals compared to other conifers. I've jammed that LS into a baslam with amost zero sky visibility and it gets verified shots.
 

Aaron S

Active Member
Good idea is to send a project to Support and to post here about a problem. It would help to make "better" DPOS and it will help to all our community.
What's the preferred method to send the project? I swear there used to be a "send project to support" button on the LS, but I just can't find it anymore.
 

Aaron S

Active Member
Project sent to support.

Any other thoughts on Nate's response to the third paragraph of my original post? Is the answer (as I suspect) in seemingly impossible canopy just to spend more time on the point?
 

Shawn Billings

Shawn Billings
5PLS
With GNSS the only way to prove the solution is good is by redundancy. Of course redundant isn't always redundant. You can measure the same distance with excellent precision with a broken tape and still repeat the same wrong answer. With RTK we use new ambiguity resolution to demonstrate the solution is good. But if the multi-path is the same between two solutions, it is still possible to get the same wrong answer. This is why we wait for 180 seconds (many will wait for at least 240 seconds) in the boundary profile for validate to prove the shot, because the multipath is most often different and unlikely to yield the same bad answer. For post-processing we do not see an independent solution, only a final answer. So to prove that a post-processed result is good, we must repeat the observation.

I have seen DPOS give a solution when RTK could not. I would not rely usually rely on a single DPOS solution in canopy without some redundancy to demonstrate the solution is good. So if I must rely on DPOS instead of RTK, I will observe at least twice and hope both observations give the same solution. The rules are changing quickly and the experiences we all had with GPS+Glonass only are going to be obsolete with multi-constellation. With multi-constellation DPOS, I've seen a significant improvement in solutions over GPS+Glonass RTK, and even in multi-constellation 2-Engine, I've seen DPOS give a correct solution where the RTK gave a wrong answer (Precise Topo near canopy and buildings).

The nice thing about GNSS is that redundancy can demonstrate accuracy, not just precision. If we measure a distance ten times with the total station, we see repeatability, but questions about accuracy remain because there may be biases in the system. With GNSS a significant part of the system (the constellation) is changing constantly. While some aspects of the measuring system are the same (antenna calibrations, level calibrations, processing estimates, geoid models, atmospheric models, etc.) the satellites themselves are constantly in motion. The signals are changing through the atmosphere, etc. So we have much more independence from one observation to the next given enough time for the satellites to move.
 

Alexey Razumovsky

Well-Known Member
Staff member
5PLS
Project sent to support.

Any other thoughts on Nate's response to the third paragraph of my original post? Is the answer (as I suspect) in seemingly impossible canopy just to spend more time on the point?
I would recommend 6 minutes. Than next occupation. There are too much rubbish in a long occupation in canopy. It takes many iterations to remove outliers. In the meantime DPOS disposes only limited number of iterations. Said that I meant own base to rover processing (BP) stage 1.
 

Nate The Surveyor

Well-Known Member
I know this is not a direct answer to your question. But...
Back in the Topcon/Legacy E days, I learned that: The more GPS struggles, the more prone it is to be a bad shot. Bad can mean bad init, 1 to 12 foot error. Or "bad" as in sloppy shot, 0.40' error. (Difference between actual location, and gps derived position)
With the Topcon, now, with Javad, there is nearly nothing we cannot get via gps, and verify. If it is "off 0.3'" it warns us via large shot spread in the left hand window.

So, the same rule applies. GPS struggle.... Shoot it 3-4 times.
This is not what you like, but it is the truth.
Nate
 

Aaron S

Active Member
Thanks everyone for the excellent advice and help. My typical procedure in all types of canopy is to shoot the point (via RTK w/ VRS) with the standard boundary profile, set to 5 minutes. I rotate the pole 120 degrees between shots and repeat this two more time and average the 3 shots using the average menu in the cogo tools. Of course, this usually adds up to much more total elapsed time than 15 minutes (3 x 5 minutes) so if I eventually get 3 fully verified shots (and they're acceptably close to each other), I assume it's good.

Sometimes, even after the 3 shots I'll do it a few more times because the epochs plot like an outline of Japan or Hawaii. If I'm in what seems to be restrictive canopy, but the LS starts cranking out shots quickly, while plotting epochs over at least 5 minutes in a circular bullseye pattern, I'm comfortable with a single RTK shot - maybe start a new shot and watch "distance to last" as a check.

However, in cases where the method I've described here won't get a verified shot, the best bet is probably going to be static sessions of several hours each, over the course of a few days. Or perhaps use RTK and if I can get the Boundary profile to get a bucket of shots that are like 25 epochs over 1200 seconds (but not Phase 2 or verified), store that, then come back a couple more days, get something similar (even though unverified) store it and average those? I've been able to get shots like that but I hate to store anything before the boundary profile has finished doing its thing.
 

Aaron S

Active Member
Personally, if an iron that I am trying to locate, for example, is proving difficult I tend to create at least one triangle with two other points within range of measuring with a steel tape. This really helps me sort out what may be working and what may not be working. Steel tapes don't lie.
That's very smart - especially if there's a couple points within 100' of the critical iron that are in open skies... you could always do a dist-dist intersection to check the main point. Thanks, I like that idea!

Alexey - Have you had a chance to check my DPOS project yet?
 

Aaron S

Active Member
Minnesota CORS does not provide data from May, 4, 5h13min to May, 5 18h 53min (GPS time)
That's unfortunate. Luckily I also shot the base point RTK, so I can still use that. But it's always nice to have a CORS solution for a check. I almost always get an RTK shot first on my base point, for cases just like this.

Thanks for looking into this.
 

Joe Paulin

Active Member
Aaron,

CORS processing your static data though DPOS will need a substantially longer occupation time compared to local base/rover processing.
 

Aaron S

Active Member
OK, so I did 2 static sessions on two separate days, each about 4.5 hours long using a T-1M. After running them through DPOS website, the resulting points are within 0.03 feet of each other, and RMS's of 0.05 and 0.04 feet. That's pretty good right? Would anyone recommend more occupations?

Now, I'll need to combine these results. Is there a more elegant method than simple mathematical average? Would there be any advantage to a more complicated method?
 

Alexey Razumovsky

Well-Known Member
Staff member
5PLS
OK, so I did 2 static sessions on two separate days, each about 4.5 hours long using a T-1M. After running them through DPOS website, the resulting points are within 0.03 feet of each other, and RMS's of 0.05 and 0.04 feet. That's pretty good right? Would anyone recommend more occupations?

Now, I'll need to combine these results. Is there a more elegant method than simple mathematical average? Would there be any advantage to a more complicated method?
I would recommend simple averaging or weighted averaging. Weight = 1/sqr(rms).
 
Top