I’m setting up a base on a new location (i.e., coordinates are unknown) using CORS data. I logged data for 2 hours at the location and I know what to do with that data. I have downloaded data from a CORS site (in US) from the User Friendly CORS site. Here’s a view of what I selected:
I realize that I need the .sp3 file, but which others do I need?
Heres what the Readme file says about the extensions:
.18o - GNSS code and phase data
.18n - Broadcast GPS orbit information
.18g - Broadcast GLONASS orbit information
.log- current and historical data for CORS site (pretty sure I don’t need this one).
The RTKLIB manual is not particularly helpful here.
As a reference, here are my settings: First, I reset to factory settings (I’m fully updated- v. 2.11.0) and only changed the following (not that all broadcasting was turned off).
RTK Settings Tab
Positioning Mode= Single
GPS AR mode= Fix-and-Hold
GLONASS AR mode= On
Elevation Mask= 15
SNR Mask= 35
Max acceleration vertical- 1m/s2
Max acceleration horizontal- 1m/s2
GNSS selected: GPS, GLONASS, GALILEO, SBAS (BEIDOU is grayed out)
I realized what I was doing “wrong”. The data that I collected is entered as the “Rover” (even though I am trying to collect data so that it can become a base). The CORS station becomes the “Base” temporarily for the purposes of post processing the data from my device so that I can then use that location as the manually-entered location for my base (and then use the rover to collect data).
Here’s the files that I am using:
For those of you who haven’t done this before- The .18o is the “Observation” data for the CORS site. The .18g file is the navigation date for the Broadcast GPS (.18n is GLONASS) for the CORS site. The .sp3 file is the IGS Ephemeris.
I have some questions about the “Options” settings, because the situation does not match the GPS Post-Processing Tutorial. I have questions about the items marked in red in this image:
.
If I set the elevation mask to 0 and do not use the SNR mask, I seem to get many more “Fix” (i.e. Q=1 in RTKPLOT) points in the resulting solutions. For example, I tend to get between 57-72% Fix points (c. 10,000-13,000). However, the errors tend to be high (c. 10 cm E, 20cm N, 25cm Up). However, if I use 15 for the elevation mask and 35 for the SNR mask (“rover” only), I tend to get different errors (in the range of 6 cm E, 16 cm N, 49 cm Up), but that is only with c. 10% Fix points. The most important part is that these solutions tend to be different (e.g., Up is c. 30 cm different). So, what is the preferred solution here? I can see which would be most precise, but, of course, accuracy is also important.
The second part is, what do I choose for “Ionosphere Correction”, “Troposphere Correction” and “Satellite Ephemeris”?
I believe I collected the appropriate data from the SBAS satellites- can I use that for both Ionosphere and Troposphere? Should I use the “Broadcast” or “SBAS” for Ion and “Saastamoinen” or “SBAS” for Troposphere?
I am pretty sure that I should be using “Precise” for Satellite Ephemeris (that’s what the .sp3 file is), but when I use it, my errors tend to increase (by around a factor of 10). “Broadcast” gives much lower error, but the locations are different (which would be more accurate?) Please let me know if I should be using “Broadcast” or another option.
I can only recommend to go out to a known point, and then collect data the same way.
Then change the parameters until you get the closest match in XYZ space. Then use this for your processing going forward.
Also, if you get out the raw .ubx from the Reach, you can also get an Sbas file when converting.
However, like your finding with the sp3-file, I couldn’t see much difference in precision, using it.
One thing that does a lot for reliability is setting Filter Type to combine. It takes double time, but worth it.
By advice from @TB_RTK and through experimentation (as mentioned above) I would also recommend to set GPS AR to Continuous when handling static processing.
Optimal for what for purpose ?
Clearly there must be a great deal of difference between doing static processing and kinematic processing, as the premise change?
I’ll see if I can find a known point again. It’s not as easy as one might think. There is a survey store near by, they may have one for calibration of their instruments.
I also post-processed using “Continuous.” It improved the the error and increased the # of “Fix” points, but the difference is not huge. Error is still pretty high. I’m glad to hear you say this, however, because “Fix-and-Hold” always seemed a bit risky. Do you use Continuous for Kinematic as well?
Here’s the plots (left= Fixed, right= Continuous):
Are the default settings appropriate for every purpose? It seems like they are set for the rover in kinematic mode. With the raw settings can they take into account ephemeris? If I just put the .sp3 file in will RTKLIB know what to do with it? Or do I need to change the “Satellite Ephemeris/ Clock” setting?
I just ran with default settings from RTKLIB ver. 2.4.3 Emlid b28 with just the obs (from “rover” and CORS base) and nav (from CORS base), but got “no data solution”. **** Ignore this comment- I entered the wrong “obs” data fro the CORS base will try again.
Use “set timeframe or period” under options in RTKplot, this will display only fixed period when you set timeframe to a period with only fixed solutions.
With the correct files, here’s what I get with the default settings in RTKLIB (ver. 2.4.3 Emlid b28). I would definitely like lower error, especially on the “U” value (which is just as important to me as the other two).
That’s why it would be nice to perform the same amount of data-collection on a known point. The RMS can be way smaller than the offset from the real point.
Seperating the Q’s seems like a good idea. Especially here where the majority is infact Q1. I just tried doing this on a 24h dataset, and the rms actually got slightly bigger, but the ORI is still within 1 cm of the CORS coordinate (also in the z-axis).
.
