![trimble survey controller and epoch 35 trimble survey controller and epoch 35](https://www.xpertsurveyequipment.com/media/catalog/product/cache/1/image/800x800/9df78eab33525d08d6e5fb8d27136e95/t/r/trimble_ranger-x3196-07-10-2020-07.jpg)
The one thing that I don't like about TBC's adjustment is that I can't set different values for the standard errors for each individual setup - I have a couple networks that contain CORS, sessions on 2.00 and 2.25 meter fixed heights, and sessions on tripod / tribrach. This generally results in a pretty reasonable number for the Chi square test on the first pass. The only setting that I really change from the defaults is the standard errors, I usually set the V to 0.007' and the Hz to 0.01'.
#TRIMBLE SURVEY CONTROLLER AND EPOCH 35 FREE#
As Dave said, you only need one, and on a point that is not a control point the class should be Unknown.īe aware that if you perform a free adjustment the coordinates of your unconstrained control points will change - make sure you clear the adjustment results prior to constraining them. Project Explorer is your friend - expand the points in question and see what you have in the way of position records. The flags you're seeing are probably because you had points with autonomous coordinates that came in as Control just delete or modify the coordinate records and recompute. I've seen compelling arguments on both sides of the trivial baseline fence, but I agree that keeping vectors between CORS adds a false confidence level to the overall data set. I generally process the baselines between the CORS just to make sure there are no problems with the positions or the data, but if I'm removing trivial baselines those are the first ones to go. I did this in TGO too, though at least in TGO you could specify flowout if there's a way to do it in TBC, I haven't found it. I don't have to worry about flowout that way. that's the reference frame in which the precise orbits are computed and 2. The reason I use OPUS IGS08 seed values is twofold: 1. The adjustment process is a whole other ballgame - I generally use Star*Net instead of TBC - but that's where I change reference frame (if necessary) and start introducing constraints. I do process CORS to CORS, I just don't worry much about them. The "trivial" thing doesn't seem significant to me (that's kind of a pun), and with large numbers of receivers out it's a major pain to disable, especially in TBC (it was easier in TGO).
![trimble survey controller and epoch 35 trimble survey controller and epoch 35](https://geospatial.trimble.com/sites/geospatial.trimble.com/files/inline-images/Trimble_TSC7_Studio_Front_GNSS_Module_73426_FavoritesScreen.png)
I don't bother disabling any vectors anymore, unless I have reason to believe there's something wrong with them. Enter OPUS-derived IGS08 positions for all stations into TBC ("add coordinate") as control quality.ģ. Submit all observed files to OPUS-S or OPUS-RS.Ģ. My workflow for static processing usually goes about like this:ġ. My apologies for the long post, just trying to provide enough information up front. Is this normal with multiple CORs being processed or does something need to be done prior to continuing with the network adjustment? All of the baselines processed successfully, but all of the stations are flagged as failed with points being out of tolerance up to 10 feet. So far I’ve processed both the static and CORs baselines together. Should all of the baselines between the CORs be treated as dependent (trivial) and be disabled? Should the static and CORs baselines be processed separately? Should we constrain to control prior to processing the baselines? I’m thinking this would be done after the baselines have been processed.
![trimble survey controller and epoch 35 trimble survey controller and epoch 35](https://is1.ecplaza.com/-H4_i8iywNCCr9aK0ZSvBRqFo4U=/fit-in/200x200/filters:fill(white)/is2.ecplaza.com/ecplaza2/products/d/df/df5/737492734/trimble-4700-base.jpg)
Are there any non-obvious project settings that could create bad or false results?
![trimble survey controller and epoch 35 trimble survey controller and epoch 35](https://i.ebayimg.com/thumbs/images/g/7qYAAOSwmBthOQNK/s-l300.jpg)
Final elevations will be per a precise leveling run holding a published benchmark.Constrain the network to published 1991.35 epoch based on the field ties to the existing ground control stations.Adjust the network constraining to the CORs at the published Epoch (2010).Process the baselines - Includes running baseline processing reports, loop closures, and disabling dependent baselines.The processing will include the following steps: Static data includes ties to existing control stations and to newly set control stations. I have done this using LGO (several years ago), so I understand the general process. I’m working on processing a static GNSS survey control network in TBC (v3.61).