RS2 first test, false Fix?

Maybe it would help to check the Interpolate correction check mark in RTKPost for this problem?

Use rtkpost b33c

Here is the log from the base used for PPK:

I used RTKpost QT to post process the RS2 log with the nearest permanent station (53km) but only as a comparisson.

Besides Rtkpost, the issue I wanted to know was why while using Ntrip RTK correction and being FIX, that “jump” appeared.

Using RTKconv, I extracted the “VRS base” obs file, (I didn´t know that I could do that), and this is the graph:

Interesting, there was a “cut” at 15:52. Maybe that cut is the cause? As the RS2 log was OK, I think that it is maybe related to the VRS correction or perhaps my SIM card lost internet connection for that period of time.

What is strange is that about 40 seconds after that “cut” the solution was FIX and that jump of 1.70m in position appeared.

These cuts in the Rtcm3 are frequent, it usually happens when the radio frequency emission is interfered with by trees or buildings. I have decided not to use the QT version anymore, I am not getting good results. Use b33c demo

In my case @agrimgalina I was in an open space, so I think it could be something related to the VRS itself or internet connection.

Summarizing my case, of possible false Fix while in RTK:

  • RS2 (rover) log OK.
  • VRS (base) log has a signal cut.


The question would be: Could the cut in the base signal have caused the false fix? If the answer is yes, and thinking of possibilities to solve that, what about a warning (visual or sound) on Reachview when there is such signal loss?

Maybe by restarting RS2, it could have get a new “fresh” and correct fix.

I have no experience with VRS stations, here in Argentina there is not. But from what I see the problem is not the RS2 but the VRS station

Hi Doppler_Uav

This link is not active any more https://we.tl/t-zpAQMpI6um
Could to make accessible logs UBX, RTCM3 (VRS) and LLH

Here is the link with the logs:

https://we.tl/t-HqazTdTuuv

There is the incorrect number of satellites in the journal of the base (VRS) . 20 satellites should are the minimum about godznie 15:56:00. The file RTCM3 is written down irregularly or the file RTMC3 is rozkodowany by RTKLIB irregularly. It is hard now to analyse Your case. I also have the problem with the record of the base (VRS).
https://community.emlid.com/t/logs-base-error-glonass-the-error-of-the-position-in-the-method-rtn

1 Like

Hi @El_Geodetos

Yes it seems that there are some satellites present in the Rover Log that are not in the base (VRS) log. I don´t know how a VRS base is calculated and how many satellites it uses.

I hope to have another RS2 soon so I can use it as base and the other RS2 as rover to avoid this issues.

Always the best option to use your own base station

2 Likes

I have a similar case: I use my RS2 as a field surveying equipment, I connect it to VRS through a SIM card. I’m in a racing play. On June 5, I turned on my RS2 when I arrived at the construction site to carry out a tachometric survey; nothing else to give the fixed sound signal, I started to take data, and when I had about 55 points, a time of approximately 4 minutes, the RS2 warns me with the sound signal that it becomes floating and then navigation after about 20 seconds it recovers the fixed mode; I kept taking data for a total of 900 points; Upon arriving at the office and downloading the data, I check that the first 55 points were taken on the edge of a firm layer, so I have checked the height of this layer.
Upon arriving at the office, I check that those first 55 points are wrong on the order of 1 meter and on the order of 0.75 meters.
The SIM card I use is multi-operator; I suspect that the problem may have been due to the fact that differential corrections for the loss of mobile coverage have stopped being received, and the RS2 has continued in a fixed state by interpolation.
I have not kept any record of what happened only the coordinates taken with a surveying software. I’m sure this coordinate problem has occurred since the points were taken on a line with known coordinates.
The truth is that I have been very concerned because, although what happened is unlikely to be repeated frequently, if it is very possible that it happens from time to time.
The situation in which the reception of the correction signal is lost and the RS2 maintains the fixed state for so long should be corrected.

4 Likes

Hi everyone,

Thank you all for sharing your observations. We take these reports very seriously. We are conducting a series of tests to reproduce the behavior and understand how to make the workflow in such cases more reliable.

3 Likes

Hi @gujahu,

To check if you have a loss of connection and a satellite “cut”, you can use Rtkconv to convert the “base_xxxxxxx.RTCM3” downloaded from RS2 to get the “base.xxxxxx.obs”. In my case I detected that signal loss.

Hi @dmitriy.ershov,

Thanks for caring about this issue. I think that would be good if:

-Reachview could detect a false fix like in my case, and indicate it as Float. I don’t know the algorithms used and if this is possible.

-At least that Reachview could detect when such a jump in position (1.70m in my case) appears while being in Fix and give a visual or sound warning. I didn´t realize that at the field, I did while analizing the logs. If I knew that I could have restarted the RS2 and maybe get a new “fresh” and correct fix. I suspect that the issue was due to a mobile data lost from my SIM connection.

Hi Dmitriy

Mam podobny problem
https://community.emlid.com/t/logs-base-error-glonass-the-error-of-the-position-in-the-method-rtn

Hey there,

Sorry it took so long to post an update.

Our new dev firmware update v2.23.8 improves the RTK solution calculation and should make the workflow more reliable, especially in somewhat challenging conditions. We believe this should help achieving better results in RTK.

Please note that dev releases provide early access to the new features and are not intended for the real-field use.

Hi @tatiana.andreeva,

Are these RTK calculation improvementes included in any stable release?

Hi @Doppler_Uav,

Not yet. These improvements will take their place in the next stable release that will be a successor for the current dev. I can inform you once it’s out if you’d like.

1 Like

Hi @Doppler_Uav,

We’ve just released the new stable v2.24 update delivering the RTK calculation improvements from v2.23 dev. I’m informing you about it as promised :slightly_smiling_face:

1 Like