Post-Process in RTKLIB - CORS Station

I have a single reach module (with supplied tallysman antenna), reflashed with the current image, running the most up to date reachview app and rtklib 2.4.3. My goal with the system is to be able to survey GCP’s for UAV surveys.

I’m slowly learning the in’s and out’s of what it takes to post process points, but, I am still pretty new to the game so bear with me!

As a test, I set my reach system up to observe (using the “single” default in reachview) for about 30 min in the same location. There is a CORS station a few miles away, so I figured I could correct the observation and see a very tight grouping of points.

I downloaded the .cls and .sp3 files as well as the files from the CORS Station (WIL1)

In RTKPOST, I set the the .obs from the 30 min observation to the “RINEX OBS”, and the base station to the observation file from the CORS Station. I added the nav file from the CORS station and .sp3/.clk files in the next set of boxes. I kept all the options at default and when I hit execute, it processes and the green status bar works it’s way to the right then back to the left (Q=0 at the end of the status bar). When I select Plot, I see the message “no solution data” at the bottom left of the screen.

If I keep all things the same, but substitute the nav file from my 30 min observation for the nav file for the CORS station and execute the process, the status bar works its way to the right (and I see Q=5) and finishes. If I choose “Plot,” my ground track is shown in red. Given the grid size and the ground track visual (up to 12m deviation), I don’t think the signals were corrected.

Has anyone been able to successfully perform a routine that post processes collected data from a single Reach module? I’ve seen that @igor.vereninov has mentioned preparing a tutorial on how to post-process raw data logs - is that available?

Thanks for your help!

1 Like

I’m no expert but have been post processing my Reach solutions, sometimes with local CORS data. In the first instance, I wouldn’t worry about the ephemeris files (.sp3/.clk) - just stick to the defaults and run with your obs & nav data against the CORS obs data. One thing you could check is that under your positions tab you are setting the base station position (you should be able to set this to Rinex Header) - this is typically the thing I forget to set that stops me getting a solution. Once you’ve got things going you can explore further, using ephemeris files & precise corrections etc.

Hello matt1973

I´m new to reach rtk and I´ve just started trying to configure a couple of devices. What I´d lilke to do is to have the base record corrections and the rover record raw data and I´m planning to use rtklib to do the postprocessing. At the moment I´m more interested in getting a good fix for my GCPs.

BUT I´m not sure how to configure the base and the rover to do this. Can you you advise?


Hi Trasvi,
I’m not really the person to ask, as I am just fumbling my way through RTKLIB post processing myself. However, I believe that you cannot use the Reach in “base” mode and also record raw data for later processing (Igor can correct me if I am wrong). Therefore it is “one or the other” as regards live corrections or post-processing. For post processing I simply log in the default “single” profile, using GPS + Glonass 5Hz (I have no interest in real-time RTK).

To the OP: one other thing you might want to double check is that your CORS observation data and your recorded observation data cover the same time frame. If not, you won’t get a solution.

Thanks matt1973!

I’ll try using them as single devices.

My CORS is too far away,I’m working in remote environments in Mexico, so I need a base for the corrections.

I am no expert but I am slowly getting better at post processing. My settings with a base station inside 10 km that seem to get the most accurate results are:

I have not touched the rest of the options. I am getting the following…

The “green fixes” are where the accurate position is. Within a 1-1.5 cm radius. Not bad for a L1 only module but you need good conditions.

If you have a base a long way from the rover (long base lines) using the “Estimate ZTEC” for the ionosphere works quite well. I have used this for post process of L1 signals on two base stations over 120km apart. The results where within 5 to 10cm from the actual position. For closer base stations it does not work as well though and broadcast ionosphere models appear to work better.

If anyone has any suggestions to improve the position with the post processing, I would welcome them.