When I convert a .UBX static file to RINEX, using rtkconv (Version ‘demo5 B31’) requesting 30 second epochs:
with these options:
for submission to NGS OPUS, I get a RINEX file that has epochs that are 0.003 seconds offset:
Is there an option / setting to align epochs to the nearest second?
Thanks
Mark
Hello Mark,
This is how internal clocking in the receiver works, so there is no option to change it. This is completely in line with RINEX spec, so should be processed by software just fine.
I can confirm that after post processing in rtklib in kinematic mode, the resulting time stamps are rounded off to nearest 1 second intervals if this was set in both your base & rover recording intervals.
My target software is NGS OPUS. I have tried collecting .UBX files and converting them, and RINEX files directly with 1-second rates. In both cases the submitted files are rejected by OPUS with this message:
1009 WARNING! No antenna type was selected. No antenna offsets or
1009 pattern will be applied. Coordinates with reduced accuracy
1009 will be returned for the antenna phase center.
1009
1020 OPUS aborted on the submitted data file for one or more of the following
1020 reasons. OPUS cannot process the data file.
1020 1. Collection interval of the data file was not one of the allowed rates.
1020 The intervals that are accepted are 1,2,3,5,10,15,30 seconds.
**> 1020 2. The time of each epoch is offset from one of the above intervals. The **
> 1020 seconds epoch field must coincide with one of the above rates.
1020 3. The data file may have been collected in kinematic mode. OPUS does not
1020 process kinematic data files.
1020 4. Note: OPUS processes data every 30 seconds, and 2+ hour files
1020 collected at the 1 second rate should be changed to 30 seconds.
1020 5. If your data were collected today or yesterday, we may not have
1020 sufficient CORS data - try resubmitting your file tomorrow.
1020
I think that item 2 “…epoch is offset…” is probably the offending issue (I have waited several days for submission.) Is there a document that describes a “known to work with OPUS” workflow?
Thanks!
Mark
Hi Mark,
We tested RINEX files recorded on Reach devices with OPUS, and they were processed just fine, so the time format shouldn’t be an issue for that.
May I ask you to share your UBX and RINEX files so I can look into them and check what might be a reason?
I have placed a .ZIP file at this location: [ 2Jobs ]
It contains two jobs and a small readme1st.txt file that describes the jobs.
Thank you!
So I tried to upload an RS2 rinex file to OPUS and indeed it says it does not accept uneven time intervals. Here’s the error message:
FILE: raw_201909010241.obs OP1574490382693
1020 OPUS aborted on the submitted data file for one or more of the following
1020 reasons. OPUS cannot process the data file.
1020 1. Collection interval of the data file was not one of the allowed rates.
** 1020 The intervals that are accepted are 1,2,3,5,10,15,30 seconds.**
1020 2. The time of each epoch is offset from one of the above intervals. The
** 1020 seconds epoch field must coincide with one of the above rates.**
1020 3. The data file may have been collected in kinematic mode. OPUS does not
1020 process kinematic data files.
1020 4. Note: OPUS processes data every 30 seconds, and 2+ hour files
1020 collected at the 1 second rate should be changed to 30 seconds.
1020 5. If your data were collected today or yesterday, we may not have
1020 sufficient CORS data - try resubmitting your file tomorrow.
1020
There is such an option. Try ‘Time corr’.
Tried the settings that you suggested and still getting time decimal part. I think Emlid should address this issue as using OPUS is a vital part of post processing. I would like to say that post processing in Magnet or RTKLib has no problems with the decimal time. Only in OPUS.
partial results
19 9 1 21 53 56.0040000 0 12G11G 1G30G23G22G18G 8G 7G 3G17G 9G16
21599716.394 113507270.523 -109.009 45.000
21290572.811 111882707.293 1036.818 48.000 21290549.497
87181237.101 807.581 39.000
24320266.517 127803856.183 3068.195 42.000 24320243.227
99587329.263 2390.882 38.000
24957100.704 131150440.392 -1816.876 38.000
24356228.309 127992846.235 1840.049 28.000
21313367.877 112002500.392 -616.185 45.000
23537164.662 123688626.648 -1754.385 43.000 23537140.769
96380648.280 -1367.124 35.000
22053013.681 115889360.884 1765.540 48.000 22052987.766
90303301.340 1375.720 38.000
25182045.647 132332532.599 2159.888 43.000 25182024.515
103116161.269 1682.794 34.000
26248465.569 137936621.5561 1479.559 41.000 26248436.336
107482959.188 1152.178 34.000
24895375.425 130826102.679 -1440.906 40.000 24895351.019
101942206.197 -1122.473 36.000
25539404.744 134210474.205 -1233.297 32.000
19 9 1 21 53 57.0040000 0 12G11G 1G30G23G22G18G 8G 7G 3G17G 9G16
21599737.218 113507379.742 -109.467 44.000
21290375.652 111881671.010 1035.904 48.000 21290352.285
87180429.602 807.121 39.000
24319682.660 127800787.952 3067.970 42.000 24319659.424
99584938.437 2390.565 39.000
24957446.334 131152257.310 -1816.925 38.000
NRCAN processes the files just fine. Would that be an alternative to OPUS?
I checked it on the example of session No. 1 made by Mark Silver raw_201911152137.UBX. It works.
If you uncheck the time corr box will the time decimal part appear again?
If I uncheck the Corr Time box after this operation, the decimal part no longer appears.
So when does the decimal part appear in the rinex file? check or uncheck? I have tried every combination in the options page & I am still getting a time decimal part,
Hi @tatiana.andreeva , here’s the UBX file link with the uneven time event.
https://www.mediafire.com/file/u97htvajs1j4srr/raw_201909012153.UBX/file
To check or uncheck, this is the question 
Time decimal part it only appeared once when starting the program. The program version is probably important. I have it 
Regards
00003190.obs (564.9 KB)
Do you remember where you got that version? My version has a b33 suffix.
Sorry, I will answer tomorrow.
I read that NRCAN PPP does not use existing GPS stations/CORS. It’s a PPP process which has meter level accuracry. Maybe I am wrong so correct me if I misunderstood its process.
The version I used is probably 2.4.3 b5. It is described here:
