Emlid Studio 1.7-could not get same result as processed with Emlid Studio 1.4


I am wondering if there are any algorithm changes in Emlid Studio 1.7?

I have some .POS file and CSV file that I saved and processed using Emlid Studio 1.4. However I cannot replicate the corrected result with the latest 1.7 version. The value i got is close to what i got previously (but not exact) and the status change from FIX to FLOAT?

Posted here to check if anyone experience same issue like this.


1 Like

I am guessing that it has to do with your ES processing settings. Check the Glonass/Galileo to see if you had fix-and-hold on or off in each version.


Fix-and-Hold is a strategy for solving the ambiguities in RTK and PPK. After the first ambiguity fix holds them constrained. Fix is more stable but in case first initialization was not correct it will take longer to recover and initialize correctly. You can think of it as if Fix had inertia.


Continuous is a strategy for solving the ambiguities in RTK and PPK. In this case, ambiguities are resolved epoch by epoch. Less stable than Fix-and-Hold, but no risk of holding a false fix.

1 Like

Thanks @Zaz5400, i am rarely setting the parameters, always leave it as default. I played with the settings as you suggested but still could not get the same result as i get previously.


1 Like

Hi Ting,

We don’t have algorithm changes from ES 1.4 to 1.7. You can check the changelogs here.

Mind shooting us the data you’re using? It’ll give us some insight into what’s causing the differences. You can send the data here or to support@emlid.com.


Hi @ting.kingking,

I processed the data you shared in both Emlid Studio 1.4 and 1.7. The results were similar.

I’ve also tried to change the settings in Emlid Studio to get more FIX solutions. But it didn’t affect the results much.

So, I’ve checked your logs. Here are the satellite visibility graphs for the rover and the base:

You can see that there are red and gray marks in the log. They occur when the signal is delayed or too noisy. It looks like the environmental conditions were challenging for Reach RS+. And this is the reason for FLOAT.

Reach RS+ is single-band, so it requires a sky view like in an open field to obtain a FIX and provide you with a centimeter-accurate position. Let’s ensure placing the receiver in such conditions. You can also follow these tips from our docs. Once you improve the sky view for the receiver, the logs will become of better quality, and it’ll lead to improvements in processing results.

1 Like

Thanks Inkar,
I’m still a bit perplexed as i remember i got more FIX points when i run it last time.
Would you mind to do one final checking for me please? i would send you two .POS files; one that i saved previously using ES1.4 and another one is recent generated .POS using ES1.7. I found the value between two files are identical as start of the survey but start to divert as towards end of the survey.

The end result of corrected points are not hugely different, in cm. However i ensure repeatability between the surveys that we run.

Thank you

1 Like

Hi Ting,

I’ve processed your logs again but couldn’t reproduce the same results as in your POS files. Have you used the default settings?

Here are the results that I obtained in ES 1.7 with default settings:

I’ve tried to “play” with the settings, and the best result was 40.2 % FIX. I changed the filter type to Combined and set the ambiguity resolution for GPS to Continuous.

It is hard to obtain a better FIX percentage for the current logs because of the data quality. So, my main recommendation is still to remove obstacles and improve the sky view for your Reach RS+ in further surveys.


Thanks Inkar,
I’m usually dont play with settings unless if there any advices. So im very sure last time when i used ES 1.4 i was using the default.

I guess this would remain as a mystery. Putting aside the FIX issue, im hoping to reproduce same correction i did last time (to demonstrate repeatability in scientific reports).
Anyway thanks for your help.