@jbw?ÿ
Thanks. I'm glad it helped.
I was fortunate early in my career to learn some valuable lessons from Alan Akman and Jessie Hummel (Caice Co-Founder and Caice/Electronic Field Book (EFB)/Florida DOT). Those two guys were a huge inspiration to me for wanting to learning the ins-and-outs of how surveying works.
Many aspects of surveying/geodesy are intense:
Learning the concepts? Okay, I'm listening.
Learning the Math? Uh, what did you say?
Learning to code? OMG, have you seen that new TikTok dance?
Wanting to talk about what you do for a living with other people in the same boat because our clients and everyone else outside of our little club don't know anything about what we do? Bingo! That's the glue that holds us together.
There are many in this field (and related fields) that are smart, or know what they're doing, or execute well, or effectively communicate with others. Put all of those together in a single package, and you have a winning combination.
The beauty of these message boards is that each of us is on a path, and no matter how far along the path you are, there are people in front of you and people behind you.?ÿLearning is a life-long endeavor, welcome aboard.
@michigan-left?ÿ I don't disagree with much of what you wrote, but though I'd point out a couple of things in reference to your Star*Net comments:
made it vulnerable to easily using incorrect/outdated "seed" values by missing a step during the recalculate/recompute phase of data reduction, or not selecting the most current .dat file
The new version of Star*Net -- which I only reluctantly bought when my v6 dongle failed -- monitors the .dat file(s?) and pops up a window asking if you want to use the current version whenever a change is detected.?ÿ I find this annoying, but maybe others find it useful.
and the .lst output file did not display a copy of the text of each file used in the sequence of calculations
As you probably know, including observation data in the listing file is a user-selectable option.?ÿ I don't select it, as it just makes the file larger and therefore harder to navigate, and I know where to find the obs data if I need to review it.
?ÿ
Going through all the steps to "turn off" this gps data, or that optical data for testing iterations would drive me nuts.
It's not that big a deal if your data is organized well.?ÿ For small projects it doesn't matter much, but for larger ones segregating data into separate .dat files (e.g. by field crew, by instrument, by date, etc.) makes it easy to test scenarios by just turning on or off selected files.
Star*Net aside:
But since you have Trimble hardware and the software, I encourage you to get more comfortable with TBC for data QA/QC and LSA. Once you get the hang of it, I think you'll discover it's a cleaner, easier, and smoother process.
I think this makes sense for most shops.?ÿ I'm not a big fan of Trimble optical gear, and as a small operator their business model doesn't work very well for me, so I run GeoMax and Javad (except for the occasional campaign network, in which I still use a bunch of Trimble 4000SSi receivers).?ÿ For pure GNSS projects I adjust in TBC, but for terrestrial and GNSS/terrestrical combinations I use Star*Net.?ÿ I'd like to try TBC with terrestrial data just to see what it's like, but I haven't yet figured out a good way of getting my SurvCE data into a Trimble-digestible format.?ÿ Maybe someday I'll get around to writing a converter...
