Questions about post processing RTKLIB+CRX2RNX

Hi everyone,

I received last ween my two Reach RS+ units and I am starting to do my firsts tests. Before I begin describing the problems, I have to say that I am a newbie to GPS surveying - that might be the the key problem-. Like some of you, the aim of all this is to get GCP’s GPS coordinates for drone aerial surveying.

I describe the situation: I will be working in France, where they have -if I got it right- a CORS network (http://rgp.ign.fr/) with a free online post-processing service (http://rgp.ign.fr/SERVICES/calcul_online.php), where your data are post-processed with static values from several stations. The only thing, and here is where I start having problems, is that they require input data to be whether Rinex (.yyo), Rinex compressed (yyo.zip), Hatanaka (.yyd) or Hatanaka compressed (.yyd):

After having read the Emlid Quickstart guide, the tutorials on how PPK works and GPS post-processing (https://docs.emlid.com/reachrs/common/tutorials/gps-post-processing/) I decided that the most appropriate for my work will be doing PPK to obtain the GCP’s GPS coordinates. Hence, I downloaded the Windows version of Emlid RTKLIB to do the post-process. Besides I found awesome information about how setting the Reach RS+ for PPK surveying in this post:

Later on I found this other thread which explains exactly step by step what I want to do:

I finally got my raw dataset from my base station, both as .ubx and as rinex file. When I use the .ubx dataset I follow the instructions in the tutorial on post-processing (https://docs.emlid.com/reachrs/common/tutorials/gps-post-processing/), so I can have the data transformed in rinex format. No problem so far. One way or the other, I get a set of files in format .obs, .nav., etc…
.
Following this post:

And instructions from http://sopac.ucsd.edu/hatanaka.shtml , http://terras.gsi.go.jp/ja/crx2rnx.html - from where I downloaded the software - I try to convert my set of rinex files (.obs, .nav., etc, obtained from RTKLIB) into a format accepted by the french post-processing online service - that is, Rinex (.yyo), Rinex compressed (yyo.zip), Hatanaka (.yyd) or Hatanaka compressed (.yyd). Here is where I am afraid that I start mixing things up… How can I get these kind of files, for instance “.17o”, from my raw data using RTKLIB? I have seen, downloading the data from CORS station, that some of the files provided are, for instance “fjc2286z.18n” or “fjc2286z.18o”. However I have not been able, using the CRX2RNX tool or the RNX2CRX to compress any file to any format. Here is an example of the error that I get:

Before running these commands on dos I followed the instructions in ftp://www.pecny.cz/pub/sw_3rdParty/RNXCMP/4.0.3/docs/RNXCMP.txt . So I pasted all the .exe and .bat files in the same directory where I am running my tests and I previously established the C:\Emlid directory as “path” where the .exe should look for files.

Anyway, I am unable until now of producing any rinex - compressed or uncompressed- files in the required format required by the online post-processing service. I am sure that I am mixing up -not only one but several- things. Could it be possible that files with format .18o or .17d are only produced by CORS stations? Why are not rinex files provided by RTKLIB in the format “.yyd” or “yyo”? Is it possible to generate them from RTKLIB+Hatanaka tool? Should I use any other specific software?

By the way, I have seen, thanks to other posts, that it is possible to do just what I want but by reversing the process; that is, downloading multiple CORS station information and putting it to work in RTKLIB:

I am sorry if my post is too long or too dificult to follow. I think I am mixing up a lot of stuff. Feel free to ask questions and tell me where I am wrong! Any hint in any direction would be much appreciated :slight_smile:

Thanks a lot in advance!

Cheers,

Ruben

Hi @RGR,

Really appreciate such detailed issue description :slightly_smiling_face:

Why don’t you want to use this way?
You can download station RINEX file for the period of time you need and process it with rover log in RTKPOST.

Hi Andrew,

I guess, we could say I’m stubborn :sweat_smile:

I think the only option that I have left is the one that I found and that you propose. I have done some further research and it seems to me that files with extensions such as .18o, or .17n are only provided by the CORS stations:

The thing is I still can’t compress the files with the CRX2RNX tool so I can give a try to the french online service. Then, I wonder how is it possible that 1) why do they ask to upload files that are only provided by permanent stations and 2) how can I compress files with CRX2RNX. I have seen people in the forum telling they succeeded… Would there be anybody so kind in the forum to get some screenshots?

Thanks anyway,

Ruben

Hi Andrew,
Ruben raised an important point here. It is evident how failure to keep RINEX stanfards causes trouble for users. A request to the EMLID team to stick to RINEX standards and instead of * .obs, * .nav, * .gnav etc … use * .yyo, * .yyn, * .yyg etc.

Hi Ruben,
Work with rtkconv and manually change the extensions to conform to the RINEX standard: obs = 18o, nav = 18n, gnav = 18g etc. This is it :slightly_smiling_face:

RINEX standard:
image

Richard

Hi @RGR,

Can I ask you to share your raw logs so that I can try to post-process?
You can send them to DM.

Thanks.

Hi @r.pazus,

Thanks for the suggestion :slightly_smiling_face:

As you can see, .obs .nav, .gnav are the same as .*o, .*n, *g files respectively.
There’s no difference except extensions.

Regarding RINEX standard, I can’t find any info about .yy*.
Can you point where I can find it in up-to-date RINEX 3.03 standard?

Thanks.

Hi Andrew,

no need of sharing raw logs. I’m actually able to post-process data the way you suggested.

My issues are related to the compression tool CRX2RNX and how to use it.

Thanks anyway!

Ruben

Hi Richard,

thanks by your suggestion!

I just changed the file format (as simple as you suggested) and it worked! No need to use the compression tool! So simple I didn’t even think about it…I just uploaded a file .18o (RINEX 2.10) to the online service without any problem. Well… I think I will have to wait for a couple of days :sweat_smile: Lucky me, it’s only tests that I am running.

It is very true what you say about the different file extensions, but I don’t think it is only an Emlid thing. If you are new, as I am to the topic, it is quite difficult to understand what all these extensions are about. That is what led me to think that I had to use the compression tool CRX2RNX to convert the .obs files to .18o, for instance… In addition, the fact that the website I want to use is in French and their explanations are not easy for newbies, don’t make things easier either. Here is the link (only in French, I’m afraid): http://rgp.ign.fr/DONNEES/format/

Thanks again!

Ruben

1 Like

Hi Andrew
These explanations in the French active geodetic network RGP are arguments to do this ‘make up’ :slight_smile:with the rinex extension. by EMLID There is a good description of it.

ftp://epncb.oma.be/pub/data/format/rinex211.txt
ftp://igs.org/pub/data/format/rinex303_update1.pdf
Acknowledgment: RINEX Version 3.02 and 3.03 is based on RINEX 2.11
Regards
Richard

Thanks, @r.pazus, I’ll look through theese docs.

Hi,

after a couple of days of waiting, I got a message from the French online service saying that my RINEX files were not readable. So, they could not process my request.

I think that might have to do with the file’s header. What I do not know is why that happens. If I download the station data, RTK software can work without problems with it (even multiple stations, using wild cards). But not the other way round… I don’t know. Here are two screenshots of the headers (the first one is from the station; the second one, from the REACH):

The only explanation can be that when you upload data to the online service, they must be, as their stations’ data, in format RINEX 2.10 or 2.11. I will keep you updated once I’ve tried that.

Cheers,

Ruben

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.