Earth's Largest Land Surveyor Community
I'm brand new to post processing using OPUS or any other post processing method. A couple of days ago I collected 5 points, each for 20 minutes and uploaded them to OPUS. All point were collected with the same setting on my data collector. Four of the points came back with good results. One of the points didn't process and I received the following error from OPUS
The file Base_3 seems to have a collection interval of 14 seconds!brThe collection interval must be 1,2,3,5,10,15 or 30 seconds to be processed by OPUS.
1. I'm wandering why this happened and if I can edit the TPS file to possibly remove the data point that is causing the problem??
2. With regard to the four points that were processed, can anyone elaborate on the quality of the data based on following typical results?
OBS USED: 91%
QUALITY IND. 13.47/ 2.56
NORMALIZED RMS: 0.356
This Content Originally Published by a land surveyor to Land Surveyors United Network
I run OPUS static with my antique Topcon Turbos (8 channel L1/L2). Always at least two simultaneous points, sometimes up to 4 at a time. I always run at least 2 hours, and get 0.01 meter RMS. I also post process them against each other as a check, and then use them to control my total station. Your high RMS may be a result of your short sessions.
I also find the data rate is not that important in the longer sessions. One minute works just as well as 15 seconds, but the files are a lot smaller...
I am not familiar with your TPS files. I convert my files to RINEX so I can edit them with notepad. You might convert all of your files to RINEX, and them check the fist few readings to see why the one file failed. If you need to need to remove a few reading from top of the file, just remember to edit the session start time to match the first reading.
As long as you save your original files someplace safe, you can keep editing the file and resubmitting until it gets accepted.
Very helpful Jim! Any suggestions on where can I get a file converter to covert my TPS files to RINEX?
TEQC is software onlione that is free to download and should convert your files to RINEX format. You can submit the RINEX files to OPUS just like your TPS files.
I hope it helps you out!
The OPUS service will only process sessions with the prescribed recording interval. Imagine if you where trying to use a base/rover setup with the base set a 5 second update and the rover at a 12 second update. They would only sync once every 60 seconds. Your RMS error is a direct result of the very low number of synchronized readings between your receivers and the OPUS ones.
OPUS "thins" files to a 30 second interval, so do a little math and figure out how many epochs at both 14 seconds and 30 seconds match up in 20 minutes. You had 2.... one at 7 minutes and one at 14 minutes.
Therefore OPUS could only process those two readings out of the 20 minute observations. A 5, 15 or 30 second interval would all give you 40 synced observations.
Review the following info page from NOAA and set your receivers to match - when ever I collect data for post processing, I use 5 second interval because I will process my own observation network first, then I will OPUS session the two best or most obstruction free points to upload to OPUS.
Bottom line, the problem is with your receiver recording interval settings.
Hope this helps,
My Bad, I missed the "one out of five" part. I'd suggest the you look for obstructions that might be interfering with this point. Also, if its an important point, try running a 30 minute session. While I have ran many, many OPUS sessions - both Static and Rapid Static - I rarely use a 20 minute observation except in the most wide open locations and at times that have the best/highest GPS Sat count. Remember OPUS does not process GLONASS or any other data, only the USA's GPS.
Again, sorry for jumping the gun on my first post,
I think you were right about obstructions being the issue. I moved to a higher point and the new point was processed without issue.
I run 20 min. statics all the time. Usually anywhere from 4-6 surrounding a job site. I have similar issues (once with similar error) but over the years just have expected with 20 min sessions your going to get a bad static from time to time. 1/10 if not more often. As noted above look for obstructions or any overhead utilities
Thank you for the reply. That's good to know. I ran a couple more statics on this project last week and I occupied those points for 40 minutes. The Quality Ind. for 40 min occupation was a lot higher 27.19/38.3 versus 13.47/2.56 for the 20 min occupation. And the RMS was a little less for the 40 min observation (0.305) versus (0.356) for the 20 min occupation. So I might make 40 min my standard going forward.
When I checked the distance between 2 static points about 350 feet apart with the optical, the horizontal distance was within 0.12'. That seems reasonable for the accuracy of rapid static. Agree?
Indeed. Just be sure to localize your statics for a solid baseline. .12' from opus to opus is not terrible. Doing this will make all points collected after wards within a .05' (if tolerance is set up proper) from each other and not your .12'
Just putting this out here, did you adjust your optical distance for your scale factor? Since the two OPUS points are so close ( 350 feet and not 3500 feet) I'd pick the scale factor from the point with better results.
Also, if you take out 0.03'+/- for your rods being not quite plumb (0.015' each) and the tolerance for the GPS equipment of 5mm +/- (0.016') You can systematically cut the 0.12' by half. Then you do the same thing with your optical equipment and you can quickly get to the point where your measurements could be within the tolerance errors of your equipment.
Like the Old Guy told me, half of surveying field work is error management and the other half is cutting line..
Guys I just really appreciate the comments!!
I'm sure my rods have that much error. Help me out a little with scale factor. The Opus gave two results for SPC :
Point Scale - 1.00010404
Combined Factor - 1.0000552
I think Combined factor is what I need and its only results in about 0.02' in 350' in this case.