With RTK I am able to get a point’s position in less than 10 seconds or more if the environment is not good for gps signals. If I process the log files in kinematic mode using PP software, most of the time I would get float solutions for the same point. RMS would sometimes be acceptable but solution is still classified as float. Maybe I need to average the 10 seconds of observation time used in the RTK solution? Quite tedious to separate the needed seconds for each RTK point. There must be a software that would be able to cut, average, process the same RTK parameters that resulted in a fix solution for the RTK point.
What PP software are you using?
RTKLib, Topcon Magnet & Spectrum Survey. Still learning on Spectrum but I got different results from Magnet & RTKLib when I processed in kinematic mode.
You need to think about the process of RTK and PP. The final product of any point is just a statistical average of a number of collected fix solutions. The longer the occupation time, the greater chance for the solution to converge to it’s optimal accuracy.
3 Likes
Hi Svetlana,
Can you share with us some of the details about how the RS2 determines a fix eg.
- number of iterations performed
- quality determinant eg. fixed result is 3 standard deviations better than the next best result
- if the software assesses for linear trends in the coordinates of a point
It would be nice if a minimum number of satellites could be set.
Also a minimum length of time that corrections have been received without interruption?
I think increasing users confidence that a, ‘fix’ is a true fix is important. I would much prefer to receive a float solution and wait for a fix; than get a fix quickly that I was not confident in.
7 Likes
It would be nice to see the Continuous option from RS+ come back. Fix-and-Hold seems to not be too trust-worthy when situations become tough. As you say, I then much rather have a lost fix indicating that I am pushing my luck.
7 Likes
Hi,
Just following up on the settings re. a fix.
I was reading an RTKlib site that had some great info:
“I have introduced two new input parameters, “minfixsats”, and “minholdsats” into the code. These set the number of satellites required to declare a fixed solution as valid, and the number of satellites required to implement the fix-and-hold feature.”
I’d love to be able to set these parameters and increase the chances of a true fix.
1 Like
Hi all,
The chances of catching a False Fix on a typical survey site are pretty low. Such situations usually occur in challenging surveying conditions. Most of the time you can rely on the solution status you see in the software.
However, how do you determine which conditions may potentially lead to wrong calculations?
-
If you work under the dense foliage
-
If you are tightly surrounded by high-raised buildings
-
Near any other obstacle that blocks 80-90% of the sky. You can check the Satellite SNR chart. There should be at least 5-7 sats with SNR higher than 30
-
If you receive corrections via NTRIP and work in an area with unstable Internet coverage
What parameters need to be additionally checked in the cases mentioned above?
-
DOP value. We do not recommend collecting points with DOP higher than 2
-
Age of differential. If the time is more than 2 seconds, there is a chance of connectivity issues
-
Point observation time. As I’ve already said, I’d suggest increasing observation time in harsh conditions. It might help to capture the Fix instability
-
RMS value
Reach RS+ and Reach RS2 calculate the solution differently. Also, we conducted some Fix-and-Hols vs. Continuous comparing tests and found no proof that one mode works better than the other. The results are described in this thread.
It is not always possible to provide the receiver with an absolutely clear sky view without any obstacles. I understand that you would rather avoid even a rare opportunity of catching a false fix. However, this is a common challenge for all GNSS receivers, not only for Reach.
1 Like
My point is that I rather have a float solution or a warning that the fix is potentially unreliable (i.e. that PDOP is too high or cycle slips pr minute are above a certain threshold).
These past weeks, I have gotten 3 cases where we discovered a false fix. Fortunately, for each case, it was for 2 traverse stations that had observations for backsight/foresight so we were able to determine that the elevation was off between the 2 control points. Since the traverse stations were connected to the main control network via RTK, we do not know which of the 2 traverse points for each case has the correct position. We had to re observe the 6 traverse stations, this time for more than 2 minutes. We are now observing all traverse points for more than 5 minutes if they are not in positions that obstruct traffic flow.
Unfortunately, how many other RTK points that have no total station data for the check have false fixes?
The false fix on the total station observation returned a FIX status with an RMS value of less than 0.10m and had 30 seconds observation time, which are our new thresholds for observing traverse points after getting some false fixes at the start of the work,
Juan, what firmware do you have on your Reach? Do you have logs from those sessions?
We are using fw 2.22.5. we tried to pp the logs but like what I mentioned in other posts, we could not get a fix status when we process in PPK. maybe 95% are float (#2) in rtklib results.
we tried this in both rtklib and magnet. will try it in spectrum survey once we get the hang of it.
Hi Juan,
From the v2.23 dev version and current stable v2.24, we significantly improved the RTK performance on Reach RS2 devices. That’s why I recommend working on the latest stable: it should prevent you from getting the difficulties you experienced.
1 Like
Thanks for the info. But since it was released only recently, I want to wait for a few weeks and see what problems other users have/will encounter with the new fw. From what I read on this forum, there seems to always be some new problems that users will get from the new fw release. It will solve some past problems I am sure but the units are now being used for an ongoing work & we can’t risk having any unknown problems prop in unexpectedly.
Why not when collecting a point, reshoot the same point and inverse between them ? Although I don’t use the app for RTK, I would think this would be possible. I just use for static purposes.
Using j-field in Javad software, if you already shot a point, it gives a distance to last report on the screen. It’s a valuable function in the software. Maybe Emlid could incorporate something like this in their software.
2 Likes
Inversing is definitely needed! Why not just walk off from the point about 10 meters and stake back to it?
1 Like
I’m surprised inversing is not included in the app. That would be something pretty simple to incorporate, would be very valuable to the user and would be a simple way to validate a point.
1 Like
Maybe it could come along with draw a line/polyline between points… Then just click on the line and receive a measurement.
3 Likes
Can you imagine having to do that for every shot or even just 10% taken by an RTK shot? That’s doubling the collection time which defeats the purpose of using an RTK in the first place.
I don’t think so, I don’t understand why everyone is in a hurry to get a shot. Using my 2 M2’s as static and using my Javad Victor LS system as rover with RTN, locating edge of roads, creeks, etc. I usually take at least 2 shots per point, total time per point is usually less than one minute. Sometimes I have to occupy a point at least 30 minutes if in high multi-path areas. I just don’t understand why everyone is in a hurry taking shots. I enjoy my surroundings in the field looking at nature and the area I’m in. I usually PP if there’s any question in the data I have.
I’ve been a licensed surveyor since 1985 and 63 years old. Accuracy and knowledge in knowing you have an accurate position is paramount in any collection system. Especially when you’re providing an accurate map of property boundary or topographic maps. Geodetic networks usually have occupation times of at least 4 hours per station if submitting data to NGS.
As stated in another post or thread, you need to understand that the longer occupation of a point provides a better statistical solution for the position. More epoch’s, mean a better position and guarantees a confident solution.
2 Likes