No Common Time Error

Joe Paulin

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

Seems good to me, how does the vertical compare? Even if I don't need vertical, I always compare the vertical as a quality indicator.
 

Aaron S

Active Member
Seems good to me, how does the vertical compare? Even if I don't need vertical, I always compare the vertical as a quality indicator.
Unfortunately I didn't record the antenna height for either setup (usually just boundary work). ...I know - I really need to get into the habit. I agree with you that it's a good check of the overall quality. It's something I watch when the LS is "making popcorn" - how consistent the verticals are.
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
DPOS: 1 report

ANT HEIGHT: Vertical(ARP) -1.520(m) OVERALL RMS: 0.009(m)
ANT DELTA N/E/H:0.000/0.000/0.000
REF FRAME: NAD83(2011)(EPOCH:2010.0000) ITRF2014 (EPOCH:2017.637)

X: -304684.342(m) 0.003(m) -304685.257(m) 0.003(m)
Y: -4283919.095(m) 0.006(m) -4283917.815(m) 0.006(m)
Z: 4700191.666(m) 0.006(m) 4700191.635(m) 0.006(m)
DPOS: 2 report

ANT HEIGHT: Vertical(ARP) -1.520(m) OVERALL RMS: 0.007(m)
ANT DELTA N/E/H:0.000/0.000/0.000
REF FRAME: NAD83(2011)(EPOCH:2010.0000) ITRF2014 (EPOCH:2017.637)

X: -304684.352(m) 0.002(m) -304685.267(m) 0.002(m)
Y: -4283919.135(m) 0.004(m) -4283917.855(m) 0.004(m)
Z: 4700191.707(m) 0.005(m) 4700191.676(m) 0.005(m)
Calculus
Weight1 = 1/(RMS1*RMS1)
Weight1 = 1/(0,009*0,009) = 12345,679

Weight2 = 1/(RMS2*RMS2)
Weight2 = 1/(0,007*0,007) = 20408,163

Xweighted = (X1*Weight1+X2*Weight2)/(Weight1+Weight2) = (-304684,342*12345,679 - 304684,352*20408,163)/(12345,679+20408,163) = -304684,348

Yweighted = (Y1*Weight1+Y2*Weight2)/(Weight1+Weight2) = (-4283919,095*12345,679 - 4283919,135*20408,163)/(12345,679+20408,163) = -4283919,120

Zweighted = (Z1*Weight1+Z2*Weight2)/(Weight1+Weight2) = (4700191,666*12345,679 + 4700191,707*20408,163)/(12345,679+20408,163) = 4700191,692
 

Aaron S

Active Member
Thanks Alexey. I think where I got confused is that your original formula shows the lower half of the equation being the sum of the P's. I'm thinking it should be the sum of the weights. I appreciate the example.

Does the total time of the solution play a part in this? Consider if this was 4 static sessions we were weighing - with each session being 2, 3, 4, and 5 hours long. If you weigh them based on RMS alone, is that taking into account the different timeframes? Because longer sessions will be better quality, usually. Or is that all captured in the RMS value?

OR am I getting into territory that's beyond my tenuous math skills! :D
 

Nate The Surveyor

Well-Known Member
@Aaron S I've never done that! ;)
Seriously, I've been watching this subject for a long time.
From L1 only, with 8 channels,
To Topcon/Javad, Legacy E.
To the T-2 LS combo.
And, always, I'm not as interested in how it does it, but I ALWAYS want is the coordinate that is as close to the actual as possible.

So, when you go to the woods, this argument (RMS, vs Time) sort of goes out the window.


Short time observations, that yield low rms values.
Long time observations, that yield high rms values.
Long time observation, that yield low rms values.
Which one is closest to the actual value?
My general "truth", is that the longer observation, (I mean ridiculously long ones, like 4 or more hours) generates:
The most accurate coords. That the equipment is capable of.
And
The most accurate error estimates.
So, by doing 3, 4 HR observations, and averaging it, you start to get a very HONEST look at the numbers.
If you did 10, 4 HR observations, then you start to see that you practically had all you needed with 3 HR. Observations.
Then, you start to try 3 15 minute observations, and compare that to 5 15 minute ones.
What I'm seeing is:
The more challenging a site is, then the more time, and observations are needed, for an accurate (closer to actual) that both numbers are. (Error estimates, and close to actual, and error potential).
It's those obstructions (multipath) that pushes you to need more time.
The javad system drastically reduced the amount of time needed, to get both numbers.
That was a long sermon, on how I do it, AND how I became a Javad fan.
Nate
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
Thanks Alexey. I think where I got confused is that your original formula shows the lower half of the equation being the sum of the P's. I'm thinking it should be the sum of the weights. I appreciate the example.

Does the total time of the solution play a part in this? Consider if this was 4 static sessions we were weighing - with each session being 2, 3, 4, and 5 hours long. If you weigh them based on RMS alone, is that taking into account the different timeframes? Because longer sessions will be better quality, usually. Or is that all captured in the RMS value?

OR am I getting into territory that's beyond my tenuous math skills! :D
Let's consider observations in open that we are doing relative to CORS. Most accurate are 24 hours session. Spread of positions is within 0.01 meters while processing 365 days. 12 hours sessions are 1.5 time less accurate. 6 hours sessions are 2 time less accurate. 4 hours sessions are 3 time less accurate than daily sessions. Said that I mean 365 days processing data. We did this tests for a lot of locations tied to CORS.
 

Aaron S

Active Member
Nate - Lots of good wisdom there. I'm probably splitting hairs in this example where the points are only a couple hundredths apart, but I want to know for when they're not. But if I can run two 4-hour static sessions on different days, and get essentially the same answer, in difficult canopy - I'd say that's a win! (and probably doesn't warrant a third session) My main thing is repeatability. It makes me very happy to go out there on different days, with totally different satellite geometry (and sometimes a different GNSS receiver) and get basically the same thing. That's how I make sure I can trust it.

I have the luxury of being a federal employee where time is usually not a limiting factor on my efforts. I like to try understand the equipment as well as I can, to produce the best results I can. Since I can take my time (where some in the private sector may be rushed to produce results), I make sure I'm doing all I can to give John Q. Taxpayer the best bang for his buck, and hopefully no one has to second guess my work later, or redo it.

And Alexey... Thanks again!
 

John Troelstrup

Active Member
Alexey,

I have a project I ran yesterday. Base was setup in good location for several hours. Good sky.
Located my points and tried to DPOS this morning and received a "No Common Time" error with no processed points.
I have sent the Log to support and await further advice.
The project is titled "12719 Chicago Ave"

Thank you,
John
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
Alexey,

I have a project I ran yesterday. Base was setup in good location for several hours. Good sky.
Located my points and tried to DPOS this morning and received a "No Common Time" error with no processed points.
I have sent the Log to support and await further advice.
The project is titled "12719 Chicago Ave"

Thank you,
John
Got it
 

Bryan Enfinger

Active Member
Residuals of the observed baselines area very good indicator of bad or good data. You'll have to request the "extended" version of OPUS to see the baseline rms
 

John Troelstrup

Active Member
Hey John, we found that some CORS are represented with not completed RINEX files. Its our issue. I believe we will fix it soon. We have successfully processed your project in manual mode.
Thank you very much. If I return to work in this area, will this be a recurring problem for this particular area?
How do I obtain the corrected information?
In order to proceed at this point, All I need to get started is the Txt file.

Thank you
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
Since now we have no noticed uncompleted CORS data files in the states other than Florida.

Coordinates are in attached document. Epoch 2020.9192.
 

Attachments

  • Report epoch_2020comma9192.txt
    25.8 KB · Views: 224

John Troelstrup

Active Member
Since now we have no noticed uncompleted CORS data files in the states other than Florida.

Coordinates are in attached document. Epoch 2020.9192.
Thank you for the processing. I appreciate it very much Alexey.
In the future, is there anything that I can do to alleviate or detect this problem while in the field?
Everything was working normally and it felt like a good day with no problems.

I always start the base in Autonomous.
Would it be better practice to always use the FPRN ( our statewide broadcast network )and establish a working point on grid to set the base up on?
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
It happens no often , not every day(in Florida). If I were surveyor I'd use a rebar to pin base station position. In a case like this I would repeat an observation next day.
 

John Troelstrup

Active Member
Since now we have no noticed uncompleted CORS data files in the states other than Florida.

Coordinates are in attached document. Epoch 2020.9192.
Alexey,

Pardon my ignorance. I have no idea what to do with the file that you attached.
Can you provide assistance or point me in the direction of what I need to know.
Just looking for a txt file of the P,N,E,Z,D adjusted to Florida West SPC with NAVD88 elevations.

Thank you for any assistance.
John
 
Top