I just got a result from today’s field data where we got a fix for 2 traverse stations. We were doing topographic ground shots and one rs2 unit was getting a fix/float signals so we decided to turn to our total station for some shots until we got a steady fix . The 2 traverse points that were measured by the rs2 returned Fix status. When we got back to the office and processed the total station & rtk data, we got almost 9m in height variation between the ts & rtk data. The rtk data for the 2 shots were Fix with rms values in the 0.006 m and sat number 9 & 4. Isn’t it part of data validation within the rs2 to consider such low satellite numbers before returning a Fix status?
1 Like
How long observation time did you use?
What was your environment like?
Typical obs time for each shot is 10 seconds with a fix status. Shots along roads with houses and buildings both sides. We usually do a validation shot of a point measured previously. But these errors are shots done midway through the day so can’t check with previous shots.
Did I understand you correctly that only had 9 sats visible for this?
Yes 9 and 4. User did not notice number of satellites while doing rtk. It was when data was downloaded that we noticed a fix for a shot with only 4 sats
With what constellations enabled?
All 4
If you have 9 sats available, then that should tell you that there is something wrong. Another indicator is the PDOP value…
1 Like
What’s wrong with the 9 sats? I remember using rtk with just gps+glonass with about the same number of sats and getting a fix status. It’s the 4 sats that concerned me, rs2 should not have returned a fix reading with 4 sats.
If you had another unit for static, you’d have a baseline ( RS2 and static unit) and rover collecting data ( i. e., triangle). You can PP and verify rover “fixed” position and also determine closed loop accuracy. I also would use a longer occupation time for the rover, at least 30 sec for PP. If you’re logging for 10 sec, why not 30 ? Especially in multi-path areas. Even if the baselines are short, 10 sec is hardly enough time to PP as verification.
2 Likes
I think that is the ideal situation. But my concern is that the RS2 is returning a fix reading. That in itself should be an assurance that the point’s position is correct. We can’t have the field surveyor verify each and every shot that he makes in the field.
3 Likes
Regarding the fix, then I completely agree. It should not fix in those conditions.
I just don’t think 10 sec is enough to get a reliable fix. Even with our world class Javad receivers locating edge of rds, etc., I get a minimum of 30 secs per point. RTK is fast, however it may be not enough time for the solution to converge with a reliable accuracy.
4 Likes
Hi Juan,
In bad environmental conditions, GNSS receivers may obtain a fixed solution and calculate the wrong position. It’s a rare situation, but no one is safe from this.
If you survey with an obstructed sky view and low satellites’ number, I’d suggest checking the DOP value and collecting points for a longer time. Such fixes are quite unstable, so increasing the collection time may prevent getting false coordinates.
We’re working to improve the RTK performance of our receivers and add additional validation steps to reduce these cases. So, please keep your receivers always up-to-date.
4 Likes
Being a land surveyor for most of my life and being licensed since 1985 ( I’m getting old !), I’ve always thought of fixed positions as a “spur” shot to a point in terrestrial surveying (i. e., total station, transit and tape). If you turn only one angle and measure one distance, how do you know if it’s correct ? You can turn multiple angles and measure the distance twice, but you really don’t know the accuracy of the located point without a closed loop.
Same thing with GNSS located data and points. If you have two units on-site as a baseline, your rover unit completes a polygon.
You can then verify the rover point by PP and compute a closed loop for accuracy.
Buy another unit (M+,M2, RS+ RS2, etc) !! And also buy a good PP software !
3 Likes
Is there a software that would reproduce the RTK results in the office using the log files?
I mean to get the exact coordinates if for example I used the wrong base coordinates or connected to the wrong NTRIP base and I wanted to correct it to the correct base.
I’m not sure what you are describing… If you logged the raw data for the base and rover, you can PP with rtklib or with a commercial PP software like I do. If you are on an RTN, you can download the base files of the RTN and PP with rover. Of course you need the raw files of both in either instance.
It has happened to me on several occasions that I have taken points with the RS2 with Fixed RTK, and later I have verified that the measured coordinates were not correct, it has happened to me in places clear of buildings and vegetation.
I have a SIM card in the RS2, and I attribute the problem to that the RS2 keeps averaging the differential corrections for a long time, after stopping receiving data packets due to lack of telephone connection. When the reception cut-off time is a few seconds, the interpolation it does to get the Fixed is correct, but when it begins to have 20 or 30 seconds without receiving corrections, the calculated coordinates begin to deviate and the equipment continues to indicate RTK Permanent.
We shoot in control points with a robotic instrument and auto-level with which you always have to backsight and best practice is to hit another checkpoint. We then come in and set secondary control and traverse points or construction benchmarks and GCP’s with no less than 60 seconds. This is the same whether it is our Topcon or Emlid equipment. Thing is that for normal topo or stakeout Topcon can hit it in 3 seconds whereas I am not comfortable with less than 10 seconds with the Emlid even though the RS2’s are very very good. This becomes a bigger deal when you are doing a topo from a vehicle.
If you are experiencing 20-30 second breaks in corrections then I would wait at least a minute before approaching and collecting or staking out a point. I would also recommend logging for PPK every time if your are doing high accuracy work. If anything as a doublecheck of the RTK if you think something might have gone awry.
2 Likes
It would be interesting for Emlid to program the option of being able to select the time in which the equipment can interpolate the last corrections, after having lost the connection, so that it goes to the auto state and not to a false fix.
4 Likes