RINEX files not on even seconds

and this is the latest from Emlid’s document site

Hi @marcosplata, @jjb,

First of all, I’d like to point out that we thoroughly tested RINEX logs recorded on Reach RS2 receiver with OPUS and may confirm that it should work just fine. I duplicate here some requirements to RINEX files from Reach RS2 that I posted earlier in this thread:

  • The RINEX log should be recorded in Static positioning mode and contain GPS observations only with 1 Hz update rate
  • It’s better to record raw data in RINEX 2.10 format as we used logs in this format for our tests and may confirm that it works
  • The log should be recorded during 2,5 hours at least. According to OPUS, it’s better to use raw data logged for 4 hours

I’ve converted the 2nd file (that was logged during 4 hours with 1 Hz rate) to RINEX 2.10 containing L1/L2 GPS observations in RTKConv and then submit the file to OPUS. OPUS was able to process the file and I got the results. I can share it with you in PM if you’d like.

As for the 1st file (2 hours, 5 Hz update rate), I wasn’t able to convert it to the RINEX file with 1 Hz observations in our RTKLib version. It seems there is an issue with it, and we’ll check how we can fix this.

May I ask you to make sure you uploaded the correct file? This one contains only 12 minutes of data which isn’t enough for PPP.

1 Like

The UBX file is for testing of conversion to RINEX with even seconds. No need for long UBX file. I just want a version of the RTKConv that would give even seconds readings.
What version of RTKConv did you use? Can you give me the download link to it? I want to test it on my longer UBX files for submission to OPUS.
Thank you.

Would this not be a Rinex converter directly from uBlox? As that is the OEM of the gnss chip. Do they knot have one already?

Ublox rely on tecq/rtklib for RINEX conversion

Hey there,

I’ve tried to convert the file using RTKConv version @r.pazus shared above and noticed that this RTKConv provides only L1 observations after conversion. OPUS requires L1/L2 data, that’s why it can’t process this file.

We’ll think about adding this feature to our RTKLib version. Still, this hardly can affect processing with OPUS somehow as OPUS accepts RINEX data with non-integer time values.

You can download the RTKLib version for Reach RS2 in our docs.

I did not realize that, thanks. This must be the case since their binary message structure is published. Even still it would be nice to have an OEM utility as a back-up. They perhaps did not have to worry about Rinex when their market was low-level embedded positioning. Now that they want a piece of the precision market they should re-consider.

I have also noticed that even when I send my static files to the Canadian PPP service. Some times it interprets the data as L1 only and in Kinematic mode.

Perhaps this is occurs when there is not enough GPS SV’s in view with the L2C signal?

The problem here is probably different. There is simply no L2C here and hence only those calculations for L1.

USo I tried to convert the ublox from RS2 using an online RINEX converter
I then uploaded the resulting RINEX files (online & RTKCONV) to OPUS & AUSPOS.

from OPUS, I got a solution for the online converter RINEX file & an error from the RTKCONV RINEX file. for the RTKCONV file it says that it was less than 2 hours even though the RINEX header says it contains 4 hours of observed data.

RTKCONV file error message
> 1007 The RINEX dataset submitted to OPUS failed to pass an initial
> 1007 test for one or more of the following reasons.
> 1007 1. The data only contained values for a single frequency.
> 1007 2. RINEX file not formatted correctly.
> 1007 3. One of the lines in the RINEX file is over 80 characters
> 1007 in length.
> 1007

From AUSPOS, both RINEX files returned processing errors.

may be not a RINEX observation file
or may be a RINEX 3.x observation file
or an empty file or a part of RINEX header file only.
AUSPOS cannot get a solution.
If it is a RINEX 3.x file, please convert it to a RINEX 2.11 file and resubmit.

I think there is an error somewhere in the RTKCONV conversion process. Please someone from EMLID take a look and post for us a correct RTKCONV file,

PS: Rinex files are accepted by OPUS using RTKLib 2.4.3 b33 if you change the time decimal part to .00000 but is rejected if processed from RTKLib 2.4.3 EMLID b28 x64 .

Thank you.

Hi Juan,

Sorry it took so long to get back to you.

We’ve found a way to convert RINEX data from Reach RS2 so that the time becomes an integer. To get the integer time in RINEX data, you should specify the -TADJ=0.1 option in the Receiver Options field in RTKConv Options as it’s shown on the screenshot below:

However, this is not required for OPUS as it accepts standard RINEX data recorded on Reach RS2.

According to AUSPOS, their service can’t work with L2C data. Therefore Reach logs won’t process with AUSPOS. However, AUSPOS is working on the update that will enable this functionality in future versions.

Also, I’d like to point out that RTKLib version 2.4.3 Emlid b28 is designed for Reach RS+ and Reach M+ receivers and, therefore, outputs L1 data only after conversion. I assume that’s the reason why OPUS aborted the submitted data.

For Reach RS2, there is an RTKLib version 2.4.3 b31 that can be downloaded from our docs.


finally!!! it’s on even seconds & I have compared both the integer & decimal converted RINEX files and processed them in RTKLib. The results of the base are the same and the rovers differ only in the x.xxx2 decimal part.

Can you tell me where you got the -TADJ=0.1 option ? Is it written in the RTKLib documentation? Thank you very much for your assistance on this matter.

1 Like

Hi Juan,

This is an internal RTKLib option, we’ve found it in the source code.

Have you been able to successfully upload and process OPUS Rapid Static and Static jobs with your RS2 device since this fix? I am waiting to hear back about this issue also before I make a purchase of two devices. I am also waiting until the RS2 antenna has a calibrated file selection in the OPUS menu. Anyone know when that may occur?


I just reprocessed a Rinex file from RS2 to verify if the uneven seconds would be accepted by OPUS. So i sent 2 Rinex files of the same observation - even & uneven time logging observations.

Both were accepted by OPUS. However the 2 positions varied by approximately 4cm. Please see coordinate output for the same point. I used the NONE antenna option for both sessions.

even seconds output:

SOFTWARE: page5 1801.18 master50.pl 160321 START: 2019/09/01 22:17:00
EPHEMERIS: igs20690.eph [precise] STOP: 2019/09/02 04:49:00
NAV FILE: brdc2440.19n OBS USED: 6312 / 9518 : 66%
ANT NAME: NONE NONE # FIXED AMB: 55 / 77 : 71%

REF FRAME: ITRF2014 (EPOCH:2019.6687)

     X:     -3174537.238(m)   0.062(m)
     Y:      5316667.946(m)   0.083(m)
     Z:      1523461.793(m)   0.037(m)

uneven seconds output:

SOFTWARE: page5 1801.18 master91.pl 160321 START: 2019/09/01 22:17:00
EPHEMERIS: igs20690.eph [precise] STOP: 2019/09/02 04:49:00
NAV FILE: brdc2440.19n OBS USED: 6588 / 7787 : 85%
ANT NAME: NONE NONE # FIXED AMB: 55 / 88 : 63%

REF FRAME: ITRF2014 (EPOCH:2019.6687)

     X:     -3174537.286(m)   0.025(m)
     Y:      5316667.989(m)   0.078(m)
     Z:      1523461.834(m)   0.038(m)

Interestingly, OPUS used more data from the uneven seconds logging file = 85% against 66% from the even seconds logging file. Also there were more observations in the even seconds file - 9518 vs 7787. Don’t know why since both came from the same observation file. My conclusion is the rinex conversion with the -TADJ 0.10 settings maybe removed or interpolated the data to even seconds which was detected by OPUS and thus rejected some of the interpolated data which then led to the difference in final solution? Not sure. Maybe others with more knowledge can chime in. I would like to know the reason.


Is your measurement an occupation of a known control point and are you able to compare the absolute distance between the known point and OPUS point?

When I evaluate GNSS receivers for absolute accuracy I check their accuracy by occupying a known HARN (High Accuracy Reference Network) control station for a 2 hour observation period. Then I upload the Rinex data to OPUS then compare the OPUS results to the published HARN coordinates. Do you have any evaluations of this type that you can share with me? Thanks again.

Considering that there are no Reach RS2 receivers out there for demo purposes (at least not to my knowledge) I am also throwing this out there for anyone that may have actually tested their RS2 as I describe above? If so I would love to get your Test Rinex occupation files so that I could evaluate this for myself.

The point is a project control point used in a survey work. But even if it was an arbitrary point, the 2 solutions should give the same coordinates because they came from the same raw ubx file. The 4cm is small but there should be no 4cm discrepancy. Will try to upload original ubx file later today.

Hey there,

Just like to point out that it’s better to use raw data recorded on Reach directly with uneven time value for PPP in OPUS. These observations are more precise than the ones you get after conversion to the file with even time. In this case, RTKLib interpolates the data which may reduce the accuracy.

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

Hi everyone,

I’d like to revive this old topic to share a couple of options for getting logs with rounded seconds that we’ve added recently:

  • When you record logs in ReachView 3, you can choose the OPUS preset. Here’s a guide about logging data for OPUS in ReachView 3 – it’ll help you set up everything.

  • In case you convert the data in Emlid Studio, you can enable Time rounding in the Convert settings. As a result, you’ll get a log that can be used for further processing in OPUS or other services.