HOME BLOG SHOP FORUM CONTACT US TERMS

False Fixing (Resolved)

Have you ever gotten a “false fix”?

All the points shown in the image above correspond to the same point on the surface, about 10.05 meters of baseline, in a partially obstructed sky, and all taken in “Fixed RTK” mode. Taken at intervals of a couple of minutes, while restarting the S100 application.
It is not the first time I have noticed a false fix, but it is the first time in small time intervals. Maybe it’s the latency of the mobile internet, but I tried with two different operators and in both I got false fix.
I also noticed that after about 70 seconds, the coordinate indicated in the false fix was corrected and showed me the expected one, so I recommend you to be careful in partially obstructed skies and wait a while after the first fix (at least 1 minute) and observe the number in the baseline field if it has not changed to start the survey, once a reliable fix is ​​obtained and as long as the fix is ​​not lost, the rest of the points raised can be considered reliable.

https://www.intechopen.com/books/global-navigation-satellite-systems-from-stellar-to-satellite-navigation/analysis-of-ambiguity-false-fixing-within-a-gbas11

This article addresses the topic of fake fixes and their possible causes

Edited: previously wrong picture uploaded.
Points 2, 4 and 5 are the awaited with correct coordinates.

3 Likes

Hi
Can this caused by base survey? Base survey takes 60 seconds to get fixed.

1 Like

Hi Jim, like you said is because of base, but not for base survey. I have installed the alpha+ as a base in a permanent place with good sky view, with fixed coordinates resulted from 7 hours of PPP and when I did the test in the picture above, base was started hours ago. So, I’ve been testing and testing and found there’s something not working well with the RTCM.

All points, in this last screen, were taken in different hours of day, with base configuration in Skytraq, so the problem is in the RTCM, please fix it.

1 Like

Hi,
The screen capture in your second post seems ok to me.

What is the differences of situations of the 2 screen captures, you just surveyed at different time?

Second screen is good because was taken with base in Skytraq, first screen was with base in RTCM

And Polaris Connect App is crashing a lot too, but with lefebure I’m getting the same problem, urge an update in app and software/bluetooth version of S100

I will contact you to understand the app crash issues you encountered.

The crash consists of mobile screen freezing, with no data or invalid value in the field of status information, requiring a restart of the phone and the S100

Sometimes the phone does not get connected with S100 on the first try, and the app does not try multiple times like Lefebure app does. This may be the cause.
You can just restart the app, and usually do not need to reboot S100 to get this fixed.

Hi,
According to our test engineering person, in some cases, the rover may need a few more minutes before it gets a Fixed RTK solution with an RTCM-format base. However, once the rover gets Fixed RTK solutions, the positioning quality stays as good as in the case of Skytraq-format base.

I taped videos showing NTRIP transmissions with RTCM base

https://drive.google.com/file/d/1w3cjPbtKaCxnE4LDpNqgHz7TZW19qG96/view?usp=sharing

and with a Skytraq base

https://drive.google.com/file/d/1IVq6QZnSWV9rQzguG0jmqgTF0MVxmWPv/view?usp=sharing

As you can see, the accuracies are quite similar.



1 Like

Please try it in a partially obstructed sky, with a few of multipath expected to have.
Collect one point in such conditions and then, after a minute, stake out the same point and check residuals, in RTCM.

I see you have a difference with SPED CORS, What are your suspicions?

1 Like

Te conectaste a San preso y una privada de santo domingo

Sería bueno probarlo bajo una vegetación muy densa ver si tiene buena solución y la precisión

So you found the stakeout error (in non-perfect environments) in RTCM is greater than that in Skytraq?
In that case, we will try to reproduce and check this. Thanks.

Yes, if is possible, take it over known coordinates, take a lot of lectures in the same point and look for inconsistent.

I found that the issue was with base update rate set it to 10 Hz. If configuring base to 1 Hz, the app does not crash.

1 Like

Here are some pics of where i get the false fix






Sorry for 4K

And here is a link to a video of behavior of Polaris Connect in such environment, is the same point collected. Look for baseline length field, changing for each time I start the application and then get a “fix”.

https://drive.google.com/file/d/1i-RnxsBysNLVYnrRGRlV0r05CSUEGNln/view?usp=drivesdk

Last fix star at minute 5:20.

It’s also happening in Skytraq format, so I conclude is multipath effect.

Well, I think you should keep the base update rate at 1 Hz. Higher base update rate does not help positioning.
Can you please configure base update rate to 1 Hz and check if that issue still exists?