I assume the same requirements as far as maintaining lock or reinitialize as the PM2?

I think it will be better. Partly because of the PM3 and partly because of the GNSS Solutions Software.

The PM3 can reportedly maintain lock better, and, with WAAS, it can fix integers faster (read faster reinits on unknown points or OTF).

The GNSS Solutions will process forward and backward, so if you lose lock and then regain it and maintain it for a long enough time after it could fix on the backside. So, say it takes fifteen minutes to initialize where you are. If you lose lock at 3:00 and then regain lock at 3:02 and maintain lock until 3:17, the points collected from 3:02-3:17 will be fixed.

I wouldn't use this as a guaranteed method for reinitialization. What if you unintentionally lost lock at 3:05? All points between 3:02-3:05 would be lost as float. But I would like it for insurance if the reciever missed notifying me of a loss of lock. Maybe I'd lose a point or two, but because of the reverse processor, I wouldn't have to lose everything between the loss of lock and the "forward" amount of time to regain my fix. So I wouldn't lose everything from 3:00-3:17.

Personal experience with Stop&Go has always been that the base is within a couple thousand feet - normally within a thousand. Realistically, you should be able to reinit (OTF or unknown point) within 10-15 minutes with a PM2 at that range. I would guess that the PM3 will be around 5-8 minutes in that distance. That's not bad.

Hopefully that's all clear as mud. :)

The PM2 and A.S. can process S & G backward too.

According to who or what, John? Phil seems to indicate this is new to GNSS Solutions. (The receiver has nothing to do with it).

Maybe it is, but I've done instantaneous S & G with the PM2 quite a few times. Loyal is the one that put me up to this use of "on-the-fly", initialization.

. . . I guess . . . if it works.

Of course, I guess your basically saying it doesn't work, so fine, I'll default to that.

It doesn't work. I've never done it and I wouldn't try it.


Modified By John Francis on 11/8/2005 at 5:19 PM

I'm still a little confused, I think you're saying you can have a gap in lock and may still get fixed positions from the first initialization.

My experience with the Trimble dual-freek models is you only have to initialize before ending the Survey. IE you start collecting shots as it initializes OTF. If you lose initialization at any point, then you will need a new initialization before ending Survey.

Is this the case with PM3 or do you need to initialize BEFORE any Kinematic shot?

I am pretty sure I'm going to purchase three and do Kinematic with two bases or do Static with three at once. It looks like it will be a very useful system for the price and add quite a bit to my capabilities.
Modified By David Karoly on 11/8/2005 at 7:44 PM

David,
By backward processing, I mean that it will make the end of the session the beginning and process all the data backwards to the beginning. So, if you hit a known point at the end of a survey then it could be considered the beginning initialization by the backward processing. Also, if you have enough data after a loss of lock, it could be processed backward so that you only lose the site(s) shot during the loss and not the site(s) shot from the moment lock is lost until OTF has a chance to initialize again.

It processes from front to back, then it processes from back to front. This would typically leave very little left to chance with respect to loss of lock issues.

John,
It could be that A.S. goes forward and backward. It could also be that you just got a really fast init. This could especially be true if your rover was close to the base early in the session and you had enough time on your first site to init or enough time before you observed your first site to init. I wasn't there so I couldn't tell you, and even if I was, I probably still couldn't tell you. I leave to "those in the know" to tell us if forward and backward processing is an enhancement to GNSS Solutions has over Ashtech Solutions. I do know that the old reliance processor had it and I think Prism also had it. The concept isn't really new, but from what I've inferred, it is new to "Solutions".

One instance was when I was showing how the PM2's worked to another surveyor. I told the surveyor that normally, I would initialize for about 10 minutes, then begin S&G. But(and I told him this), I wasn't going to wait. The base and Rover were set and the rover initalized for less than 1/2 minute, I recorded, maybe 10 points that he was locating with his TS and I hit a couple points twice, then I placed the rover back where I started hit for an occupation, stopped it and turned the unit off. The total time was 20-25 minutes. Everything worked out fine.

The last time I did it, I intitialized for about 2-1/2 minutes, then proceeded to S&G over points that I had previously located. Everything worked just fine. The total time for this deal was about 7 minutes.

I've done this process, amybe 4 times in the pst few months and every time it's worked. So far, I've only done it, when I already knew what the data should've been by prior location.

I don't really ever expect to use it, simply because, during intitialization, I am usually doing things that wind up taking 15-20 minutes(this is why I have my on-point counter 1200 seconds). I had to make a "special" effort to get such short static initialization.
Modified By John Francis on 11/8/2005 at 9:21 PM

I do like your idea of setting the timer high and then just hitting the stop button. I wouldn't use it all the time, but it certainly has its place.

I mainly do it, because even during S & G, I will often walk off a hundred or so feet(with a pin-finder or to set a nail), then come back.

There are many times during an S&G session, that I could've actually used static.

I’ve sometimes wondered if going back to a known point during a stop and go survey (using the same site ID) might help the software solve problems. With backwards and forwards processing I can definitively see the advantage for going back to a known point, (probably the init point) before shutting down.

I am buying the GNSS software upgrade because the price is right and ultimately the magic is in the software. I still wonder if Thales has a plan to use the firmware more effectively to help the software quickly reinit.

The known point reinit concept does not work very well right now under partially obstructed conditions but what about the concept of the user more actively controlling the flagging for the software?

The known point reinit concept has not been fully exploited in my view.

I never heard what the "upgrade" options were.

I don't think were supposed to talk about prices here, so talk to Mike.

From what I understand the software is ready to ship. If I remember correctly from an earlier thread the new software can co-exist with AS 2.6 on the same computer.

I bought GNSS Solutions last week. The CD is coming from France. It appears they are having a little turmoil over their.

Is everybody in France excited about this hot new GPS software?

Paul in PA

Locus Processor V 1.2 &
A/S V. 2.7 &
GNSS Solutions are all on my old slow Pentium III Dell Dimension computer.

I don't think I have booted Locus Processor in a while. I have had both of the other two open at the same time, looking at the same data sets in the last few days.

Say you have three fields to topo, they are seperated by trees, you need to walk through the line of trees to get from one field to the other.

You set the base in one of the fields, initialize, and topo the first field. When you walk to the second field, you lose lock. Now you get out in the open. You could topo the entire 2nd field under the first initialization and you may or may not get fixed solutions back at the office. Now you go to the third field, losing and regaining lock. You topo the third field. At the end of the session you decide you need a control point in the third field for the TS (you can see the base through the trees). So you set up and do a 15 minute static session on the control point. Now you have an initialization at the end of your work. So you're saying this initialization will, at a minimum, apply to the shots (I guess ProMark calls them "sites") in the third field and may also apply to the shots in the second field.

Hopefully my example makes some sense.

I know in some places everything is open for miles around (like the midwest or the Sacramento Valley north of the buttes) but often we have open spaces divided by no-GPS zones like trees and bridges.

And I'm hoping that you hear that the first field is just fine, that the second field is just fine, on it's own accord by something like a new/independent re-initilaization and that the third field would also be good by a third new/independent re-initialization, in a fashion similar to doing the first field, turning the unit off after finishing, going to the second field, turning the unit on and initializing and topo'ing and so on and so on.

without ever having to turn the unit off, enjoying the benefit of a faster initialization and all the data downloading as one project file.

As SV's come in and out of view your "init" certainly changes confidence, depending on pdops and position in the sky (low or high). So hitting multiple points over again during s&g sessions is a good way to make sure that you have a legit init (I like the sound of that). It also bails you out if you lost lock and didn't know it...

As for the first, second, and third field stuff I wouldn't trust any walk through the trees to keep a s&g session alive. Do the first field, hit some points multiple times, walk through the trees, (if you keep at least 4 sv's in view hopefully you will have enough data to maintain a float solution), then do a 5 minute occupation on a station and do more s&g...Hit that same station multiple times during the middle field session and ditto the procedure for the third field...

When you get back to the office you will either have:

1) one continuous s&g session with no losses of lock and you wasted 20 minutes during the day getting multiple shots.....or
2) you needed those extra observations and 5 minute inits to bail yourself out of a poor SV window sometime during the day and/or your jaunt through the trees....or
4) You have enough SV's and no space weather so that an OTF solution is available....you could try this by turning your long init points in the middle of the job into ???? instead of site id's..


Finally...The Locus/AS processor is more like a "least squares" kind of engine than an epoch by epoch kalman filtering engine. Prism and Reliance had flavors of pnav as their basis while AS uses the GPPE engine. Different animal. Remember the first Locus software allowed pseudo kinematic with long periods of time between occupations of the same site id....It combined observations at the same site into ONE final point solution....After v1.2 that was no longer available.

What happened to number 3?

Good advice Bob. I enjoyed playing with psuedo kinematic with locus processor, but they dumped it so we could review repeat vectors done in a stop and go session. Before, they were (as you mentioned) merged in to one, so you couldn't view the repeats. Using different site ID's for the same point helped this so that you could tell what difference you had between two observations. Now this is unnecessary.