For those just joining the program...
Previously I had inquired about the use of the LOCUS system for sub-meter positioning. After our first failed attempt at pk I realized that the receiver was capable of producing consistent sub-meter positions on our known control with 5 min observations. The software (v1.2) though reported residuals in the range of 10-20 feet so I had no reliable way to know that the points were indeed submeter. Does the new version (2.x) allow for processing of code only?

Shawn

Solutions/Locus doesn't support code only processing, but whay would you want to when you have the phase data? You can use much shorter observations if coarse (1-5m) results are OK.

I think I am making a dummy out of myslef using the wrong terminology. What is the technique that gets to the 50 cm level?

Thanks
Shawn

I'd just use short static obs., 5-10 minutes depending on length of line. You'll get a float solution, and it'll be flagged as "failed", but the solution will be valid within the error estimates of the solution.

In your opinion (and I promise not to write this down, try it, and call Ashtech demanding to know why it did not work) what would be a general time frame for <5km to get a good float solution. (I feels kinda funny saying a good float solution as this is the surveyors enemy.) I just want a rough idea to test it. It would appear that <1km, 5 min will come very close if not give a fixed solution. I would like to use this 50 cm technique to pickup creeks and lease roads and other rough topo, but it would have to be at least as fast as 2 guys can do conventionally (which might not be too hard to do in the "deep woods"). I made a mistake in saying that the residuals were out of range in v1.2 on the float solutions. I was looking at the vector analysis (which was really ugly 10-20') as opposed the the adjustment residuals which reflected 1-2 ft (float solutions).

Thanks,
Shawn

Brian,
In case you couldn't tell, I'm having a ball figuring out just what these things can do. Thanks for going down the trail with me.

I don't really have a feel for occupation times at that accuracy level. I guess you'll have to do some experimentation.

Brian,

The ashtech reliance processor can take a 30 second L1 code and carrier observation and process to a "decimeter" (less than 1') level accuracy. With reliance, not much in the way of initialization or reinitialization is required, and it works great in moderate vegitation.

I've tried what shawn is suggesting in the past, with Locus, and got the same results. The processor reported accuracies in the 5 to 10 feet range, with 5 minute static obs.

I've wondered why reliance can get 1'+/- out of a 30 sec obs, and locus can't get 5' out of a 5 minute obs.

The obvious answer is that the Locus processor is designed to either get high accuracy/precision solutions, or die trying.

I'm not an expert (by far), but I'm assuming that the two processors are using different routines to solve for positions. I think Shawn's orignal post was asking if v2.0 would include an option that allows the "GIS" level accuracy with locus, with no initialization, and very short obs.

-Greg
Modified By Greg Shimp on 7/21/2001 at 12:18 PM

Greg,

You did a much better job of presenting my question than I did. My question is can we get 1-2' accuracies out of Locus with short obs and no concern for lock issues?

Shawn

Greg,

I am well aware of what Reliance can do. Reliance and Locus were developed and optimized for different tasks. This is always a tradeoff. In making Reliance perform better under canopy, its performance at the cm/mm level is degraded. In optimizing Locus for accuracy, the canopy performance and decimeter-level performance is degraded. While it's possible to make a single product that would do both, it would make both the receiver and software much more difficult to use, as the user would have to change quite a few parameters. One of the primary goals was ease-of-use for both, reducing the need for training and tech support. Of course, this will always have a cost (in terms of flexibility).
Modified By Brian D. Ewing, PLS on 7/23/2001 at 9:22 AM

Brian,

Thanks for the explanation. This makes sense. So now all I need to do is talk Dad into a Reliance receiver, right?

Shawn

J.D.,

I swear I had nothing to do with Shawn's conclusions. ;-}

---Brian

Brian,

For a point of clarification, is the difference in the hardware or the software?

I've always thought that GPS recievers are basiccally the same thing, i.e. an instrument that records the signals sent from satellites. With that in mind, it would seem that the primary difference between the results obtainable with Locus and the results obtainable with Reliance would be in how the software reduces the observation files.

A year or so ago I tried to figure out a way to process Locus B, D & E files in the reliance processor. It's been a while, but I think the D file was the major hang up. The D files from both system look similar, but I guess they are different enough that Reliance won't process it. I always got the "Invalid D-file" error message, I think. I even tried modifiying the locus D file to look more like the reliance format, but it didn't work. Someone who knew what they were doing (i.e., not me) probably could get it to work, though.

Too bad ... having that 2-in-1 capability would have been nice.

-Greg

Greg,

I seem to recall in the list of features that the ZXtreme is capable of the 50 cm measurements to which we refer (I have no idea what these types of measurements are called). Seeing as how the Solutions processor is designed to process the Locus and the ZXtreme I would think that if it does not work in Solutions that the "problem" (quoted because as Brian indicated it was a choice to make Locus more accurate and less robust) would be in the hardware. I suppose only experimentation will tell. I'm about experimented out though...well at least until next weekend.

Shawn

Greg,

It's not just the PC software, the receiver firmware is using different parameters. Also, the respective D-file formats are different. This can be overcome if you want to do a lot of manual editing.

Shawn,

The Solutions processor is intended for surveying; it's optimized for the best possible precision, but won't do as well as the Reliance processor for lower precision under difficult conditions.
Modified By Brian D. Ewing, PLS on 7/24/2001 at 9:32 AM

Hey,

I figured it out.

Shawn is just trying to get out of the brush cutting. Ain't gonna happen.

So much brush, so little time.

J.D.

So, you gonna take away his Locus and give him a brush hook? ;-)

Brian

J.D.,

I think the technical term would be "multipath mitigation".
Dave