Has anyone out there ever found a reliable method for initializing a kinematic survey on a point previously determined by static?
I have been struggling with this problem for over a year, and have not been able to make the magic work. Ashtech has never, to my knowlege, published any procedure for this.
There are two methods.
1) you finish your static shot, and without turning off the receiver, you log a kinematic using the same site ID, then when processing you massage the observations to eliminate a 1 second ????, making it continuous. This worked well with version 1.0 and 1,2.
2) You turn off the reciever after collecting a good static. Next day, you occupy the same point logging a kinemetic using the same site ID. Then you continue with kinematic site logging.
The first method works almost every time.
The second method works sometimes, but mostly it fails. The software does not allow the user to say "THIS OBSERVATION IS FOR KINEMATIC INITIALIZATION FOR SUBSEQUENT SHOTS IN THE SAME FILE!!!!!"
When using version 2.4, if you download all files in the same session, including D-files, the software insists that the initialization observation is a "STATIC" obs not kinematic, resulting in an attempt to process a 30-second static shot, which always fails.
I suspect that Ashtech has a real problem figuring this one out, like I have, and thats why the official silence.
I would like to be able to tell the software "look, this particular observation is a 30-second shot on a previously KNOWN POINT for the purpose of continuing with a kinematic session." Why is it impossible to tell the software this simple fact. The software is not capable of figuring this out on its own, apparently.
I have decided that the locus is just not capable of kinematic unless one uses the initilazation bar.
If anybody knows a secret method to make the HP handheld do what I am trying to do, please let me know.
I need to understand your field procedures a little better, I guess. Are you trying to make the software perform a 30 second initialization on a known point, then continue doing kinematic? That is what I am reading (interpreting) from your questions..If so, you're trying to fix ambiguities with single freq in 30 seconds and it "aint gonna happen"..
I have had success performing a full 5 minute initialization on my known point in Locus, then logging kinematic data on the same day. I may be misunderstanding your problem...please advise.....b
Nearly,
From my understanding of Locus Processor and Ashtech K. this MIGHT work, but I've never tried it.
Collect static location. Process it. Export it as vectors.
Next day use static point for init. Don't use software init box, just use same point number id. Collect K. points. Import vectors and Process K job seperate from static session.
I've run several static/kinematic sessions without the init-bar(I never use it) but I've always been lucky enough to get them in one day and not have to turn the receivers off.
Alternatively in Locus Processor you can use a 5 minute init on a known point. Collect some K points. Return an hour (minimum) later and collect another 5 minutes (same point id), collect some more K points. (I like to return 2 or 3 times but it isn't absolutely necessary.) Also do the 5 min. thingy on several known (static) points throughout the job site. This will not process as you want it to in Solutions 2.4. You have to use Locus Processor. This is essentially the Psuedo-Kinematic technique that Shawn, JD, Brian and others along with myself were discussing in earlier threads.
The PK technique I've used. The stuff I was doing wasn't control but ground topo and things seemed to work fairly well with x,y,z's about 0.1' or less residuals. As always there are a few outliers for various unknown reasons (multipath, obstructions, etc.)when shooting 10 second shots.
I've never run a full blown test on PK for control situation. I did but then when I started looking at a couple ties that I thought were in the control network, they just didn't measure up for control. Fine for their use, ground topo.
Good luck,
Jimbo
Pardon me guys for being a little ignorant about the Locus. I got one to use outdoors just a few days ago and have still been studying the manual in between solving other problems.
Just so you know that I am not too much of a new guy my first kinematic and PK surveys with Ashtech single frequency tools dates back to 1994 but it is a new day with the Locus and Ashtech Solutions so there are new lessons to learn.
All I can tell you so far is what I have read in the manual and that is a five minute occupation to begin that kinematic survey. That is quite a bit more than 30 seconds. Now that is just what I got from the manual. Once I figure out what the lights are telling me and what the button does I want to go outside with my little HP and initialize on a previously surveyed point using the Z-12 here on my desk as a base station. I have not done it yet but I think I can make it come together if I try hard enough.
Many of my projects would have required me to have a bunch of previously surveyed points to use to re-initialize without going back to the bar at the base. That memory of what I used to do is why I want to learn to use the Locus without using the bar. Not that the bar is a bad idea. The bar is the only way to begin without having a static surveyed point to start. I just know, down deep, that I am going to lose lock before the session is done and be looking for a short walk instead of a long one. That's why I want to learn to do it without the bar - using a previously surveyed point.
What is in my head is that I am going to have at least two fixed points in my project. The first will be the base station on my desk. The second will be that point out there in the parking lot where I initialize my rover. I guess I end with a question - do you think that will work? Would you be willing to try it and tell me how well it works? Maybe we could learn together. If you have already whipped this problem then please share with the rest of us.
Once I make it all work with the HP I want to learn to use the new Survey Controller 2 and then maybe I can answer that question about which one works better.
I can tell you that Richard and I went out and did some experiments with two Locus base stations and one rover. The "extra" base tried to get a solution to the rover on the bar but the vector failed with only five minutes of data to work with. Once we did initialize the rover was getting vectors to both base stations. Do you think it would have solved the vector to the extra base if we had left it on the bar long enough?
So far, Richard is the wizard for questions about what we did that day but I will get there and be ready to help as soon as I can.
I probably shouldn't get involved in this one, but I'll give it a shot. What is the difference between initializing on a known point and reinitializing on a known point. The five minute procedure was mostly for the k-bar init. I believe Bill Martin made a comment a long time ago on this board that the 5 min procedure for init and reinit on a known point was more or less a pessimistic shot in the dark and that >30 sec should be sufficient. How long do you observe a reinit on a known point. There should not be any difference. One thing you might try is to make the known init/reinit point a control point (vert & horz) in the post process s/w. These are guesses on my part as I unfortunately have little experience with Locus kinematic due to environmental conditions in our work area. I would strongly suggest searching for any post made by Bill Martin related to kinematic. He had a "three part series" that upgraded the techniques in the manual.
Shawn
Shawn,
I am not saying don't push the envelope or try things that are not in the manual. But if something almost always fails it is time to stop doing it that way.
Like the guy who went to the doctor and said, "Doc, I think I broke my leg in three places. What should I do?" The doctor said, "Stay out of those places!"
1st I haven't done a lot of K but I've done a few projects with the Locus.
The following is with Locus Processor software. I haven't had a project to use Sol. 2.4 with K yet.
Using the 3 receiver setup and the init bar (2 base, 1 rover) the software (Processor) always seemed to have a problem in determining the rover on the init bar(when K box is checked). Even with fairly long (1 blink) occupations for short baselines (2000-3000 ft). That is why I gave up on the init bar.
I haven't had any K-projects large enough to run over 1 day. Therefore my techniques may not directly be usable for those that have to turn off the receiver and come back on a second day.
3 Locus units, 2 as base(B1, B2), 1 as rover(R).
B1 - known control point near center of project or at one corner of project
B2 - known control point offset a good distance from center of project perp. to "length of project" or at opposite corner of project from B1.
Case 1 (center pt & dist. pt)- tends to make strongly intersecting triangle vectors, even if not really necessary.
Case 2 (corners of project)- This makes the 2 "vectors" increase and decrease inversely (more or less).
R - anywhere on pole w/bipod (usually set a nail for future re-occupation).
B1, B2, - start cooking.
R - sync with HP, 5 minutes occ. Using K survey mode, pt. number x. Repeat until B1 and B2 have 1 blink...finish current 5 minute countdown. All repeats use SAME pt number. (Effectively provides a static control point as init for K rover).
R - collect K points thru project- 10 sec. occ. with 2 sec epochs. Occasionally setting nails for re-init if necessary (write pt. number on flagging for re-init reference.)
R- re-init on "known" point for 10 sec. repeat twice with same number.( This gives 30 seconds re-init and you don't have to modify HP parameters, which is slow to do). Continue collecting K data points.
R - re-init on "unknown" point for 5 minutes, use bipod and reset HP parameters for countdown. Have a drink of water while waiting. Relax. Reset Hp countdown to 10 seconds. Continue collecting K data points.
R- long way from home(probably best anytime)- after re-initing on unknown, and collecting added data points, re-occ. known point, preferably re-init point, at end of session for an additional 5 min., same pt number.
I've had excellent success w/above procedures. But to repeat only done a few K projects. On each project I've rarely had to throw away more than 1 point per hundred, realizing this is for ground topo and I accept .2'H & .1'V±.
I always watch planning software for low (<4 if possible) PDOP, never more than 5. And lately I've been watching solar weather also for Kp index forecast of <4. Usually 5+ satellites.
(Sidenote: I've looked at 1 K project in Sol 2.4 that was processed in Locus. Actual sats were always 1 or 2 more than predicted from planning software. Why, who knows. )
If anything here doesn't make sense let me know. I might have left something out that I just "do" without realizing I left it out.
Any questions, just holler.
Oh, yeah, thinking about it, if I went over 1 day I'd essentially do the same thing (ok, you 'waste' 20 ± minutes) but maybe start the R near where I wanted to start Day 2 at. Then I'd keep repeating the 5 min. Hp countdowns til I had 1 blink, then I'd start collecting K data.
Overkill, maybe, but I don't go back.
Jimbo
Modified By James Webb on 10/2/2001 at 7:15 AM
Shawn,
The 5 minutes is for the K-bar. 30" should be fine for a known-point initialization.
Brian
You guys are making it a _LOT_ harder than it needs to be.
Day one: Collect two static points (1 & 2 ). after you have enough lights to solve the vector between the two, turn one off. Turn it back on, initialize, collect the point as a standard kinematic observation, using the same point number.
(I use 3 sec interval, 15 sec obs. if I'm going to be going all day, 2 sec interval, 10 sec obs. if it's a short day.)
Rock & roll!!! Set a nail once in a whils so you'll have a place to re-initialize if you lose lock. Set a nail before you enter a marginal area for the same reason.
NEVER ignore a kinematic alarm, keep the PDOP under 5 & it should all work great. All bets are off if there is significant solar activity.
If you need to come back a second day, set your base on a previously collected point, initialize the rover on a previously collectec point; Rock & Roll!
I've collected 200-300 shots with zero failed shots this way.
IMNTBHO, throw the initialization bar away.
Jerry
Jerry A...
Here's the thing. The 30 second observation over the known point, logged as a kinematic, does not work with version 2.4 at all, and works some of the time with version 1.2, and works some of the time with version 1.0
The only reliable way I have ever been able to initialize a kinematic session over a previously known point is to end the static session over point B and log a kinematic WITHOUT turning off the rover, and then fiddling with the file in version 1.2. Simply occupying the known point from yesterday with same point number kinematic 30 second is frustratingly unpredictable.
Why does it work for you?..it wont work for me.
Modified By Nearly Normal PLS on 10/6/2001 at 3:06 AM
Nearly,
Don't know why it works for Jerry.
If I understand right on the second day you are trying to start with a 30 second init on a known point. Theoretically this might work but I doubt if in our world it will. Try a 5 minute init. The trick to not having to fiddle with the file (in 1.2) is to not record the point in the HP as a static...multiple K reoccupations of the same point number and the software cleans up those ???? spots.
Jimbo
Nearly, what baseline length are you trying to init to on your known point? Maybe the 30 sec init time works for 100' baselines, but I just use the 5 minute observation no matter what...Also, how long is your unit running BEFORE you begin the init? If you turn the rover on and let it begin collecting as soon as you get out of the truck, by the time you get it set up on the known point for an init you will have 5 minutes or so of data for the software to chew on before starting your init.....
Sorry Boys, but my "on-off" method works fine with 2.4.
I did a little test a couple of days ago, using one locus and one promark2. Because the promark has a fixed recording interval of 10 sec., I used an initialization - observation time of 1 minute.
Very interesting results!
Set four points, (all about 100' apart - checking procedure, not accuracy) Promark2 on #1, Locus on #2. Observe until I get one light on Locus. Shut Locus down, turn it back on, synchronize hp-48 kinematic controller, collect 1 minute kinematic on #2, walk to point #3, collect 1 minute kinematic, walk to point #4, collect 1 minute kinematic.
All vectors solve very well. Checked vectors with total station, no blunders, no problems.
In Solutions 2.4, modified "????" observations (interval that it took to walk from point to point) to point 1001, solutions assigns consecutive point numbers to each 10-sec recording interval between kinematic points collected with hp-48. All assigned point vectors solved ±0.2'
Looks like a _GREAT_ potential for rough topo applications.
Ain't technology GREAT!!
Jerry
Bob, Occupation time is irrelevant when using "known-baseline" initialization. Of course, this assumes that the rover remains within 20km of the initialization point. Bias fixing beyond 20km (in L1 kinematic) is problematic.
Brian
Modified By Brian D. Ewing, PLS on 10/6/2001 at 10:59 PM
Brian, I'm thinking that a 30 sec init time is a "perfect" solution time to a fixed point. With the high solar activity we are seeing now, how reliable can 15 epochs be (a 2 second rate) in determining the ambiguities for a fixed solution? I guess I'm still back in the dark ages of collecting too much data rather than just enough, especially with L1 only units..I would agree with Zxtremes on the init times....