Emlid Store Blog Docs
Contacts

Unconsistent CSV files in RTK operating mode

Reach / Reach RS+ / RS2 RTK / Post-processing
#1

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 ?

image
image1262Ă—47 3.32 KB

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 ?

thanks,
antoine

1 Like
#3

Hi Antoine,

Could you please share this CSV file with me so that I could take a closer look? Is there any chance you have logs recorded for this CSV?

You can email us at support@emlid.com.

#5

Hi Svetlana,
just sent to support

#7

Hi Antoine,

I’ve received the files. I’ll check them and write you back.

#8

Hi Antoine,

Thank you for your patience!

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.

#10

Hello Svetlana,

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.

image
image1631Ă—134 14.3 KB

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 …

image
image1399Ă—632 32 KB

this is mainly what we don’t understand. Why that pt is set to FIX with such large RMS by the RS2 receiver ?

could you explain so far ?

what do you mean when you say “you work in challenging conditions” ?

antoine

#14

Hi Antoine,

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:

Screenshot from 2021-04-09 15-15-03
Screenshot from 2021-04-09 15-15-031144Ă—717 78.8 KB

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.

1 Like