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.