The same problem is for Reach RTK. If reflashing from 2.18.0 to version 2.22.3 was performed it is not possible to make correct session via NTRIP. For Reach RTK, which received version 2.22.3 through upgrading, this problem does not occur. For documentation, I enclose today’s test. It should also be noted that the ubx → RINEX conversion and RTCM3> RINEX conversion is incorrect. Users who have not decided to reflashing version 2.18.0 are still satisfied. If we had to provide their observations for comparison, we are able to add them. Hence a request to find a reason.
Additional quality control via CSRS-PPP gives additional confirmation. The report is attached
raw_202004060616.pdf (994.5 KB)
in the zip file:
base_202004060616_RINEX-2_10.zip (2.2 MB) base_202004060616_rtcm3.zip (2.2 MB) raw_202004060616.zip (771.8 KB) Uploading: raw_202004060616_RINEX-2_10.zip… solution_202004060616_LLH.zip (332.9 KB)
Hi Ryszard,
Thank you for your report. You are always very helpful with bug reports, really appreciate it.
It seems that something is indeed wrong with RINEX 2.11, while RINEX 3.x looks good. I understand that CSRS requires 2.11, we will try to fix this as soon as possible.
Could you please add more details on this one? Do you mean that it is not possible to connect to a caster, or there is some issue with positioning?
I sent 2.10 as it was directly from Reach VIew, compressed with navi data, i.e. base_202004060616_RINEX-2_10.zip (2.2 MB) .
RTN40981.pdf (1.1 MB)
If you create from RTCM → RINEX then there will be a difference, but it doesn’t matter if RINEX2.10 or RINEX3.03.
JOZ20980.pdf (1.3 MB)
JOZ2000000_U_20200980351_00U_00U_MO.pdf (1.3 MB)
That’s what I’m trying to prove. The point here is that the iteration process is very long on some receivers, those after reflashing. In my opinion, this is due to changes in the Reach View reflashing packages for Reach RTK. There was a period when this package was changed several times.
That is why I compared the measurements with two receivers from Reach RTK via NTRIP. In one data stream was RTN, which measures the short vector, several meters. In the second, it was RTK data stream to a 20km distant station. The measuring conditions are the same. It turns out that for RTN there is no fixed solution for 10 minutes, while for RTK it was only 50 seconds. It’s a bug in the application which was not Reach View version 2.18.1 and 2.20.8. In these versions RTN is faster than 50 seconds.
I made the test on two points, as in the picture:
SPYC RTN solution fixed after 10 minuts !!!
Start 2020/04/06 6:17:06 Q=1 at 6:27:32
SPXE RTK 20km solution fixed after 50 seconds
Start 2020/04/06 6:15:40 Q=1 at 6:16:31
solution_LLH.zip (650.4 KB)
base.zip (4.7 MB)
It will be probably worth it to go back to the algorithm as version 2.20.8 if is difficult to find the reason for such a long initialization.
Request for change of title to the thread: Difficulties in obtaining fixed solution during inizialization time for Reach RTK.
Hi Ryszard,
I’ve checked your solution and RTCM3 data and haven’t noticed anything strange or unexpected from them. The quality of the base’s raw data is quite good in both cases, so it seems as there should be no issues with getting fix.
May I ask you to share the raw data from the rover recorded during these tests, too? I’d like to try to post-process them and compare them with RTK results.
Also, could you please elaborate on which exactly RTCM3 messages these stations provide? You can just share the screenshot of the Correction Input tab while receiving the corrections from these stations with an opened list of incoming RTCM3.
Thanks.
Hi Tatiana,
Thank you for checking.
I enclose this supplementary data. I described this case further in the thread here. PPK here, but it’s about real-time difficulties, i.e. RTN.
Hi Ryszard,
Thanks for sharing! I’ll look into the data and get back with any update or additional questions.
Ryszard,
May I also ask you to check if the same issue persists on the latest v2.22.4 stable version? There were some improvements in RTK performance there.
Hi Tatiana,
I moved the topic to the main thread and additionally checked the ‘638’ session using GNSS Solutions, which shows extremely good accuracy. This is the rapid static method (RS). Here I think the reason is a change in the RTCM to NMEA in ‘Correction Input’ (GGA message). I will try to show it in another example.
Raport_RS_638.pdf (628.2 KB)
If we simulate in GNSS Solutions that this is a kinematic session then the program will treat the observations as Stop & Go with showing epochs as ‘float’. I enclose it, because it can be helpful. Such sessions can easily do yourself for confirmation of my suppositions.
Raport_PPK_638.pdf (401.6 KB)
Performing today v2.22.4 quality control I noticed the still unsolved problem of float freezing and, compared to v2.18.3, unacceptably TTFF (warm, normal Time to first fix), which should be less than 1 minute.
In the first postprocessing session I show the part in which after a short screening of the antenna by hand the Reach View remained as ‘float’, despite the fact that it looks like it should be ‘fix’. This can be seen in the screenshot reproduced. This forced me to ‘Reboot’ which resulted in a separate session.
In this session, in turn, with a short TTSF (Hot Time to Subsequent fix) there was a long unacceptable period of re-initialization (15 min.).
These two sessions I made by RTN with the following settings without moving the receiver.
Full documentation is available for download attached.
The results are presented graphically from postprocessing (of course option forward only), performed by RTKPOST-QT ver. 2.4.3 Emlid b33 recommended by EMLID. I wrote about my doubts before, whether it is a good choice to use the unstable version - the author T.Takasu warns that this is a development version. The 2.4.2 pXX is the stable version with the newest patches. The 2.4.3 bXX is the development or beta version with experimental implementations.
With the improvements, of the following versions you can see that the RTN method makes more trouble in Reach View, while simpler algorithmically RTK method much less.
Until now, the lack of results of this discussion.
The quality of RINEX obs files was checked by CSRS (reports attached).
raw_202004250638.obs GPS & GLONASS NRCan Ultra-rapid
raw_202004250709.obs GPS & GLONASS NRCan Ultra-rapid
Warning: No antenna type RINEX header record was found. Phase Centre Offsets and Variation could not be applied. Estimated height should be used with caution.
Warning: Although the RINEX header indicates dual-frequency data, only single-frequency data is present. File is processed in single-frequency.
base_202004250638.obs Error : The next time tag is not where expected at epoch 2020 4 25 6 44 0.00.
base_202004250709.obs GPS & GLONASS NRCan Ultra-rapid
Warning : Although an antenna record was located in the RINEX file, no phase centre information could be found in the IGS/NGS file for your antenna. Estimated height should be used with caution. Ensure that both the antenna type and the RINEX header record "ANT # / TYPE " are valid.
Additional comments 
These two drawings generally do not require my comment. The GGA message is necessary to synchronize the time in a known position for Q = 2.
The session should start from epochs with Q = 2. 
Hi Ryszard,
I moved these comments to this thread so that we can keep the whole conversation in one place.
Would you mind sharing the dataset with me? I’d like to look into that, too.
The solution file may contain Q = 5 (Single) in case Reach is not getting correction at the moment when the log is recording.
But I was waiting for more detailed answers to my questions:
- Why is RTKLIB 2.4.3 bxx used in the stable version of Reach View 2.22.4, which according to author T. Takasu is an unstable version? This is from the first line of the RINEX header.
- Which epoch is the “APRROX POSITION XYZ” line 6 of the RINEX header?
- Why on line 13 of the RINEX header is info on two frequencies if it is a single frequency receiver? I have included the message from CSRS Warning: Although the RINEX header indicates dual-frequency data, only single-frequency data is present. File is processed in single-frequency.
- Why in line 14 of the RINEX header ‘TIME OF FIRST OBS’ the measuring epoch is 49.9900000 sec. and the solution.XYZ file is 50,000
- What is the reason on line 15 of the RINEX header that the session ends with ‘TIME OF LAST OBS’ at 23.595 sec., I.e. from 0.005 sec. interval deviation?
In addition, there were questions:
- Why for the option when the base is from the RTCM stream provider (here called NTRIP) where ‘Base mode’ is OFF, the frame ‘RTCM3 messages’ is active? After all, we have no influence on what we get from the VRS service provider?
- Why if ‘Base mode’ is OFF, the ‘Base coordinates’ frame is active? If this is not a program error, for this option it should be transferred for the RTN (VRS) option in the ‘Correction input’ tab.
This is not just a thread about the initialization stage. Re-initialization, in which there is ‘freezing float’, looks worse. The advice to give ‘Reboot’ is strange, after all, with some initial assumptions, it should do the application algorithm.
Here I attach this session after Reboot. It is also a spectacular example of these previously described faults. RTKPOST gives good results
raw_000000_U_20201151602_00U_00U_MO.pos
but during the session, the status ‘fix’ was only shown for 1 minute, from 16:01:46 to 16:02:54
solution_202004241600.XYZ
With so many faults, it is not possible to use the Reach View 2.22.4 application for the Reach RTK module (current name: Reach).
base_202004241600.zip (311.7 KB) raw_202004241600.zip (1.5 MB) raw_000000_U_20201151602_00U_00U_MO.pos (416.7 KB) solution_202004241600_XYZ.pos (383.6 KB)
Hi Ryszard,
The version numbering of RTKLIB is a difficult topic, but I believe that it suffice to say that 2.4.2 has not been updated since 2018. We have built on top of 2.4.3 as it was a more actively developed and better performing branch. We then added our own enhancements, bug fixes and other changes on top of that. If you try to use 2.4.2 on Reach in a real-life scenario it will not work well.
When writing a raw data log, as far as I remember it is the last known position while writing the file, but I could be mistaken. Is this important in some scenario? It is meant to be just an approximate position, as it can’t be precise if we are talking about kinematic sessions.
When writing a correction input log file, it is the position that we get in 1005/1006 message from the correction provider.
This is probably a bug. We will test it.
This is how the HW clock in the receiver works, there is nothing wrong about it. RINEX standard does not say that observations have to be only on integer seconds.
I can see how this could be confusing that when you turn the base mode off you can still see its settings. We are not going to change this immediately, as honestly this did not cause any issue for years and it does not break anything. However, there is a very large UI update coming where we are going to address this confusion completely.
Hi Igor
Thank you very much for these answers. They explain a lot. I have further conclusions from them. Speaking of RTKLIB, I now tend to avoid downloading files in ‘logging’ that have no checksums, i.e. only raw_.ubx, RTCM, and NMEA downloads if needed. The rest need DIY.
I am counting on a new upgrade with the removal of what I call ‘freezing float’, i.e. no re-initialization. This problem now appeared for 2.22.x and was not present in versions 2.18.x and 2.20.x. Here, probably, the unification of algorithms for single- and dual-frequency receivers is the cause. This requires separate computational procedures, especially when for one-frequency short vectors the iono- and tropo- influences are completely negligible.
Here I have a detailed attention, it is not about integer seconds but about the interval, which must always be equal, e.g. here 0.200 seconds for the entire RINEX, otherwise, the system, e.g. OPUS will reject such a file with an unacceptable interval warning.
Thanks again.
Regards
We process them differently. Actually 2.22.x and 2.18.x run the same RTK codebase for single-frequency receivers, so it shouldn’t be different in performance. We have done numerous tests and did not notice a difference between thess versions. After the quarantine restrictions are over we will do more testing to try and find the issues that you described.
OPUS sometimes generates all sorts of errors, but if you wait a little more it will actually process just fine. @tatiana.andreeva can be of more help here, but it seems to be more or less how OPUS works.
Hey there,
Just wanted to add that we’ve released the v2.22.5 firmware update that should resolve the issues with fix reinitialization time. It’d be great if you could check if it works for you.
The full list of the fixes and improvements can be found in this community forum thread.
This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.