You OPIE/ORGI guys are raising so many interesting questions its hard to know where to begin comments. Here is a start on a question that Shawn raised about why the cycle slips look different on different plots. The short answer is that the computation of coordinates using carrier phase observations is normally done using double differences. If you use double differences to look at residuals and there is a cycle slip, ie the receiver cycle counter "slips" so the recorded cycle count over the interval between two measurement is more or less than the true cycle count the double difference residual plot will show an offset between the residual of the measurements before the slip and the residuals after the slip. The offset, in centimeters, will be approximately equal to the number of cycles that the counter slipped multiplyed by the wavelength of the L1 frequency. This type of offset, occuring whenever there is a cycle slip, gives the type of residual plot that you mention that looks life a jack-o-lantern's teeth.

But a way often used to automatically locate cycle slips is to employ what are known as triple differences. In this case the residuals will show up on triple difference residual plots as spikes associated with the interval during which the cycle slip occured rather than as offsets. Usually triple difference solutions are used to locate cycle slips and fix them, then the final solution used to get coordinate differences is done using double differences.

Cycle slips can be fixed by using the fact that the error in residuals, in centimeters, is known to be an integer multjplyed by the L1 wavelength. With user software this is usually done automatically by the reduction program which "looks at" either double difference or triple difference residuals from an initial solution.. But it can be done by hand if the software allows it, a messy and thankless job.

Unless the data is extremely noisy fixing of integers can usually be correctly accomplished so long as there are observations at every measurement epoch. But, if there are a number of measurements missing in the middle of the observations of a satellite, correctly fixing a cycle slip that occurred between observations several minutes apart is an iffy proposition. A common practice in reduction programs when there is a substantial gap in the observations of a satellite by a station is to avoid the problem by treating the observations before and after the break as if they were from a different satellite. Since one always solves for the number of whole cycles for each satellite on the first observation epoch, the so called initial integers, this sidesteps the problem. J. D. mentioned taking data out of the middle of observations of a satellite sometimes caused a solution to blow up. The cause of this might be that the automatic cycle slip fixer could not correctly fix a cycle slip across the data gap that was left and the gap was not large enough to cause the software to treat the observations after the gap as if they were from a new satellite.

Of course, since I don't really know how your software works there could be some other explanation for why the solution blows up.

Mr. G,

I think you answered the question I had concerning the removal of a small segment of tome from the middle. Segments of up to 15 minutes could cause a major problem. But, these were also during lengthy segments of time where only 4 common sv's were logged. It would make sense that if the data after the trim for that sv were to be incorrectly fixed, the solution would be weak. It would be great if you could analyze Ashtech Solutions 2.x software.

I haven't finished with the L1 only experimentation of O.R.G.I. All my processing has thus far been with AS2.5 and L1 only. It is difficult to qualify the results at the moment without having fully acceptable coordinates on the "POST". I would hope that when we finally get a dual frequency position from multilpe sessions on this point, adjusted to both the same 5 CORS stations, and OPUS, we'll have an acceptable target for comparison. Your thoughts?

Thanks

J.D.

J.D.:

For what it is worth, isn't one possible problem with the exercise how you get to NAD83 from ITRF? Doesn't OPUS use NAD83 positions for the CORS that are not the best current estimates and then adds the residuals due to that effect into the net estimate of the positional uncertainty of the unknown point processed in OPUS?

Have you examined the CORS coordinates to make sure that the NAD83 velocities published for all of the CORS points that you'll be using are nearly the same, that their present relative positions to each other are essentially identical in the NAD83 reference frame as they were at the epoch for which their published NAD83 positions were derived by NGS?

It still seems to me that it would be worthwhile doing the ORGI/OPUS/OPIE comparisons in ITRF so that the small residuals attributable to the ITRF-to-NAD83 conversion did not enter into things.

I realize that in practical work one wants to end up with NAD83 positions, but isn't the first question really what is the real precision of the L1 positioning? The second and separate problem is how to derive the NAD83 position of the station sought.

Best regards,
Kent McMillan, RPLS Austin TX
Modified By Kent McMillan on 12/17/2001 at 1:09 AM

Whoa....

I agree that the ITRF correction is entirely a valid process. I want to see it in play here as much as you. I'm just still excited that "Phase 1" of this project seems to be a success... actually producing repeatable coordinates from stations 124-181 miles away with L1 only.

If we can all agree that part of the experiment is successful, I'm game to tweak this thing as far as possible.

I did briefly look at the velocities of the CORS stations when you brought up the ITRF issue during Test 1 or Test 2. They did all appear to be within a fairly small range, but I'll have to pull out my notes to verify that.

No disagreement here regarding the ITRF suggestion. I'm just wading through this one hurdle at a time.

J.D.

J.D.:

I'm not criticizing. It is just easier for us lazy folk to offer suggestions from the stands than to get our own hands on the problem.

Best regards,
Kent McMillan, RPLS Sloth TX
Modified By Kent McMillan on 12/17/2001 at 1:22 AM

I'd like you to take a fling at the Locus files and run the numbers. Just keep in mind, all I have been trying to establish is the fact that L1 only can give repeatable results. I'm still not sure I can claim victory on that with only 3 comparable test sessions.

I think we're on the verge of being able to implement some type of "homegrown" procedure to bring reality to the longings of Deral Paulk and Kent McMillan from several months ago. Seems Deral first uttered the moniker "Opie", followed by Kent suggesting the full blown "OPIE" program. And seems there was something about "Aunt Bea" in there too.

If you're game, I'll email you the Test 1, 2 or 3 files (or all three if you want) for your analysis. I'd appreciate your evaluation if you have the time.

We really need to have an OPIE/ORGI meeting sometime to put all these ideas together.

J.D.

constantly bumping into the walls of life

J.D.:

Sure, if you'll send the data in RINEX format, I'll undertake to process it in ITRF to whether that makes the results look as good as I think think they will. I do expect a significant improvement or I wouldn't be agitating for ITRF.

Best regards,
Kent McMillan, RPLS Austin TX

You've Got Mail

j.d.

Wonder if Phil could talk to someone and get you the use of a loaner dual frequency blue box to use for the OPUS test...

Also would need to get Dave Doyle to find out how to submit 8 or more hours of data. The OPUS site has a maximum amount of time that you can submit. They might have to overide a setting or do it off line...

What's the chance of doing one of Phil's common standard of practice checks...Set up another receiver (at the same time as POST) on a pin 200'feet or so away, so we can also validate our point-point ground accuracy.. Compare the results (before processing between the points, calculated as it were) versus a direct measurement...Wouldn't have to be a POST, just a pin with the tripod over it for a one time session...
TM

I'm not planning 8 hours of continuous dual frequency. I had considered 3 four hour sessions though, on different nights. Say first night 7-11, second 12-4, third 6-9 (CDT). All three sessions could be processed independently using the same CORS download method (and identical stations), just for comparison with the "non-ITRF shifted" L1 results. And for the real comparison, 2 or all 3 of the four hour sessions could be submitted to OPUS for processing. Lot's of possible scenarios.

I also like the idea of two simultaneous points. Would be very interesting indeed.

As for the "blue box loaner", that would be nice. I do think a more fair assessment of my results thus far would require a loaner L1/L2 unit, loaner software, and a loaner data processing expert with dual frequency knowledge. Three of the things I seem to lack. I could run the unit, do the number crunching etc., but even I wouldn't accept the numbers if they were too close to my L1 numbers for fear of some subliminal bias creeping into the process. I'd really prefer a totally independent set of data for which I could have no possible influence on the outcome. I could run the unit sessions though.

J.D.