Hi,
On a recent project where we operated with a RS2 rover receiver and a RS2 base receiver (with NTRIP caster) we noticed wrong records in the CSV file of the project exported.
the receiver was set up to receive correction from the base via a NTRIP caster. (ie: We use the NTRIP EMLID CASTER).
the issue we noticed into the csv is a survey point set as FIXED whereas the accuracy fields stored in the csv were very high. How come ReachVIEW is able to set to FIX Statue with that kind of accuracy ?
would it be possible to check why the RS2 receiver can return FIX solution whereas accuracy threshold is not reach at all ?
how does it work in ReachView ? How can it be possible that a csv project file stored such record ?
We’ve thoroughly checked your data. It seems that the point was recorded with such accuracy because of the short occupation time. The point was recorded for 20 seconds. In some cases, it might not be enough to calculate coordinates with the best accuracy.
You’ve also shared the raw data logs: as far as I can see, they don’t include the time span when the 3603_crtl_soir point was collected. However, I see that, in general, you work in challenging conditions. It’s definitely okay, but I’d suggest increasing points occupation time in that case.
thank you for your deep investigation.
Of course when working in base-mobile mode we have to take care of base line length and one has to survey point in several epoch.
Initially We were surveying any detail pt with RS2 ROVER at 1hz during 20 seconds… and for control pts during we surveyed the pt stationary during 3min.
However we change the rover config and set it at 5Hz.
therefore for a pts surveyed stationary during 20 seconds at 5Hz it gives 100 samples recorded .
this is what you can notice in the CSV of that project.
I reckon it’s safer to survey a control pt during 3 min , thus it gives 900 samples recorded.
what is striking in that CSV project file is what RS2 returns for 100 samples recorded : on top the pt accuracy looks ok (around 2 cm XY and Z)
but that last pts “3603_ctrl_soir” has also been surveyed @100 samples recorded but returns weird and large RMS ENU accuracy …
Sorry, I wasn’t clear enough. Fair question. By “challenging conditions”, I mean partially obstructed sky view. Please take a look at the screenshot below:
This is the plot showing SNR values for satellites. Just in case, SNR is a parameter that allows evaluating GNSS signal quality. Under clear sky view, the SNR value is usually stable and higher than 35. However, in your case, there are jumps between 25 and 45. Also, there is a significant amount of cycle slips that appear when the signal is lost.
In such conditions, it’s better to collect points for a longer time because the solution status is unstable as well. You can start to collect a point in Fix, then it jumps to Float and Fix again. The point will be recorded with a Fix solution status. However, RMS values are bigger than usual in that case. That’s why the sample count doesn’t make a lot of sense here.
It looks like the same situation occurred with 3603_ctrl_soir point.
UPD. Just want to add that you can try to set restrictions in ReachView 3 to collect point with a Fix status only.
