While locating stones yesterday I had one in a valley and couldn't receive radio, I had known I was going to have some issues so I took a repeater with me.
However, it was raining so hard that I couldn't get the truck anywhere near the point I wanted to set on and had to do it all on the 4 wheeler, the repeater got left in the truck (I didn't really want to set it all up and leave it in the rain anyway).
That meant I had to locate a couple of points using PPK.
I always look at how much they change from an autonomous point to the processed point. As I looked at the second one it changed only 0.14'N, 0.11'E, 0.44'El.
I've never seen one that close before, and it wasn't like it was a real long session.
I used some far away cors stations and processed, and they matched very close.
I guess I have to trust it, but ..........
> I used some far away cors stations and processed, and they matched very close.
>
> I guess I have to trust it, but ..........
How far away were the CORS sites that you used for the PPK solutions if you ended up with fixed integer solutions from short occupations?
50 miles, 2 minutes
> 50 miles, 2 minutes
Was it a continuous segment of PPK for much longer than 2 minutes from which the integers were resolved or just one isolated 2 minute occupation?
The trick to make it work, is to start the PPK session as long before you need to locate the point as possible, and leave it running as long after you locate it as possible. In this case I was taking long 4 wheeler rides between points in rough country, around the head of ravines and through pasture fence gates.
So I would put the receiver away and turn it off while riding, then when I get there start it as soon as I can, let it look and fix, do my other stuff, then locate the point and not turn it off until I left. The ppk was on for about 12 minutes at that particular point before I left and drove to the next one. But I only spent 2 minutes on it for the PPK session, the base was only about 2 miles away
> So I would put the receiver away and turn it off while riding, then when I get there start it as soon as I can, let it look and fix, do my other stuff, then locate the point and not turn it off until I left. The ppk was on for about 12 minutes at that particular point before I left and drove to the next one. But I only spent 2 minutes on it for the PPK session, the base was only about 2 miles away
Oh, I can believe getting good solutions for the baselines to the base 2 miles away. What's giving me pause is that, if I understood you, you were getting baseline solutions of similar quality from a CORS site 50 miles distant. If the processing proceeded using the point as a fixed integer solution from the 2 mile baseline solutions and initializing on it for the baselines from the CORS sites, that seems plausible that the CORS solutions would agree fairly well over a short occupation.
I processed two points to the cors and the base, there was .03' difference more or less. The verticals weren't very good however, not that I care much about them
PPK = Punt, Pass and Kick
What did you do with the football?
> I processed two points to the cors and the base, there was .03' difference more or less. The verticals weren't very good however, not that I care much about them
What I was wondering about was the order of baseline solutions and whether the baseline processor solved the short 2 mile baseline to the point first and then used that position in the solution of the baselines to the CORS site.
No I did them seperatly.
> No I did them seperatly.
But if they were in the same project, didn't the position quality of the first effect the second set of baseline solutions, i.e. did you see a fixed base initialization in the second set? I'm just wondering if they were truly independent or not.
No, they were processed independently, not connected, I always do that.
> No, they were processed independently, not connected, I always do that.
You're using TBC, right? If you look at the detailed baseline solution summaries as they came out of the baseline processor, is there anything in the summary that indicates a fixed base initialization was used in one or the other?
Kent, these baselines are processed totally independent of each other, there can't be a connection.
> Kent, these baselines are processed totally independent of each other, there can't be a connection.
If they are in the same project and TBC keeps track of baseline solution quality, I'd think the only way they could be completely separate is assign a different point name to the point that was positioned by the baselines to it from the CORS. Otherwise, TBC would "know" that there is a position for it of a certain apparent quality already in the database, right? How did you prevent TBC from using that position in the second baseline solution, that is, not to use it to resolve integer ambiguity?
It's much simpler than you might think, I've always done it that way, looking at each solution, then deciding if I combine them and adjust
> It's much simpler than you might think, I've always done it that way, looking at each solution, then deciding if I combine them and adjust
I wasn't referring to the adjustment. I had the actual mechanics of the baseline processing for PPK segments in mind. If you include a session on a control point of survey-grade (fixed integer solution) quality in a PPK segment, doesn't the baseline processor attempt to use that to resolve integer ambiguity?
I'm not talking about adjustments either, I didn't adjust these two points anyway, but held the solution from the base.
It's always been part of my work flow it see how each baseline solves for each point. There are probably many ways to accomplish this.
In TBC I do it one particular way, but I can think of a couple of others that would also work. Computer programs are wonderful for certain things.
> It's always been part of my work flow it see how each baseline solves for each point. There are probably many ways to accomplish this.
When PPK baseline solutions are generated in TBC, is there a setting on some processing setup menu that instructs TBC to pay no attention to the position of some point as previously determined? In other words, why don't you think that it uses some prior survey-grade position in processing other baseline solutions?
In earlier versions of Trimble's baseline processing software, in that situation it would generate two different solutions, the OTF solution and the fixed baseline solution, and would choose between them for the final solution but would display both with the statistics of each.
Yes there is a setting