Different location baseline with postprocess gnss vs locus processor ?? help me!

Is there any brave to tell me what to do ??

It's not bravery... It's that autonomous, vs tied to a NGS marker difference.
Probably 2 autonomous solutions being compared.

N

If you did not constrain your processing in GNSS Solutions to the same location as the Locus Processor Solution took, then that would explain it as Nate said.

Nate The Surveyor, post: 432895, member: 291 wrote: It's not bravery... It's that autonomous, vs tied to a NGS marker difference.
Probably 2 autonomous solutions being compared.

N

Excuse me, can you explain your answer?

JerryS, post: 432896, member: 205 wrote: If you did not constrain your processing in GNSS Solutions to the same location as the Locus Processor Solution took, then that would explain it as Nate said.

Excuse me, can you explain your answer?

The earth does not submit itself easily to a mathematical model. (a quote from Shawn Billings)

When you use GPS, you have a tool. This tool will allow you to USE a "Here" position, which is typically within 10 ft horizontally. IF you have a cluster of Locus up, and you HOLD the one place fixed all throughout the job, all will "LOOK WELL". But, in fact, that whole job is typically within 10' horiz.
UNLESS you go to a local USGS or HARN network point, and constrain the data to a datum.
This means that the whole job can fluctuate, around, be be an intact unity.
Why don't you call me, or someone else. This is PRE-K GPS material.

Num is in profile.

N

I'm confused. Raw measurements. Deltas. Verify with a total station. Verify with a steel chain. If one of them doesnt match the other two, then figure out why. Likely the GPS...

It sounds a bit like your Locus solution was based on static data from the units sitting there long enough to fix and as Nate says you had an 'autonomous solution'. That is one that the Locus (GPS) has derived from accepting a mean of all good observations for each Unit and deriving a position that is 'approximate' only. The vectors between your setups are okay, just they're all out of true position (based on some known grid datum) by it seems 2 metres plus or minus.
Then when you use another modern GNSS system tied to or constrained against a known Datum you have the difference you are referring to.
That's what I assume has happened.
Originally you had what we also call a 'local datum'.

The old baseline vector relative dX dY dZ

A vector between antenna may not have a useful coordinate. It's the ECEF delta that is the measurement;

Think of it this way, you setup a receiver on a point and turn it on. You let it sit there long enough and tell it use it's position, it is basically throwing a dart at a dart board after having a few drinks, you might hit the board, but most likely not the bullseye. You have to determine the true coordinates for your base point or you are floating in space.

Do this experiment: Set up 2 locus units, some 100' apart, leave them up for 2 hrs. Download their coordinates. Then, do it again, BUT start a NEW file, with a RE-observation, of the SAME 2 points.
You will find:
The brg and dist between the 2 points will be nearly the same, for BOTH FILES. BUT, the location of the point on earth, will have changed by a few feet.
You can do this all year long. This data will be ok, as in the brg and dist between will be good. BUT, the location of both points will be different.
You are asking WHY. Well, lets START with the point that it is FACT. Then, we can go on to why.

I am seeing new GPS users, setting up their BASE on the SAME point, 3 days in a row, with a "Here" and they cannot figure out why the whole job has shifted, from Day one, day 2, and day three. You HAVE to constrain them to the same point. And, until you tie into a source of REAL coords, that's all you can get.

ca pasa, senior?

Until you fully believe this, you will have a hard time moving on, to the reasons WHY.

N

If your Locus data are processed in both software using the same file as the reference (or base) file, then it is my understanding that the autonomous position of the file should be the same in both because the reference position is based on the first fixed position the receiver determines. If for whatever reason, you specified the other data file as the reference (or base) file, then that would account for the difference in the positions.

A GPS baseline is a calculated difference between two GPS XYZ positions. It is a 3D vector that should not change, no matter what processor is used, yet you are reporting that it has. Most likely something else has changed such as the satellite ephemeris that fixes the satellites positions in the sky. Also your Locus processor may have determined some atmospheric correction that may be different from that calculated by a multiple wavelength processor such as GNSS Solutions.

While that 3D vector should not change, what your processors say about it may change. A 3D GPS vector is fairly useless until one end of it is constrained to a known point on or near the earths surface, that is place it on Datum. Typically this is your raw solution and raw coordinates. These coordinates may be fairly close N-S and E-W but height wise they can be off in the range of 100s of meters. Those raw values can be greatly improved simply by fixing one end to an elevation that is derived from a topographic map if no other information is available.

Yes, elevation, and that includes antenna height, is important. I saw surface vector distance errors of that range many years ago in an L1 only network, caused by the fact that I had multiple occupations on the same fixed ground points and had errors in the antenna height entries. My input warped the data output.

Recheck your input and re-explain to us in more words, your use of the term "baseline".

Paul in PA