A post was split to a new topic: Incorrect baseline for RS+ v2.22.4
Thanks for this update.
I have done a confirmatory test session. I still expect such confirmation from users who also reported this to me.
I attach the survey report. Unfortunately only in Polish, because this external controller has no foreign version.
greetings
2020-04-16_21-19-18.zip (4.6 KB)
Session made with Reach RTK module, RTN method, data stream: RTN3G_VRS_RTCM32 (GPS + GLO + GAL)
1 Like
I also did an additional test for checking of cycle-slip detection and repair in the new version 2.22.4. For this purpose, at the same point as previously, I briefly interrupted the reception of satellites by covering the antenna by hand. This time, the solution was always ‘fixed’, it gave the same result. However, with a longer break reinitialization, it is sometimes frozen. It can be seen here:
Quality checks can be carried out in many ways. And so, e.g. with teqc.exe:
qc.pdf (74.5 KB)
You can also use the CSRS-PPP report:
raw_202004171629.pdf (920.8 KB)
Or simply do it on the basis of the ‘Land survey report’, where individual results were recorded.
raport_test_17_04_2020.zip (4.5 KB)
From this conclusion that in this version 2.22.4 this problem has probably been optimally solved.
However, there are still cases, already signaled in several threads, freezing the process of initialization and re-initialization. This occurs when the solution ‘float’ remains in a place like this:
Here in this test it is RTK method to the remote 20km reference station so such freezing is justified. Manual parameter change definitely speeds up the re-initialization, for example, a minor change, e.g. in RTK Settings elevation mask by one degree or GLONASS AR mode. I guess this can be done programmatically. This problem did not occur in earlier versions before reflashing so it may be worth returning to that initialization algorithm for one-frequency receivers. Maybe this should to be worked out in the next version.
The test concerns the Reach RTK module.
I include raw data throughout the session:
raw_data_test_17_04_2020.zip (3.1 MB)
4 Likes
it would be nice to have a refresh button for NTRIP mount point list.
1 Like
and it would be nice if ReachView M+ or M2 could show the number of events marked so that we could compare to the photos taken.
It can be seen that after the discussion EMLID team left in this new version 2.22.4 active frames for ‘Base coordinates’ and selection of ‘RTCM3 messages’ with inactive base mode. This causes the user to doubt whether it may conflict with the measuring procedure if he only works with the receiver as a rover with NTRIP. Please, dispel these doubts.
1 Like
It would be very good, that when configuring in static only enable the base coordinates and in kinematic that it cancels the entry of the coordinates
‘Rover’ with NTRIP is a ‘rover’ irrelevant or ‘static’ or ‘kinematic’. ‘Base’ is what we get from NTRIP (point or VRS). 
I am thinking when one does not have ntrip availability and I generate my own ntrip or for when I do PPK and it is not confused between base and rover
2 posts were merged into an existing topic: Difficulties in obtaining fixed solution during initialization time for Reach Module
Hello. I’d like you to see my post on M2 RTK solution: ReachView LLH vs RTKNAVI DEMO5 data analisys.
I think you will like it.
Hi! I’ve seen many good things about this update especially the improvement on the RTK fix. I’ve tried looking for the ReachView image for this update (v2.22.5) but can’t seem to find it. Can anybody please put up the link?
Thanks!
thank you so much, i have succeeded ini updating my firmware to ReachView v2.22.5!
1 Like
only see the firmware file: reach-rs-v2.22.5.zip, or it can be used on any Reach devices including RS2 and M2?
You can find the image for Reach M2 in Reach M2 Firmware Reflashing guide and image for Reach RS2 in Reach RS2 Firmware Reflashing guide.
Please note that we don’t suggest reflashing the devices without our recommendation.
1 Like
Hello, guys!
We just released v2.22.6 . The list of changes is available in the first post of this thread.
Hi ! Will a dev version appear updating the RS + error of the flashing green led? or do I have to go back to stable version 2.22.6?