Activity Feed › Discussion Forums › GNSS & Geodesy › PPK with Survey Pro
PPK with Survey Pro
Posted by therock003 on January 21, 2018 at 7:20 pmOn another topic we discussed the possible use of ppk practices for use with certain applications. Since i have not practiced this before, i need to make some test runs and try it out. So of course you have to set the base to log static when operating, and then have the reeiver store ppk information, so even when it does not receive base corrections, it stores information for points taken as autonomous to solve them in the office via post processing.
So what do i do to get the final positions of points that have ppk information? Do i import them in TBC along with the static for the base, and solve all individual baselines?
therock003 replied 5 years, 8 months ago 6 Members · 15 Replies- 15 Replies
I don’t know anything about Survey Pro, I’m guessing we are talking about a DC program. For that I use Access and Survey Controller.
I assume the procedure will be the same, I always set the survey style for PPK to send the info to the collector:
1. It saves steps when downloading, all the RTK and PPK files from the day come into TBC together when the DC file is downloaded.
2. I’ve had issues in TBC that I didn’t have in TGO processing PPK files from the receiver.
You don’t want to have to download a collection of PPK static files to TBC individually, if you collect to the collector, all the PPK files will automatically come in with one file download. I always download the base file first, then when you download the job file from the collector it will draw a light blue line from the base to the PPK location, just hit process baselines and it will process all the points and give you a slide with each one and their respective information. Then agree to accept them and it will put them where they are meant to be. It’s a good idea to write down the before and after numbers as you are learning the program to see how far it moves after it’s processed.
I also download the base from the collector, when you go to shut it down, I stop the job, but don’t turn off the base. After the job is ended I go to the receiver and import the base static file from it to the collector (this is a good time to do some base file clean up), then in the DC you have both the job file from the rover with all the PPK files in the .job file, and the base file, so then you can download it all together without dragging everything into the office. Maybe survey pro won’t do these tasks.
Many people are afraid of PPK, you just have to remember that PPK and RTK are the same thing except one is real time, one is post processed, but they use the same info.
The important thing about PPK is that you need to let it have some time, let it see the sky for as long as you can, before and after collecting the point, the longer the better, if it stays fixed for an hour and you collect 20-50 points and never lose fix, then that session is going to be good, I’ve never seen a session like that fail.
IMHO it should be SOP to log the raw data from your rover and base for RTK work. I’ve used both Survey Pro and Access and the procedure for PPK is the same. For me it is the only way to catch bad initializations, particularly with the float/fix type RTK engine. It’s not that uncommon for me to lose radio and need to make ties either with PPinfill in the case of Access, or do fast static using Survey Pro, in either case the data will need to be processed later in TBC back in the office. When we were using the R8-3 as a rover in marginal high multipath environments, wasn’t that uncommon to get a bogus fixe now and then. Without running that data through TBC at the end of the day, I’d be hard pressed to catch the bad shots without multiple occupations. Typically what I’ll do is import the points out of the DC using just the point #, then import the PPK points using the same point # with a “_extension”. Typically if one of my shots involved a bad localization at this point it will slap me in the face while viewing the residuals in TBC and the two points won’t plot in close proximity (.01-.02′).
Like Mo said on observations, ‘Moe time is Moe betta’.
WillyIs there free software or service anywhere to process PPK?
I have no real need, but it would be interesting. I have considered getting a 2nd older receiver (e.g. 4000sse) to do more benchmarks in a day, and PPK would be another thing to play with using that gear.
.Bill you can process PPK with RTKLIB’s post processor.
OK. I guess I need a lesson on PPK with SurveyPro. I usually just take a 20+ minute shot with the Rover as a check. I then process that file and my base position through OPUS. I don’t have any post-processing software; but, if RTKLIB will work, I may have to give it a try.
So, how would I store a PPK shot in SurveyPro?
So, how would I store a PPK shot in SurveyPro?
You don’t. You store the raw observations in both your base and rover and then importing those raw files directly from the receivers into your post processing software. I’m only familiar with Trimble TGO & TBC, but I’d venture a guess that RTKLIB works in a very similar fashion. The process is completely independent of SurveyPro and differentially corrects the rover’s observations against the base data. The seed coordinates for the base are held as fixed and the vectors solved to your rover shots. The resulting vector solutions can then be examined closer for issues and if acceptable can then be exported as coordinates in whatever projection you’re working in.
RTK all by itself is the equivalent of a conventional side shot. There’s really no independent check. By resolving integer ambiguities using this process you can get a much better feel for the statistical strength of your solution beyond just the pdop that SurveyPro is giving you, which in my experience tends to be a bit on the optimistic side.
WillyI’m wondering if Survey Pro has the same capabilities that Survey Controller and Access do.
It may not be possible to log at the rover like the Trimble DC’s do as you RTK (RTK & logging style), it’s very powerful.
However, you should be able to start a rover survey in PPK and collect.
That’s one of the big differences between SP and Access. SP doesn’t let you set up different survey styles like in Access. At least not the last version I was using. In any case unless he is using TBC he won’t be able to import a .survey directly into a non-Trimble processor. Likely have to convert the data to rinex first and go from there. Access was for me a major improvement in that respect.
WillyI guess it’s so seamless with trimble that you don’t think about all that other stuff:
Rinex? what would I use that for?
OPUS? I hear all about the data conversions, I just click on the file and it’s gone. The only time involved is typing in the email address. Don’t need to worry about where to measure the HI, it converts it for you.
And so on……..
Sorry, didnt get mail notification for the replies and im just seeing this.
So Guys not sure how Acess operates since i’m using Survey Pro, but in my case you are getting the option to enable ppk for autonomous not sure what this does since supposedly exporting the job file should already have all the necessary information like satelistes gps start end time and whatever is needed for the post process for later.
So in any case, better safe than sorry, lets say i enable ppk for autonomous, i then export the whole project as a single file at the end of my session, and then go at the office to process the baselines for the final result as you say?
I’ll do some experimentation this coming weekend to say how all of this behaves
BTW theres a .survey a .job and a .job/raw file. Which should be the most appropriate one for me to export
EDIT: So if you set do not allow, it means that if you are in an autonomous position yo ucan even store points, you would only need radio or network solution to store if you set that option?
I would seriously appreciate further help on this one. I have been trying tough this past week but to no avail.
So i power on my base unit, and let it log the static file. I download it when done, and import the .t02 to TBC. During the time the Base was recording, i did some autonomous shots with the rover unit, on the point i want to survey. Did 3 of them to have a comparison reference for the results. When i’m done i export the .job and raw file from the rover receiver, and i import to TBC as well.
Now on TBC i eneter the known coordinates to the base on the static file, and set control quality to establsih my base.
But now comes the tricky part. Upon the .job file i imported, no points appear on my project in order to select and process baselines.
Why dont they appear?
If you can think of no reason, inside survey pro on theres a feature that saws the raw data, and from there you can see GPS week, start and end time and other data.
Can i at least manually write these down and compile some kind of format to import, and then habe thos points appear and process them
As i said ive been sweating a lot about this, and i would welcome the help.
The only obvious problem I see is you don’t mention importing the .t02 file(s) from the rover into TBC. They are not located in your .survey file but are stored separately. Also TBC, depending on the version you’re using, treats SP .survey files as the basdard step children of their main product Access .job files. All you’re missing are the rover files and forget the .survey files. They don’t contain the raw GPS data that you need to do PPK. Hope that helps. I’ve used SP and since moved on to Access and don’t miss it.
WillyI dont understand, what the point of using the rover static file, since the rover was moving and has lots of useless information. And lets say i import both base and rover static file and the job file, how will TBC process the desired baselines
Every time you store a shot with the rover the software in your controller will create a parse around that set of observations coding it with the information you put in SurveyPro, like your rover antenna height, point number, description, ect. That info is all in the .t02 file in the receiver, created by the software. Back when I first started out doing this I didn’t have any fancy software to parse things out like this. Run the base and log the .dat file to the receiver. Turn the rover on over a point and let it cook and then shut it down creating a unique file in the rover stamped with a Julian date/file # extension. It was up to me to book the point number, description, antenna height, start stop time and then manually enter that data in when I differentially processed the base data against the rover data. Since your moving around, you’re relying on the software to create those records and they’re coded into the .t02 file in the receiver. Your .survey file is just recording the output and generating coordinates and statistical data and keeping a journal of your job. The raw GPS data you need in order to do any processing is stored in the rover’s memory. If you don’t keep up on downloading it fairly frequently, it will be overwritten and that data lost. You need two sets of .t02 files. One from the base, the other from the rover. Without either one you can’t PPK jack.
WillyOf course, you are right. I’ll try importing the rover static as well.
On the other hand i am confused with all these different post processing methods that exist. On one hand we have this ppk we have been talking about, but then there is this fast/rapid static, there is the stop and go method, or even occupying a point and start and stop logging on the spot.
Whats the difference between all of these method, and provided you have good visibillity and satelite geometry, could there be more precision in the end?
Log in to reply.