I have no idea what we did wrong. We are using Microsurvey Fieldgenius to collect points in the field. Never had any indication that we were in float on the app but may have been. Even still, can we not correct the rover positions with a known base point? Why cant we get a fix even processing with known point? I have a solved position for our local base using both opus and processed cors station rinex data with our base rinex. Very similar location…so we got that far. Now when we process with the known base and our rover’s rinex data we are not getting a fix. Very poor results.
Can you post your raw-data?
Can i send the raw data in a private message to you?
Can you please share the processing data with me as well? Please send it via firstname.lastname@example.org, I’ll take your ticket.
I took a look at the raw-data. Both your units have issues with SNR and cycle-slips.
However, especially the rover has big issues.
Here is a screenshot from RTKplot:
I processed with a few different options in RTKpost. As you have a very short baseline, L1 only processing is viable option. Also disabling Glonass gave me a few more fixed epochs.
Here is the best I could do, using L1 only, GPS+GAL+BEI (so no GLO):
Interesting! There were a lot of trees with wide canopies there. So maybe that particular time of day all good satellites were low on the horizon. Everything at the bottom of the graph there is opposite the clear horizon to the north. Perhaps letting the rover observe for longer periods of time would improve our results?
Thanks again for your help.
That is definitely one approach yes, but in order for this to work, it has to be so long that you would be able to obtain a fix in L1-mode on each point, which is usually at the 5+ min mark. Collecting a lot of points with 5 mins obs time will take some time
Thank you for sharing the data! I see that my colleague, Kirill, outpaced me and already answered you via email. But I second his thoughts and comments from Christian above.
The logs from your rover have a lot of cycle slips—red marks that show that signal was delayed or disrupted. I assume they occur exactly because of the tree canopies. So my main recommendation here is to provide the device with a sky view without any obstacles and place it far from any reflective surfaces that can cause multipath. Here is also a guide from our docs that can help you with the receiver’s placement.
P.S. Christian, thank you for your analysis!
Yep could take a while! Probably best to only do that on control points - sideshots dont need to be as long! Another question though, if our base was in a better position would we be able to correct rover shots in ppk, or would we still get bad results?
Thank you Julia! Yes Kirill and Christian, and you have all be very helpful. We are always trying to learn and be better! I am curious though, in Emlid studio- how do you view the positions of the satellites in the skyplot window?
There is nothing better than constant learning!
I drag and drop the observation file to the Emlid Studio plot. Then I change the view from Satellite Visibility to Skyplot at the bottom of the window. If the navigation file is located in the same folder as the observation file—you’ll see the satellite positions there.
Here is an example of what it looks like:
You can see how high the satellites are above the horizon. The vertical scale from 0 to 90 shows the elevation angle.
I have a couple of comments here as well
Both RTK and PPK use in calculations data from satellites, which are common for base and rover. It gives the main idea—the number of such satellites and the quality of data from them on both receivers defines the quality of the solution.
So I’d say that improving the satellite visibility for the base is a good step. Sometimes you may get better processing results, as the new file may have more in common with the rover data. But when the data from the rover is poor, it won’t suffice. So you’ll need to improve the rover’s environmental conditions as well.
I’ll have to voice my opinion on this. Multipath is not good for any type receiver. The best receivers/software can pick out the good clean signals and derive a reliable fix. That’s why they cost more.
Have you ever stood under a large tree when it’s raining ? The rain isn’t as bad as standing out in the open. Same principal in GNSS signals… You will receive fewer/less quality signals under the tree. Any kind of multipath with any kind of low cost receiver is not good.
If you are concerned about multipath in an area you are locating, you’re probably are already in a bad area for GNSS observations. Without proper validation/field location procedures for any located point, you are taking a big gamble on the supposed “fix” solution using GNSS equipment.
Closed observation loops using local short baselines are your friend. They will tell the true value of your “fix” on the located point. Without some kind of verification, whether by terrestrial/GNSS PP loops, you will never know what the true accuracy of your located point is.