CORS provides for downloading their rinex data for no charge. Is anyone using their GNSS receiver data exported to rinex to do post-processed kinematic surveying? if so, I'd like to learn how you are doing it.
?ÿ
A lot of surveyors did it in the past, but most have graduated to more complex RTK, Network RTK, or proprietary systems. It is still as good as it was in the past, but other systems can be better or more importantly more time economical after the initial investment.
My recommendation is to get a post processor that can create a VRS position within your survey from available CORS data. I did that years ago using GNSS Solutions, which automatically download the three nearest CORS, and created the VRS position and VRS observation file to be used within your post processed PP RTK. GNSS Solutions is no longer supported by Thales/Magellan/Trimble, so you need to do some searching. It is just as easy for me to set up a base, then use an OPUS/OPUS-RS position to post process from.
How do you do it? is too open a question.
Ask again giving information of what GPS toys and tools you have and what your budget is to get more.
Paul in PA
Yes, not all that often but last Friday I was tieing down several BLM corners to wrap up an extensive design survey and found myself outside radio range and did a half hour static on my last corner tie of the day and found my base had shut down early on me due to a failing battery and cold temps. There happens to be a CORS station 5 miles away. I'll download the data through the NGS site and substitute it for my base in TBC for post processing. By processing all the day's work using both my base and CORS independently I should be able to get a decent solution, I hope. The corner was in fairly dense forest and may be pretty noisy. Fingers crossed.
With a half hour observation you have a chance at getting an OPUS-RS solution in the Anchorage area. email me the RINEX file and I'll give an opinion or even submit. It might need some cleaning up.
Paul in PA
I'm confused about the definitions.
Post Processed Kinetic, of course, is distinguished from Real Time Kinetic by being processed back in the office rather than at the time of occupation in the field.
But what about the Kinetematic part? Drones definitely are kinetematic, with points being captured along a continuously moving path.
But it seems like both terms get used for operations where a short time is spent with the receiver stationary on each fixed point. Why is that still kinematic?
So what does it take to make a Static observation? Usually we think of an occupation of many minutes to some hours for Static. Does more than X minutes make it Static?
The other variable is what data you process against, and thus the distance between the rover and the reference.?ÿ We tend to think of Static as processed against distant references like CORS. Does the reference source affect the name?
So if I set up a base for a few hours and process it later with OPUS, and occupy many points with a rover to collect files for a few minutes each to process against the base file, what is the right name?
?ÿ
Bill,
Frank specifically did a longer than PPK static observation, because he could see the sky view problems at the site. Good thing he did because he later found out he had base problems. Without knowing exactly what Frank did let me give a general explanation. Let's say he was doing strictly RTK or mixing RTK with static. A good policy in doing an RTK is to start with a short static observation, do an occasional static throughout the day and end with a static. You can end on your starting point but as long as your statics are on marks that make a repeat observation possible, you are OK. Some softwares (maybe all now) can even calculate backward from a static point if somewhere along the line you lost lock. Again assuming Frank lost lock while doing RTK and has some kinematic points prior to his ending static, PPK can fill in the gaps.
If it were my project I would break it up, into parts. Download and record all RTK using his base file. Next step, add a CORS to base and run PPK. Step 3, Run PPK from the CORS only. Last calculating step, solve the static file independently and/or use OPUS-RS. Now compare all 4 sets of positions. If it neccessary to run some PPK backwards, figure out your best position for the static, fix in your file and run PPK again.
Yes more office work, but we are building confidence in our solution hoping to not require a site revisit.
Paul in PA
?ÿ
?ÿ
?ÿ
I think a lot of folks get "fast static" mixed up with PPK, and then a lot of people get confused about what PPK really is.
Fast static does not require initialization. It's a short static session, and nowadays the line between "static" and "fast static" is pretty blurred - in my opinion, static is static, whether it is a short session or a long session.
When most people talk about PPK, they mean obtaining RTK-level precision without receiving a real-time correction stream from a base receiver.
This requires initialization at the rover, either on a known point or by letting the receiver sit and collect data for enough time to solve for the integer ambiguities. It also requires the operator to "maintain lock" by keeping enough satellites in view for the length of the PPK session, more critically enough common satellites between the base and rover. But once the rover has initialized, you can essentially make "RTK" type observations (1-5 epoch shots) during the length of the session. And as Paul mentioned, letting the rover sit and collect data at the end of a session helps a lot too. I suspect these non-moving segments are why a lot of people get confused, since these are essentially static observations during a kinematic survey.
?ÿ
But PPK does not necessarily mean RTK-level precision - I used to support scientists who depending on the job needed either centimeter-level, or one-to-three feet precision. For the latter they could stretch out their distance from the base and not worry as much about a long initialization.
Concerning the original post, I have used CORS for PPK processing before, but the downside is that a lot of CORS (at least where I have worked) do not log at sufficiently short intervals to make PPK feasible , or at least economical. PPK works best with a high observation rate, 1 Hz or better. Additionally, CORS may not receive/log full constellation data (i.e. they only log GPS) and there may not be enough common satellites to solve at the desired precision.
As Paul mentioned, processing software can use a couple tricks to help solve sessions where lock was lost, but it cannot fix bad or missing data. PPK is one of those methods where the operator really has to understand both the field and office technical details in order to get their desired accuracy.
A lot of UAS work is done with PPK, but often by combining the GNSS solution with IMU data to get a much improved solution for the trajectory. Again, the operator needs to have a very good grasp of techniques and pitfalls involved.
?ÿ
Logging at sufficiently short intervals is a current problem with CORS. In the past you could get 1 second files from NGS even if it was recorded at any longer interval. In order to save space after some time NGS decimated files to 30 seconds for long term storage. That was OK because using ufcors, you could still request 1 second files. NGS would use a program that interpolated the 1 second data from the 30 second data. You could download the interpolate program for your own use, but NGS no longer makes it available. The original "Interpo" required you to write a .bat file with the commands and later "Rinterpo" was executable in Windows and still works in Win 7. I use it from time to time, when my Ashtech receivers default to the factory 20 second interval and I then interpolate to 10 seconds for submission to OPUS or OPUS-RS.
Way back when, I tested interpolate by decimating static files to 60 second intervals or longer and then interpolating back to 30 seconds, then submitting the original and interpolated files to OPUS and never saw more than a variation in the N & E third decimal point. The program worked by reading 3 points before and after the needed interval, calculating a best fit curve and using the midpoint, for every observation of data created. I have seldom seen a large file take more than a second to do all the calculations. The people who wrote the programs are long gone from NGS and I take it the new folks do not understand or trust them, hence they are history.
For some of those same reasons NGS wants to rid itself of the US Survey Foot.
Paul in PA
If you are talking about PPK (Post Processed Kinematic or sometimes Stop-and-Go) then I would think most CORS epochs are too long.?ÿ I mean you could do it but Faststatic against the CORS would be better and you pretty much would have to anyway.?ÿ Maybe there are CORS out there that have shorter epochs (1 second or at least no more than 5 seconds) which would be more practical for PPK.
For aerial mapping, Absolutely.?ÿ
A 30 second CORS, or 2-3 CORS, good to go, interpolate the CORS to 1 Hz.?ÿ
We would depart for job, which could be adult be 40 min flight time away, I??d put up a receiver at the airport and process the airborne data 3x using CORS, NRC-PPP, JPL GIPSY and my own base: no significant difference.
1/2 a wave differences, 10 cm, was well within required positioning, and only 10 cm differences really confirmed that the base at the airport was just fine at well over 100 mi.
So yes. CORS for kinematic. Data from all kinds of base receivers from SOPAC, for lots of countries. Bogota was always a go to.?ÿ
?ÿ
