No solution data in RTKPOST

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.

Any help appreciated.


Can I ask you to share your logs, @emma.cody?
I’ll try to post-process them.

It wont allow me to upload as it isnt recognising the obs or nav data. Is there another way to send to you?


You use a file service, like

You can upload logs to Google Drive, Dropbox etc. and share a link here or in PM.

Great here you go
mydata nav and obs are the rover and base are the 0520 files. This is the first week of base station data but all ~8 months of rover.

Thanks again

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?

Hi Andrew,

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.


I suggest the simplest solution:

  1. Share your session for weekly selected parts. It’s because

  2. Check out such separated parts in the Canadian CSRS-PPP system. An example is my checking EMMA001A.pdf (1.4 MB)

  3. Download the observations from the two closest IGS reference stations: MQZG00NZL and DUND00NZL

  4. Postprocessing RTKPOST should give centimeter accuracy since PPP gives such good results.

Awesome thanks. So separate my data into 7 day chunks? And then use the IGS stations as my base station data in RTKPOST?

I suggest such a project analysis procedure:

  1. Change the format of your RINEX to version 2.11
  2. Use only the 7-day observation sessions for analyzes in the PPP method (CSRS-PPP)
  3. 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
  4. In addition to the PPP method, i.e. in the ‘Static’ method, use only daily solutions, i.e. sessions no longer than 24 hours.
  5. 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?


Alrighty will see how I go with breaking it down into smaller chunks. Thanks!

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).

Cool will look into that

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.

1 Like

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.


Report_VRS-EMMA_23_02-2018.pdf (177.5 KB)
vrs10540.pdf (1.5 MB)