RINEX implementation in ReachView, maybe there is a better way?

Hi Emlid,

Some days ago I collected a +20 hours of UBX raw data with ReachView v2.9.3 (in a bad location so please disregard the quality of the observables as that was not the scope of the test)… Latter on I decided to convert the UBX file to RINEX obs file with RTKconv_Emlid_b27 which worked just fine, it gave me a 78.7 Mb file.
Just recently I tried to run the obs file through TEQC and it wasn’t working so after several unsuccessful tries I decided that instead of trying to run the RTKlib generated RINEX I would use TEQC to convert the UBX to RINEX.
What was my surprise when I realised that the output file was 110Mb! a 28.5% larger than the file from RTKlib even though both were RINEX v2.11.
Immediately after seeing that very large difference I started comparing the RINEX files (TEQC vs RTKlib), what a difference! The File from TEQC had waaay more observables missing in the RTKlib file, in fact the TEQC file had more epochs than the RTKlib RINEX.
For further review you can download the 3 files from https://drive.google.com/file/d/1C5scmofgTIE_QxHYWecjkf0VgmO7yNiP/view?usp=sharing

I suspect that you have no intention to “revise” the way RTKlib is currently converting UBX to RINEX but would you consider using a Linux build of TEQC under the hood of ReachView instead of the RTKconv?

Many thanks

Isaac

Hi again,

I shall correct my previous statement, I did forgot that I disabled Galileo and SBAS in my RTKconv processing meaning that I was not comparing apples to apples (TEQC had Galileo and SBAS enabled) it is still interesting to note that the TEQC file seems to have a few minutes that RTKconv does not record in the RINEX file.

Cheers

Isaac

@Isaac Might be better if you edit your first post to represent how you now see the world and what the remaning issue is…

Not quite on topic for this thread, but I tried converting a .ubx file with standard RTKLIB stable version (v.2.4.2) and it was a no-go. Works fine with Emlid’s version. Is that typical?

The 2.4.2 stable version is really old. Like 4 years or so.
Its recommende to use Emlids version, but you should be able to get results with the latest BETA from RTKlib here (at this time 2.4.3b29)

I’m fine with using Emlid’s version. I just wanted to see if my experience was typical. It looks like the RTKLIB project has stopped evolving. Perhaps it does all it needs to do now.

From my review, I conclude that there are no significant differences in the use of teqc and rtkconv. However, it is better to separate observations into a 24-hour set for postprocessing.
Having Issac’s raw data, I checked their quality. Everything is OK. Postprocessing was done without special preparation, in reference to Polish reference stations. The result is extraordinarily accurate for vectors over 1500km. In connection with the basic postprocessing, a very interesting comparison from Canadian CSRS-PPP shows how the Reach module deals with clock drift. Sigma clock 2-3 nanoseconds is very good result. Congratulations to the EMLID team!



Land Survey Overview.pdf (213.2 KB)

wroc3421.pdf (131.8 KB)

reach3430.pdf (144.0 KB)

More tests here.

2 Likes

Hi Simon,

Thanks for your suggestion, I will try to edit my future posts to conform with your thought. Please let me leave the current one as it is.

Isaac

Hi Pazus,

Amazing result using Polish base stations, I concur, regarding the RINEX conversion I suspect there are slight differences between TEQC and RTKconv, particularly on how slots numbers are assigned for GLONASS SVs but nothing major (that could significantly affect PPK).

Thanks for your time and effort!

Isaac

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