Compute Inverse

Perhaps the systems have different scale factors.?ÿ

I would say that one is ground, one is grid or geodetic, but over that short distance you would have to be at 63,000 foot elevation (minus whatever the grid scale factor is). So not that. So my other thought would be one is a slope distance. Or you did a calibration and got some totally whacked out scale factor.?ÿ?ÿ

Agree with John...

Pretty much has to be a "slope distance" or a totally whacked "calibration."

Of course to err is human, to TOTALLY screw things up requires a computer.

GIGO

Loyal

Maybe your data is being scaled once in the DC and again in Carlson? If this is GPS data, maybe post process the vectors for an independent check on the solutions?

Yeah, I'd guess slope distance on one of them.

I'm with the slope distance v. horiz. distance crowd.

BTW - it isn't really enough to say that you are using a TSC3. That is just a device. It's the software the device is running that is really key.?ÿ ?ÿ

?ÿ

?ÿ

So here's an old timer's question.

What is the correct answer?

Sounds like you have two coordinate pairs, it's simple to calculate by hand.?ÿ

Try changing your cogo to grid or ground.?ÿ

Many different length types between two points. These images from: https://geodesy.noaa.gov/library/pdfs/NOAA_TM_NOS_NGS_0010.pdf

Another possibility is that "you" (the two different computers) are mixing zones.

Data collector in one zone, desktop/laptop in another.

Just say'n

Loyal

Posted by: @mightymoe

So here's an old timer's question.

What is the correct answer?

Sounds like you have two coordinate pairs, it's simple to calculate by hand.?ÿ

My thoughts exactly, and I'll take it a step further. Take a look at the coordinates in each device to see of they are the same or not. If they are the same, then one or both of them is doing something odd with the inverse. Compute it by hand to see which is screwing things up. If they are different, then one of them is making some sort of a translation, which would merit further investigation.

I for one really hate that much of our software is designed to "fix" things for us like changing coordinates from us feet to international feet based on some obscure Metadata setting, without telling us that it has made the change. It takes 5 clicks to delete a file, but we can move things without trying. Rant off, preaching to the choir anyway. 😉 ?ÿ

@david-baalman

There's no substitute for eyeballing the data. Just to add to the scale factor consideration, one does not have to be ground and the other grid, the two systems just have to be using different scale factors.

Consider this. Suppose the desired scale factor is 1.0015 and one of the two systems uses the reciprocal of the scale factor instead of dividing to get ground from grid. Both have 1.0015 as the scale factor, but one system uses 1/1.0015 = 0.9985022 for its calculations. 

The ratio of the two results will be 1.0015/0.9985022 = 1.0030023, which is very close to the OP's result. The scale factor that hits OP's numbers exactly under this scenario is 1.001499681.

Anything's possible,right?

I ran into the same situation about three years ago. Ran it by the Community, but never got an answer.

My situation was Survey Controller on a TSC2. Compared the inverses between the TSC2, AutoCad LDD, and an HP41 calculator. I got three different solutions using the same coordinates. The TSC2 solution had the biggest difference so I quit trusting it's solutions. Haven't checked out my current TSC3 to see where it stands.

Is this a GNSS or "Total Station" project (observations).

IF were are talking about a GPS/GNSS situation, then the SIMPLE solution, is to export the Latitude, Longitude, Ellipsoid (or orthometric) height for these (or ALL) points out of the TSC3 (which SHOULD be a piece of cake).

Compute the (your zone) State Plane Coordinates of the points in question (I would use the NGS software to do this), and follow the yellow brick road from there.

The NGS "tool kit" has EVERYTHING you could possibly need to sort this out.

Loyal

I do not know about the TSC3 but Carlson SurvCE has a 2D and a 3D solution to inverse.?ÿ The 3D version will give you a slope distance, horizontal distance and an elevation difference with an azimuth.?ÿ You get some really wild solutions if one point is at 0.00 elevation and another point is at a real elevation.?ÿ I would guess given the numbers in your example that it would be a slope distance vs. horizontal distance not a scaling issue.

If the OP would be good enough to post the elevations of the 2 points we could quickly determine if the difference was due to slope/horiz distance.?ÿ?ÿ

A couple obvious checks

1 are the coordinates for points 100 and 1001 the same in both software??ÿ

2 are the state plane zones the same in both??ÿ

a scale factor of 1.0034 is twice as large as any I've encountered, even in central Montana.

Slope distance vs horizontal distance settings seem to be the logical explanation.

But still what is the correct answer Carlson or Trimble? So which one did it correctly?

It's always important that your DCs, computer software, and hand calculations all match. If not you are doing something wrong.

?ÿ

Look under TSC3 "Cogo Settings" there is a grid or ground option.?ÿ Your data will store grid coordinates if set up correctly, but still report ground scale inverses (if set to "ground").?ÿ Handy if you're in the field doing boundary work.

As others have said, though, that is quite a large scale factor - OR - the points in the DC do not have true vertical values.?ÿ If they're computed points and have a placeholder elevation of -9999 or "0" you'll get an incorrect ground scale applied via the cogo setting I mentioned above.