Activity Feed › Discussion Forums › GNSS & Geodesy › TBC vs OPUS question
-
TBC vs OPUS question
Posted by dave-o on August 13, 2023 at 1:59 amTotally out of ignorance here, but I’ve got the TBC trial version going, have zero experience with it except for some YouTube videos, and have some questions regarding import and coordinate systems/datums/reference frames:
The plan was to import a GPS static file (nnn.t01 or nnn.23o ?) into TBC and try to match what opus reported on the point – seems simple
I set a new project to global coordinate system – metric -> WGS 84; datum transformation is NAD83 (2011) Molodensky(?) using GEOID12B (Hawaii) and a US NAD83 Hawaii Zone 1 (1-5101) SPC. I was trying to match what I’d see from OPUS.
When I import the nnn.t01 static file to TBC (one point) it shows me I’ve got almost 4 hours of occupation and first thing I notice is that the point properties show “Global Coordinate – NAD83(PA11)” where I thought it was set to WGS84. Then “Local Coordinate – NAD83(PA11)” also – which I thought should be what’s there and the “Grid Coordinate -Hawaii Zone 1 5101 + GEOID12B”, which I also thought should be there.
Question 1 is: am I transforming twice by having Global and Local both set to NAD83…?
Even more disturbing – I select the imported points’ properties (the nnn.t01) and it’s over 3m higher than what OPUS reports (for the SPC+geoid pont) and > 3.5m away.
If that’s not just making me twist my face to about 40 degrees from normal, I converted the t01 to RINEX and imported that – which to me should be the same wrong as the t01 – and it comes in almost 6m from the keyed in OPUS point and over 6m difference in elevation.
I’m positive I’m confused/missing some basic concept(s). Any even fundamental input that could flash a little spark into this old brain?
OleManRiver replied 1 year ago 8 Members · 27 Replies -
27 Replies
-
So the opus is processed data. Your nnn.t01 is raw data unprocessed. So they will not match. You can send to opus throughTBC and or send to trimble rtx center point. Its there version of a Opus solution. I do this as a sanity check. But NGS OPUS gives me something to tuck away in project folder and state in notes on plats and drawings for someone to follow. I would have to read up on hawia datum and coordinate system before I could answer anything on that. What i do is set up my project coordinate system in TBC to be nad83 20-1 va south or north zone. Then choose my geoid model 18 for us on nad83 2011. I don’t do the transformations menus. As it’s defined already no need for us. Now if I want to do a transformation to a different datum then. But I prefer to use ncat for that and then build a different project in correct datum. If this doesn’t help and no one else can. Pm me i can jump on the laptop and we can teams or whatever and try and figure it out.
-
Your OPUS data is NAD83 and you’re OK being set global and local as NAD83. WGS 84 shouldn’t enter the picture.
In your imported data there will be an autonomous position associated with the raw data. That coordinate is meaningless for this exercise and can be disabled. If you want an independent check of your processing send the raw data to RTX. This is a different treatment of the data and should come out almost identical.
THRAC.. TBC is a powerful toolbox, but they still can’t let go of WGS84. They are just like my brother who married the same chick three times. Let it go. It’s not healthy…
-
Agree with the above post.
Opus gave you a processed solution based off the 3 (or more) closest NGS cors base stations.
The TBC import you did is just the raw observations. It has no fixed base station to process baselines off of.
Just to get you started…. go to NGS CORS map. Click a station nearest you. Get a data file (dat, rinex, etc.) for the date you did the 4 hour observation. Drag that file into your TBC project. It should draw a line between your static point and the CORS base. Now you can start playing around with TBC and see what options are available.
This is just to get you moving in the right direction
-
@thebionicman Love it. Well everyone starts in wgs84 with gps. However no one well most no one is survey grade wgs84. Except for a few. I am with you once you select whatever datum/reference frame. Wgs84 should not be in the verbiage. Also i have been keeping a little running log of opus vs rtx and not much difference at all so far. I have seen a little over a tenth here and there but mostly under and usually the position falls within the uncertainties that opus provides via ngs.
-
@cutphil81 @olemanriver @thebionicman
Wow, thanks, all. I sent the t01 and 23o files to RTX (OPUS) and they scooted right up next to each other. Then, out of the shear joy of learning something so cool (and only having 29 days left to check this out) I downloaded the datasheets from the 3 CORS sites listed as referenced in the OPUS solution for the single point occupation, saved them from the email as html and dropped them into TBC (1). They showed up so I exported them all to Google Earth – voila, a cool graphic.
Then followed @cutphil81‘s rabbit trail, went to the CORS map and selected each of the 3 stations, downloaded their data zip file based on the time span, imported the .xxo files and… they drew two baselines between the 3 CORS stations so, not sure what to do with that, but maybe for another day. Quickly realizing how little I know about this.
Thanks so much
dd -
@dave-o you could post process those baselines. As a way to play with that aspect. So instead of OPUS using pages to process you can as well. TBC is very powerful and i have not even made a dent in what all it can do. I have a static project coming up and has some tight tolerances. So i went to the CORS map and chose all the stations surrounding my area’s and processed several different times and days to get use to it a bit. But i also like to know how they check between themselves before i start building a network as well. One i have discovered has a vertical discrepancy. So i will not hold the published value on it. I think its an antenna replacement or wrong antenna in the rinex header . Probably just has not been updated or NGS was not told about it yet. This is why we are all here to learn from each other. Glad to help anytime. I am still learning TBC myself so i am no expert either. Rover has been a big help as well. When you get into fixing control for adjustments you have a couple different ways . So on cors station data sheet you can see the n e up values or the hz vt not all data sheets have that but the actual NGS owned ones usually do and that allows you some weighting for it as well. Good luck have fun. I have been working and learning the drafting side slowly. I do all least squares with rtk and robot data now days .
i have to give rover83 the goods as he helped me find out how to apply those values i knew I wanted them but had no idea on exactly how. Great people here is all i can say.
-
@dave-o you could post process those baselines. As a way to play with that aspect. So instead of OPUS using pages to process you can as well. TBC is very powerful and…
I understand most of those words but have no idea how to go about doing any of that… this is the fun part, though, screwing up and hoping it doesn’t make it to deliverable. This is an actual job, but going through the bit of this has just helped me feel more secure about the map I’ll create from it. Mahalo pahi.
dd -
@dave-o oh man i speak Mississippi lol. No worries at all. You are doing what i have done. I would get a solution from something like opus and then take the raw data and see if i could get the same or close. The baselines or line you see is grey I believe we call those vectors. Once we process them they are still vectors that have been solved for. Like a total station you turn many angles direct and reverse the mean angle is your truth in the end. Unfortunately the raw vector not processed is not very precise or accurate. Rtk creates a vector thats blue in TBC it has already solved the interger ambiguity so its good well good for no extra processing. Never hesitate to ask. Go to Trimble knowledge center youtube channel and such it can help.
-
@dave-o With TBC, when in doubt right-click. You will get a command history or sub-menu (depending on where you are). It can lead you to relevant functions.
Good luck, Tom
-
Question 1 is: am I transforming twice by having Global and Local both set to NAD83…?
Nope.
Even more disturbing – I select the imported points’ properties (the nnn.t01) and it’s over 3m higher than what OPUS reports (for the SPC+geoid pont) and > 3.5m away.
At first blush this seems problematic, but it isn’t. That value is essentially just a seed coordinate to facilitate processing. If you didn’t previously have a position for said point in your DC it’s basically just a ‘here’ position, and being +/-3m isn’t surprising.
WARNING: this is without morning coffee… might gloss over a couple items.
1: upload your t0 files
2: upload your CORS files
3: upload ephemeris if you have it- you can download this in TBC itself or just go to the source like I do (ftp://igs.ign.fr/pub/igs/products/mgex/)
4: either import the CORS data sheets or manually assign control quality lat/long/height positions to your CORS
5: process your baselines
6: make sure your standard errors and centering errors are to your liking in your project settings
7: perform min. constrained adjustment as a backcheck
8: assign uncertainties to your CORS and fully constrain
Enjoy.
-
If your up for having a bit of fun with it you can download the observations for the various CORS stations of your choosing and process the resulting vectors to your observations to come up with your own version of an OPUS solution. Using various combinations of stations based on their distance from your work and geometry, you can get a better sense of the variables that play into whatever solution you’ll end up the most comfortable with. Trimble’s RTX is another option as mentioned. I have in the past used CORS in lieu of my base data to solve vectors in a pinch and it actually works rather slick, in a pinch.
Willy -
Trimble’s RTX is another option as mentioned. I have in the past used CORS in lieu of my base data to solve vectors in a pinch and it actually works rather slick, in a pinch.
Sometimes it can very helpful to add CORS to the network, even if they are not going to be held fixed.
RTX-PP is an excellent check on OPUS (or manual CORS processing). Different processing method (PPP) utilizing a different set of reference stations (Trimble’s global network), and is full GNSS rather than just GPS.
“…people will come to love their oppression, to adore the technologies that undo their capacities to think.” -Neil Postman -
Speaking of using CORS. What are Yall using for centering and height errors on CORS stations and are you processing linear quadratic etc. seems I always fail the chi first time but on low side and results don’t really change after * scaler but passes next session every time. I am proving cors stations and then choosing the best few around a area to build a network from. Long long baselines.
-
I did a comparison of OPUS solutions to static processing of the same data using CORS data. It was great way to practice with the software and hardware and working with CORS raw data.
GPS receiver: iGage iG5 GNSS unit.
Software: CHCNav CGO2
Here is a PDF of various comparisons.
-
@gary_g Thats exactly what i have been doing so I can figure how the software works. Playing around with different settings etc.
-
Speaking of using CORS. What are Yall using for centering and height errors on CORS stations and are you processing linear quadratic etc.
If I’m doing an adjustment that’s just bases and CORS I generally do something to the tune of 1-1.5mm for centering. If I’m doing a combined adjustment that includes RTK/stop-and-go, I’ll usually bump it up to 3mm.
I usually process linear. There’s usually plenty of stations within 5-15 miles.
-
@steinhoff gotcha. I am about where you are then. Do you see the lower factor first go so if i am remembering correctly lower means my measurements are better than I assumed. Higher I usually have an issue I didn’t catch. Or I thought i was better than I truly am. I use about 3mm for rtk . I am doing static to transfer elevation from a 1st order mark to site and cors to get my horizontal. We will also have rtk and digital levels as well. And a traverse through the woods. Cors stations are about 7 to 15 plus miles away some further for me to get one in each quadrant. Once i have a pair or two on site it will be smoother as a few miles total. Just getting it there. The bms are all within a couple miles so not bad to do what is required. I have to hold cors and at least one ngs main cors so fun times. Learning with tbc. I have not done a lot of post processing with it yet. Lots of other networks larger in the past but totally different software then. I asked the dealer how to disable spotty data on satellites he said no need. I am reading tonight to try and figure out if it’s possible. I used tgo years ago and i could do it there and same with gpsurvey for off the shelf software. I may run everything through opus projects as a check but client wants tbc reports so i will have to figure it out.
-
Do you see the lower factor first go so if i am remembering correctly lower means my measurements are better than I assumed.
Usually, yes. It’ll be closer to unity if I’m doing CORS+bases & stop-and go together. Whether I process CORS baselines against the rover or just use baselines from my bases… depends on my mood and what kind of ephemeris I have. Distance and rover obs time is also a factor.
Higher I usually have an issue I didn’t catch. Or I thought i was better than I truly am.
That usually means a blown base height for me. This is why I highly recommend to crew to do somewhat significant changes in base heights between round 1 and round 2 of observations. 2 bases + different heights for each usually gives me enough to pick out the bad height.
We will also have rtk and digital levels as well. And a traverse through the woods.
A lot of networks I do are full combinations as well. If it’s a rehash of an older project before my tenure I’ll also usually scrape data from old control and topo files. Some of our chiefs still have it ingrained to do foresight checks when doing topo… Get enough of them together and you can actually get some decent redundancy when paired with the control work.
One fun thing to do if you can field 2 bases is have RTK vectors from your RTK base and post processed stop-and-go from the other base in your adjustment. Gives you a nice mix of processing methods for your GNSS to try to chase out the poltergeists.
I asked the dealer how to disable spotty data on satellites he said no need. I am reading tonight to try and figure out if it’s possible. I used tgo years ago and i could do it there and same with gpsurvey for off the shelf software.
The TBC equivalent you’re thinking of is session editor. Select your baseline, right click, session editor. To be honest I somewhat agree with your dealer. From what I’ve seen TBC is pretty good about screening out the fuzz. There was a time when I checked all my baseline processing reports and then dived into session editor to turn off satellites or snip out cycle slips, but now I mainly do that only when stuff gets weird when the adjustment is happening and I’m trying to troubleshoot data.
-
@steinhoff Thanks that’s awesome information to know. I truly appreciate that information. Its funny. I have my crews do third point cks just because i know it gives me extra redundancy and it doesn’t take that long. I have been on smaller projects usually a boundary. Have them set up in the best spot in as close to middle of the site and rtk and logging. No cell coverage so network rtk is out. In these I usually have them set a few control points first thing then do all the mapping and and find corners. Rtk those observer control points. Then depending on time and how much mapping is still needed hit a couple of the main control again. Move base to one of those and finish up tying the prop corners and all control again. Usually the 3rd day i have them set base on one log data as a extra opus ck and any outliers tag again at a time i deem to get separation. Maybe. But its then they usually set up robot to locate bldgs car ports and items rtk don’t work. We have some decent traverse kits so they will usually measure rounds for any traverse needed to get into areas but they are learning fast to measure rounds to bs fs and known control point or prop corners we recently shot. And so they have slowly developed that eye for having ties and a good network pretty fast and identifying in the field now when something was bad and getting me that extra ck. At first it was a bit slower as they had to re think a bit but now they just abhave it down. My LS is still getting use to this as he has been a loop traverse guy and compass rule. So it has taken some time to prove to him how intergrating data and redundancy actually can be a better way a lot of times. The Trimble processor gives me an additional ck as well it takes no more time and such as well. So much power at our hands it’s amazing to me.
-
My LS is still getting use to this as he has been a loop traverse guy and compass rule.
I still see this a lot, and I’m not a fan personally. Does it work well enough for most people most of the time? Sure. Can’t deny that.
Me? I want everything double determined at a minimum- be it from two different total station control points, total station + GNSS, or double occupied GNSS (although this probably isn’t the case if we’re working in downtown LA… can be hit and miss). 95/100 times you won’t see much of a difference. 4/100 times you’ll see a difference but it won’t have a significant impact. It’s that 1/100 that I try to account for when doing control- any type of control, really. You never know when you’re recycling control/monuments to use in another project.
Log in to reply.