I am attempting to post process several months of data collected from a Tersus Precis 305 on a slowly deforming landslide. Base station data is from a separate publically available site about 40km away (nothing closer).
I have been attempting to use RTKPOST in static for this but every time i run it there are no results (or occasionally one line at a random date within the study period.
I have initially set it up with the basic setup and following various suggestions from other forums have dabbled with various options with no luck. Running in single mode is fine for the rover data. It runs in kinematic and fixed but just not in static.
I think that there’s an issue with the base log.
Also, it can’t be processed with manually inserted base coordinates.
Do you have another RINEX base log?
I have this other base log but it didnt look right and wouldnt work once I used it so went back to the other one. I have added them to the google docs folder.
Use only the 7-day observation sessions for analyzes in the PPP method (CSRS-PPP)
Do not use RTKPOST - this is not professional postprocessing for your purpose. RTPOST is just a ‘continuous’ calculation and you need the ‘Stop & Go’ method
In addition to the PPP method, i.e. in the ‘Static’ method, use only daily solutions, i.e. sessions no longer than 24 hours.
If you want to use IGS stations, you have to do it by generating VRS for your location. It can be embarrassing. It is better to use a base station, 40 km away, which you mention about as a base point.
This is an interesting project, but there are no easy and quick computations here.
The rover part seems to have quite a number of “data-holes” in it.
How is your data collected? By digging in a pole and leaving it there for ~8 months or coming back to the site once a day or something completely different ?
RTKpost should be able to process this, if you can get a base. You can concatenate the base-obs from IGA/EUREF/etc by using a wildcard “*” and placing the base obs in its own folder.
As I see it, there is no need for you to split up the data if using RTKpost and a kinematic solving method, but it all depends on how you split of the data.
You say it runs in kinematic and is fixed, but not in static. Can you elaborate on why you want to run in it static mode?
So the site is very isolated and under snow 9 months of the year. We set the units up in Feb last year and returned in Feb this year and they had all stopped working due to damage to the wiring connecting the solar panels to the batteries.
When I ran it in kinematic I was only getting accuracies of 10-15 m. I had also be using the * as a way to read multiple files but whether I am doing it wrong and it’s contributing to the inaccuracies in the results.
Regarding the base obs, do you mean I could select multiple sites and combine for each obs period so it essentially averages them?
Your inaccuracies can be from the data having holes in the rover data. That breaks the ambiguity and thus the continuity of the solution.
Instead you could do static post-processing per day. No real user-friendly way of doing that in RTKPost, other than manual setup of the boundaries for each day, but the resulting positions could then be plotted afterwards by the day (if that is enough resolution for you).
That’s how you should calculate it. It is also important to use the RINEX 2.x format, because only then CSRS-PPP will give good results. Here’s an example.mqzg0540.pdf (1.6 MB)
Problem is this is a essentially a moving surface you are surveying, so if moving much more than 1-2 mm a day, a static post-processing isn’t ideal, or would have to be split up in shorter sub-divisions that fit the above movement-criteria.
Despite the poor preparation of the project, the results are interesting. The receiver power interruptions have changed the method to Stop&Go.
If you apply the VRS near the point, you will have what you planned. Here it is interesting that the CSRS-PPP report accepts all epochs with good accuracy without base point. You can see it on a my one-day trial.EMMA001A.pdf (1.1 MB)
I think that everything depends on ‘know how’. That’s why I joined in this thread. Here is an example that hardware not decides only (the antenna is an exception) also software.
Instead of your own base receiver, you need an active geodetic network. You can set up your virtual base near a point with high accuracy. Then all you need is a rover with GPS L1 only.
I prove it with the attached test from the emma session, using the IGS network.
The conclusion is that RTKPOST is not a software for these purposes.
