Very long static RINEX v.2.11 from ReachView 2.9.3 does not process well

Hi Emlid,

Please see the following RINEX file created by ReachView 2.9.3:

For some reason after fixing the header observation bug (take off L2 observables) does not correctly process in rtkconv_emlid_b27.exe

After many tries I seem to have achieved some success by filtering the RINEX with TEQC command “teqc -n_GLONASS 26 -S -E raw_201712152107.obs > test.obs” this eliminates Galileo and SBAS entries (not needed for my post-processing) but also gets rid of many unnecessary empty spaces in the RINEX.

After using TEQC I can process in rtkconv_emlid_b27.exe from 2017/12/15 21:08:15 to 2017/12/16 01:17:15, from 2017/12/16 10:22:40 to 2017/12/16 11:47:05 and from 2017/12/16 12:59:45 to 2017/12/16 19:59:55 the epochs outside those time frames are not processed.

The fixed base station files (3 stations) can be downloaded from:

Any ideas of what may be happening? And how to process the whole file?

PS: the rover RINEX file is unnecessarily large because it has been recorded at 1Hz instead of one epoch every 15 seconds (please add this feature).

Many thanks


Hi Isaac,
These are the consequences of this error:

The results:
LandSurveyOverview_Session_23h.pdf (970.1 KB)

Hi Pazus,

I have manually increased TEQC GLONASS maximum slot number from 24 to 26 because the data included in the RINEX file from the Emlid receiver had GLONASS observables tagged as being 26 which, by default, causes TEQC to quit the process, I don’t think there is any particular problem with that, RTKlib seems to correctly digest GLONASS SVs with slot number over 24… The big question mark is why there are observational gaps when processing with rtkpost_emlid_b27.exe. Would you be suggesting that the processing gaps are related to GLONASS slot IDs over 24?



UBX file is needed :slight_smile:

Hi Pazus,

Unfortunately I deleted the UBX file from the Reach thinking that it was “redundant” to the RINEX file, boy I was wrong!

Today I extracted a different 24 hour UBX file from my Reach and after converting to RINEX in my PC I got 0 problems, to me it suggests that the real time conversion to RINEX is a waste of Reach resources (CPU + memory) which may be prone to conversion problems… From now on I’m sold to storing UBX only (and convert latter on)…

Thanks for your help

PS: Are you using Spectra Precision Survey Office to post process?


I have experienced problems using RTKCONV to convert long log files from 5Hz UBX to slower (1Hz or 0.1Hz). The problem manifested as large empty gaps in the RINEX files.

As a workaround, I kept 5Hz and just limited the duration of each conversion using start and end time.

Maybe your problem and mine stem from the same cause.

Hi Bide,

My RINEX files do not have empty gaps, the data it is there however seems to be corrupted in some way (not obvious to the naked eye at least)…

Thanks anyway


Not sure this is appropriat or/and valid comparable, but it helps me deside whether to use RAW or processed Rinex from Reach.
From my work with photography and dSLR, RAW format was the only option with postprocessing images back at the office. JPEG files only used for preview, onthfly work and simple tasks or non critical display.
So raw.ubx would be raw images and .jpg is Rinex. Now, Rinex has its benefits, no doubt about it. Just need to apply it under the right situation.

My 2`cent

What is the reason for measuring such long sessions since 10 minutes is enough? See an example here, using VRS RTN (Figure 1)
Postprocessing in the L1 version only

Here is your whole log processed against the GARR base station. I didn’t concern myself with why it is mostly all float. Maybe the coordinates I used for the base weren’t correct. Anyhow, this is just to prove that all the data is there and is usable.

I used Emlid’s RTKCONV to reconvert your RINEX files to RINEX v3.03, and then I used Emlid’s rnx2rtkp (the Linux version of RTKPOST) to process the new RINEX. I chose that program because it can process huge log files that RTKPOST can’t.

1 Like

I couldn’t help but try another one with rnx2rtkp. This was using your supplied RINEX with no additional conversion. Settings were: GPS and GLO only; combined solution; elevation mask 25 degrees; base coordinate set to the average of the single solution.

I made this screenshot of the ground track because it is a much tighter grouping than the previous one:

Hi Isaac, This is an example of postprocessing of your 30-minute session with fixed solution (extracted from 23h), longer than I mentioned because the 15-second interval of VRS and GPS L1 only. From my experience, a 10 minute GPS + GLONASS session, 1 second interval and RTN is just as accurate as the classic static 23h. VRS should be generated from a few hours session.
Lack of ubx file does not allow to determine what is the cause of these failures.
Land Survey Overview ICGC.pdf (208.4 KB)

In addition
Estimated accuracy of VRS from Canadian CSRS, in fact as a relative is much better. vrs13490.pdf (123.3 KB)

Hi Pazus,

The reason I’m measuring such a long observation campaings is because I have a fixed antenna on the roof of my building I I would like to perform ublox neo-m8t raw data reliability studies (it is not cumbersome to perform long observations as it is a lab like environment) in a realistic environment (with multipath and partial sky view).

Eventually my objective is to see if it is possible to use such L1 only receivers for control deformations.

Hi bide,

It really seems like taking off low elevation observations helps to converge the solution, this puzzles me a bit as I made sure the Tallysman antenna (recommendation from ublox) had a good ground plane (19 cm / one L1 wavelength instead of the recommended 10 cm).

Your data looks concerning as there are many (lots of) false ambiguity resolutions…

Ideas and recommendations are welcome.



Hi again Pazus,

Would you mind to explain how did you came up with the results VRS13490.pdf? I’m used to submit RINEX files to NRCan PPP but how did you came up with the dual frequency data, was that a chop of one of the three base stations I provided? If so, what were you trying to prove?



Hi Isaac,
I tried to prove that suspicions about the rtkconv and teqc programs are unjustified. The cause was incorrect preprocessing. This is the topic of this thread after all.
VRS is generated from your three reference stations.
It looks that my good intentions have not been understood.

Hi @Isaac,

I have just processed your files with RTKPOST without any issues.

1 Like

I find this thread quite interesting. Mixing high level profession/accuarcy and how to troubleshoot with different angle of attack. Just the way i like my coffe :wink:

This one confuses me, could you clearify the end goal.
It might be my lack of english skills but to me it sounds like you have two missions here.
1.Study the ublox neo-m8t raw for reliability and consistency data (e.g no gaps in the data stream and so on)
2.Study the L1 only receivers for control deformations

From what i understand, these two topics is different and nr 1 to be somewhat solved (without the .ubx raw file) here
And nr 2 solved by bide, pazus and igor later on.
Does this sound right?

On a different matter, i am not sure putting a device on your building to measure its accuracy is a good idea, not with a tool the actually is capable of measuring sub cm. Unless your building is specially made for this kind. Your building might not be that stable.

This thread raises the following threads:

  1. implementation of surveying heights (instead of ellipsoidal -> geodetic, geoid models),
  2. cartographic projections for the purposes of mapping using drones (coordinates system, local or generic).


:wink:Who starts?