I can not express enough how glad I am that Ashtech included the ability to cleanse data that would otherwise have poor results. But with this new ability comes a need for better understanding of the results. One could easily wash too much from the processing data, come up with low residuals and error estimates but have poor solutions because even the fringe data added to the closer solution.

At this point I use the PDOP of the solved vector as a sign of too much data cleansing, but this is only an assumption on my part as to whether I have removed too much data or not.

What are some things to look for in data washing to prevent clipping too much. I would think a valuable tool would be to have a PDOP plot (similar to the residual and s/n plots) for the entire vector time span.

Shawn

One thing to watch out for is the number of satellites used in the vector solution after data cleaning has been done.

For example, if only 4 satellites remain, there is no redundancy in the vector solution -- the RMS estmates are not as reliable as they would be if there were at least 5 satellites used. With today's GPS constellation, 5 satellites not be too hard to achieve in most situations.

At the adjustment stage, a minimally constrained network adjustment on a GPS network with independent vectors is a good tool for detecting biased vectors. A constrained adjustment is another good tool as it verifies how well the GPS measurements fit the known control in the survey area.


Richard

Thales Technical Support

See my comments below which I was posting when this message came up.

Thank you both.

Richard, your comments make a great deal of sense.

Mr. G, you mention unknown cycle slips in the processing. What is the best way to deal with cycle slips (those that can be identified)?

To both (and anyone else) what should the cycle plot look like? We observed a substancial difference between the CORS plots and the Locus unit plots. I say substancial (I really don't know). The Locus unit seemed to have very small evenly sized spikes and inverted spikes that overall made a parabolic line throughout the session. The CORS looked more like (as Dad put it) a bucked tooth jack-o-lantern, more or less having a stair stepped pattern that at times (depending on the station) seemed very irregular. The stair steps may descend for a few epochs and then suddenly ascend. The plots may be Ashtech specific so I don't know if authorities on GPS processing not familiar with Ashtech s/w will be able to relate to the AS2.x display.

Additionally, I am unconvinced that removing an otherwise healthy satellite or parts of it due to residual plots is safe. It would seem to me that even if the data is more deviant from one or more s/v's that it could still be imperative to rounding out the solution. This is why I bring this up. I am very interested to know what data immediately qualifies for removal, what data should be considered for removal, and what data should remain. The adjustment analasys is certainly a great way of detecting problematic vectors.

Dad has been very successful, it would appear, in adjusting the elevation mask for each vector, customizing it to process with the lowest error estimate. It is rather amazing at what a one degree change in mask will do to the residuals. In his CORS experiment (O.R.G.I.), he has found that a mask between 18 and 22 degrees immediately lowers the error estimates and still maintains a suitable number of satellites and low PDOP. We can only attribute this phenomenon to ionospheric delays (which of course are very deconstructive to favorable L1 processing).

Shawn Billings
SIT Texas