@tatiana.andreeva @igor.vereninov
Hello !!! I attached the reports of the Reach RS + in excellent conditions of PDOP 1.2 when passing under a tree I lose the signal and I wait for it to fix more than 20 minutes and not fixed.
Turn off the Rover and turn on the act is fixed, two times I had to turn off to reset.
I need you to see the configurations or if there is something wrong that can be solved.
It is very worrying for my jobs.
What I also see in the data capture screen that the precisions are in the millimeter order and the solution is FLOATING.
Thank you ! I need help
SystemReport-base.zip (454.5 KB)
SystemReport-Rover.zip (541.3 KB)
I wonder if this RTKlib related. I see the same thing sometimes on postprocessing with RTK, where it simply won’t regain the fix-solution. But changing the start-time of the processing, the loss of signal isn’t seen, it gains the fix right away.
I know this ISN’T a fix for this problem…but sounds like your line work, you may want to consider at least (1) RS2 (as ROVER) since it is now a reality for such troublesome areas L1 may not be good for?
Going under trees etc a lot would drive me nuts personally if losing fix so often… I would assume the RS2 would alleviate all that headache, bus yes, put a HURTING on your wallet… but the price is still WAY MORE REASONABLE than a Trimble, Leica, Topcon multi-freq receiver!
2 Likes
There is also another approach: plan your path of traversing to eliminate (if possible) to avoid being too close to buildings or other things that can significantly block the skyview or introduce multipath.
It is of course not always possible, but something that should be taken into consideration. The direct, visible path is not always the best.
1 Like
in my zone the trees are inevitable, before returning to fixed in instants and not now. something is happening. I do not have money for an RS2 unfortunately, but it is not the solution before fixed perfectly after going under the trees
no building !!! before I did not lose any signal with nearby buildings and in a few seconds fixed. who sends me a reasonable configuration
What about downgrading to the released firmware instead?
1 Like
V 2.17.3 in version 2.17 above fixed without problem
So, you’re saying it wont work in 2.17.3, but worked in 2.17.2 or ?
this is Christian
I use configured arp 0.1 Hz GPS 1 Hz Glonass 0.5 Hz Galileo 0.5 Hz and 5 Hz
I don’t think it is a setup-issue. This could just as well happen with all constellations used for correction.
It is very possible, but I do not know what the cause will be, or the rollover affected emlid. With my promark3 it went under trees and fixed correctly I do not need to turn off and turn on the gps
It sucks to have to turn on and off for sure!
I don’t think it is version-specific as such, but related to the underlying RTKLib engine, as I have seen the same issue there in post-processing.
Can you reproduce this in the post-processing of the file, if you logged during the event ?
As of course, for an L1 system, the cure is to not loose the fix in the first place, thus stay clear of trees 
EMLID no longer responds to these problems, they are more interested in the RS2. At some point in the future I will be able to buy one
I trust that Emlid will continue to support and maintain both product-lines. There are still a huge market for the RS+/L1.
2 Likes
GNSS L1 is the great option for my professional work, I worry about this instability. I’m going back to 2.16
I write to EMLID support but they never answer me
Please try to replicate the loss of fix. If it is indeed coupled to the 2.17 it would be bad and should obviously be fixed asap.
Keep us updated!