StarNet Antenna Heights

My vectors are mark to mark, already reduced by the baseline processor, I think?

[pre]
G0 'V1 PostProcessed 09-DEC-2014 17:01:14.0 jackson dsf-ppbaselines_2015-02-02.asc
G1 2003-2002 3132.914300 2001.946400 4700.296400
G2 8.877889195000E-005 1.839964388600E-004 1.890452113000E-004
G3 1.233659859300E-004 -1.259902928700E-004 -1.833735004800E-004
[/pre]

> My vectors are mark to mark, already reduced by the baseline processor, I think?
>
> [pre]
> G0 'V1 PostProcessed 09-DEC-2014 17:01:14.0 jackson dsf-ppbaselines_2015-02-02.asc
> G1 2003-2002 3132.914300 2001.946400 4700.296400
> G2 8.877889195000E-005 1.839964388600E-004 1.890452113000E-004
> G3 1.233659859300E-004 -1.259902928700E-004 -1.833735004800E-004
> [/pre]

Yes, the typical Star*Net GPS vector format is mark to mark. That's what I use, although I can see that having the ability to fix a mistaken antenna height would be worthwhile.

Thank you both for the replies. What I am seeing is an additional entry on the G1 line. It's one of those "use it if it's here, don't panic if it's not" things.
The entry created by the converter is '2.111/6.927'. This is supposed to be the mark to phase center height of the base and rover. Pretty handy when you have more antenna types than employees. The converter fails to convert the rover height to meters. It's an easy 'find/replace' so no big deal, until you discover it is assigning the same phase center offset to every antenna. The concern grows when you determine that NONE of your antennas are 2.111 meters.
This will still be an easy fix once I verify the expected input. I had hoped to validate my experiments by riding the coat tails of others who have blazed the StarNet 8 trail before me. I will be surprised if someone hasn't run into it...
Thanks again, Tom

> This will still be an easy fix once I verify the expected input. I had hoped to validate my experiments by riding the coat tails of others who have blazed the StarNet 8 trail before me. I will be surprised if someone hasn't run into it...
> Thanks again, Tom

Do you have the option on the GPS vector input menu of getting the vectors reduced to mark to mark? That would be an easy check on how the antenna heights are handled, i.e. to add the mark to mark vectors to the adjustment to make sure that both are consistent with each other. (Obviously, you'd remove one set of redundant vectors afterwards.)

Tom,

There are a couple other ways to export GPS vectors. On the handheld (CS15?) export the HEXML file - it will give you GPS vectors grn mark to grn mark. Covariance values are in LLH though. You should also be able to export the ski.asc format which is also grn mark to grn mark - values normally metric and ECEF dx dy dz covariance values have to be derived from co-factor matrix. And lastly if you can load the project into LGO you can go to baselines tab and export as a csv file normally metric and ECEF dx dy dz covariance values have to be derived from co-factor matrix as with ski.asc

These are all dx dy dz to grn mark. I wrote software to cvt all these to StarNET format (with some Leica assistance). By StarNet allowing rover and base ht editing in V8 - I would think the GPS vector would need to be developed at ARP so this is curious and now I'm gonna have to check this out too.

Thanks for posting.

Best Regards,
Terry

Here are the formulas I use in my programs to compute the corrections to an ECEF position (X, Y, and Z) for an incorrect antenna height:

rs("Reduced X") = rs("Proc X") + Cos(latrad) * Cos(longitrad) * deltaH
rs("Reduced Y") = rs("Proc Y") + Cos(latrad) * Sin(longitrad) * deltaH
rs("Reduced Z") = rs("Proc Z") + Sin(latrad) * deltaH

In this case, rs is a database record, Proc X, etc are the original X, Y, Z from the GPS processor, and DeltaH is the difference in HI (processed HI-actual HI). latrad and longitrad are latitude and longitude of the point in radians.

A similar formula can be deduced for the DX, DY, DZ vector components.

Edit: I looked at it for DX, DY, DZ, and here is what I have for corrections to vector components due to a change in HI:

DX=cos(latitude) * cos(longitude) * DHi
DY=cos(latitude) * sin(longitude) * DHi
DZ=sin(latitude) * DHi

> The end of the G1 line has the base and rover heights. The current converter does not convert the rover to meters. No biggy, just find/replace...
I found that the TDS/Spectra Precision converter in v8 was outputting my vectors to feet dimensions. My first clue was that the measure ups were in feet. StarNet reads that G1 line as being in meters no matter what. So you can see the problem. You may have more of a biggy than you think.

I've figured a suitable workaround and have reported the problem to Microsurvey.

I reviewed the Carlson storage options and the StarNet import options. I did not see anything helpful so we went to the controller.
The antenna offsets in the Carlson controller do not match the published offsets. The largest relative difference between any of our antenna pairs is 2 mm. Trivial for RTK in my opinion, but I fixed it and reprocessed anyway. It brought my GPS vector errors down from 1.12 to 1.08.
At this point my plan is to do a simple find/replace on the antennas when I reprocess. I will also document what I've found and send a note to the good folks at Micro-Survey. It appears the only glitch in the Version 8 Carlson converter is the failure to convert the rover rod to meters. The heights issue is in Carlson, and it's not really an'error'. They use a different antenna model with virtually no difference in the end result. 2 mm wont keep me up at night when I know where to find it...;-)