Topcon and Star*Net concerns when processing large networks.

I use Trimble Business Center rather than Topcon. But the concept is the same. 

I load static (from TBC) and RTK (direct from job file) baseline vectors (and conventional observations) into an access database (unique to each project). Before I started my own company I worked for a local survey company that did most of their work in a 10 county area. Little by little I built up a regional network and had to deal with problems like duplicate baselines, duplicate names, etc.

In access you can sort by any field, and run queries to detect duplicates. So that is one way to do it. 

Just as a reality check, I disabled a single RTK vector in a 75-station project I did a couple of years ago, and it reduced the reported number of observations by 1 (254 versus 255) as expected.  So there seems to be something particular about your project that's causing the obs count to get out of sync with the vector data file.

Can you clarify...is it a truly "duplicate" vector (i.e. same baseline, same data, same time), or a repeat baseline (same two points but observed at different times/days)? You definitely want to keep the latter. The duplicates you would want to get rid of, because they add false redundancy. 

@john-hamilton 100% duplicate, down to the nth degree of a millimeter. just my thought, no bueno for mis-weighting the model

One advantage of bringing the baselines into access is that when I export from there I include the UTC start time, end time, and some basic stats  (precisions)

G0 '1 H Prec:0.010 V Prec:0.02 Epochs:184 Day:279 10/06/2025 15:59:56 to 10/06/2025 16:03:01
G1 PRS36798909111-25047E 22107.3513 2531.9722 -825.4832
G2 44.302774770000E-06 23.755955044000E-05 89.499146270000E-06
G3 -54.287436800000E-06 22.225141950000E-06 -00.000088259745

When Star*Net imports a vector file it includes the timestamp, so identifying duplicates is possible with a bit of simple coding.

@jim-frame Good morning Jim. We use static for our GNSS network observations and repeat observations. The vectors exported from Topcon software consist of: vector number, from station, to station, DX, DY, DZ, XX, XY, XZ, YZ, ZZ, XZ (with the last four being the VCV matrix). The export is called a Topcon Vector Format (.TVF) file to be imported into Star*Net.

Regrettable to think that Topcon's technical service is not very responsive, so it's probably a headache I will have to learn to live with.

Yeah, I should have qualified my statement to the vectors I have experience with.  I get timestamps with imports from TBC (*.asc), and my Javad TLS writes the Star*Net *.gps file directly, including the timestamps.

A clarification...when the OP said "large" networks, I was assuming that they mean a lot of points, not a large area. Once a network becomes large in area, the ability of Star*Net to properly model it degrades. I am not sure what the cutoff is, but when I have networks covering a large area, I use Geolab, which has no "area size" restrictions. I like the output from Star*Net, so that is what I typically use, especially for conventional network like a deformation network at a dam, or leveling, but also small in area GNSS networks (like a single county). 

Some of my work is as large as 20,000 sq miles or even larger, sometimes a whole state. 

From the Star*Net v6 manual:

"STAR*NET is designed for typical survey grid projects in relatively small areas
spanning up to a few hundred kilometers, the extent of a typical grid system. The
program cannot be used to adjust survey observations in a single project that spans
thousands of kilometers or miles, covering multiple grid zones."

Posted by: @moe-shetty

↑

@jim-frame Good morning Jim. We use static for our GNSS network observations and repeat observations. The vectors exported from Topcon software consist of: vector number, from station, to station, DX, DY, DZ, XX, XY, XZ, YZ, ZZ, XZ (with the last four being the VCV matrix). The export is called a Topcon Vector Format (.TVF) file to be imported into Star*Net.

Regrettable to think that Topcon's technical service is not very responsive, so it's probably a headache I will have to learn to live with.

OMG  I was looking for some heady math to learn... and my bosses said trig. LOL

I know trig to 270 degrees for a triangle 🙁 

I was thinking photogrammetry adjustments.. but wow. DX, DY, DZ, XX, XY, XZ, YZ, ZZ, XZ  missing a couple Ys i think but that's the math i want to learn. I some how missed matrices in school is this that? Your derivatives then XX, XY, XZ, YY, YZ, ZZ. IDK I am guessing. Same principle but with GNSS it adds the Z?

What do I need to read to understand that?

Posted by: @tnt

↑

What do I need to read to understand that?

Variance-covariance matrix

@jim-frame 

Fortunately it is not really necessary to understand that bafflegab. The software and its writer understands it so you don't have to. Just understand that it is what it is and that it is there for a reason.  

Posted by: @norman-oklahoma

↑

Fortunately it is not really necessary to understand that bafflegab

Agreed, because stats isn't my strong suit.  But for a project last year I had to learn how to convert correlations and standard deviations to a covariance matrix.  I slogged through it just long enough to write the code I needed, and no longer remember how to do it.