I tried processing your data in EzSurv. Here only point 29 gets fixed (over the course of ~36 minutes of overlapping data).
Looking into your data, I see a few things that affects your ability to fix, and your precision in general
You are collecting inside a forest. I guess from your base/rover heights you are trying to get through the canopy?
Looking into your rover data, you have a huge amount of cycle slip, with some clean data here and there. I guess that is from breaking through the canopy?
Your observation-times are too low for postprocessing. When you don’t have continuous data (because of the many cycle slips), you need at least 3-4 minutes, preferably 10 minutes per point to ensure ambiguity resolution for each point.
your base observations look good except for south and east direction, where the SNR is significantly lower.
Processing in RTKpost demo5 b34d does get more fixes, but given the data quality, I would advice caution in trusting position, and advice to make multiple observations per point with a few hours between to allow the sat geometry and multipath characteristics to change.
5 Likes
benefactum.xyz
(Bene Factum Ingenieros Consultores Sas)
229
The data is from a testing exercise of the RS2 equipment. And this leads me to several unanswered questions.
If the solution is NOT reliable, why were fixed solutions obtained in the field? and in postprocess the same point is float?
Should we doubt the accuracy of the field data, even with fixed solutions?
EMLID RS2 Antennas show false fixed? How to know when it is false and when it is valid?
Still achieving fixed solutions in Stop and Go, should post-process be done?
Note: We are emlid users and we love them. But if we want to learn to get the most out of the tools.
The Reach RS2 RTK and Emlid Studio PPK algorithms are not the same. So, the percentage of Fix you receive in PPK and RTK can indeed differ. It’s not an issue, and you can trust the Fix solution you get in both modes. If you obtain the Fix solution in RTK, there’s no need to process the data in Stop&Go afterward.
If the sky view is highly obstructed, the solution status can be unstable and regularly drop to Float. I think that’s what happened in your case since there are a lot of cycle slips in the raw data. It means that the signal got interrupted, and the rover lost track of the satellites. So, the software could calculate only the Float solution most of the time because of the rover’s data quality.
To prevent it in the future and ensure the solution accuracy in harsh conditions, I’d recommend the following:
Check that DOP is <= 2 and the age of differential is around 1 second. This way, you can see that the satellite geometry is good, and the receiver regularly gets base corrections.
Turn on the FIX only toggle and increase the point collection time. It will show if there’s a Fix solution instability.
Hola, es necesario que interpoles las imágenes con elrinex de navegación… Por aquí y por allá he visto una aplicación que genera esa solución es un script se llama “toposetter” de un chico alemán, es necesario Rtklib, pues es un complemento. Pide el archivo de base “rinex”, el archivo del drone “rinex”, las imágenes, y creo que eso es todo…
Hello,
Yes, Toposetter is an application that does basically the same thing as Emlid Studio, only it is able to read the events from the .mrk file. I think Toposetter uses RTKLib internally.
We are very happy doing tests with the Emlid Studio.
We have 2 Emlid RS+ teams and we do surveys most of the time for PPK, since the distances are long and we do not have coverage to receive LoRa correction, much less NTrip.
We have noticed that when we do the Stop and Go Flow, to obtain the data corrected by PPK of the points registered with our rover, the exported .CSV file lacks data related to RMS errors, there are several columns that are exported without data.
Here I share the raw data and those obtained by the flow. Maybe it’s a bug or a misunderstanding on my part.
As I have been using ES 1 Beta 10 I am finding that it would be helpful to find in the output POS file some indication of what value was used for antenna height. I have had to return to re-run a set of rover / base / nav files in the PPK analyses just to confirm to myself that indeed I had used or not used a value for antenna height, and what it was. Thanks.
Dan
Haven’t seen similar requests earlier, but I agree it can come in handy. Not sure if it’s the best way to keep these values, though. We’ll think about it. And thanks for sharing your ideas!
hello guys, I have performed a stop and go with Reach view feature and Emlid Studio, but I did not attain the corrected csv file. I have followed all steps required as per instructions from Emlid docs, but the generating corrected Csv section keeps loading for hours without generating a corrected csv file…
Let’s figure this out together. So, do you use Reach’s data as a base for another Reach? Or do you use it as rover’s to your NTRIP station?
To make any conclusions, I’d still need to take a look at the data. There might be sight details that can get overlooked sometimes, like the time in which the logs were collected. If your logs contain any specific sensitive information, you can share it with us at support@emlid.com.
Do you mean that you’d like Emlid Studio to convert your coordinates to the projection? If so, I’ll make sure to record your feature request. No quick plans on it, though, but it’s in our overall roadmap.
That’s a weird one. Can you please specify what Emlid Studio version you work with? What system does it run on?
I’d also try just one more time. You never know what happens if you don’t catch it repeating If this behavior repeats, please, share the data with us: the raw data logs and the CSV from ReachView 3 that you try to process. For sensitive data, you can use our email support@emlid.com to send them to.
Thanks for letting us know how important it is for you!
If this behavior repeats, please, share the data with us: the raw data logs and the CSV from ReachView 3 that you try to process. For sensitive data, you can use our email