The first thing i would look for is how long this fix would last… couple of seconds or few minutes?
But perfect timing of geomtry is my bet
Thats why you always measure twice or three times over certain amount of time, to verify the position.
1 Like
How do you do that with aerial mapping?
Also interesting is: it is not the first time this happens at that window.
- You dont do aerial mapping right next door to your neighbours window…
- Golden geometry happens every day, you just need to be there at the right time
5 Likes
I agree with TB_RTK. I set up in a window to do functional tests of Reach. However,I never expect good readings because over half of the sky is blocked and most of the signals are likely to be reflections. By poor skyview, I mean that I try to get as much of a view of open sky as I can. However, I would generally be using about 20 GPS + Glonass satellites at 35+ SNR . There are numerous cycle slips as satellites are obstructed by trees, etc. The “upgrades” address a lot of problems introduced by these slips. I know the results are better because I have a tape measure to confirm the data.
Aerial mapping probably would not see some of these improvements because:
- A good base station with good view of sky will likely have no or few cycle slips.
- Rover will likely have good sky view with few or no cycle slips.
The most likely improvements will be seen near trees and low buildings. There are numerous reports of excellent aerial mapping results in this forum without these beta improvements.
1 Like
I think the results show that there must be an error. The AR validation ratio is 999.9, I guess that is infinite.
The AR ratio factor is the residuals ratio between the best solution and the second best solution while attempting to resolve the integer cycle ambiguities in the carrier-phase data. In general, the larger this number, the higher confidence we have in the fixed solution. rtklibexplorer
Hard to believe that a solution 30 m away is that good compared to the second best. Also hard to believe that my window is golden (I wish it would be) for more than 20 min this evening and also some months before and that this is the case for different combinations of GPS, SBAS and GLONASS.
I think the answer which is far more likely is that there is an error in the calculation/code.
I think it is also not important whether there are better conditions when the antenna is flying 100m above the ground. The important question is whether you can trust the results and whether wron calculations are reliably detected. Of course I can see that there is an error when the error of the solution is 30 m. But can you tell it when it is 10 cm?
You need more satellites with SNR > 40. Test it in a place with no buildings around. Multipath will be a problem with buildings.
1 Like
Of course, I understand that under these circumstances the result must be bad. Bud I don’t understand why the software tells me that it is quite good.
Set your SNR filter to 40. If there aren’t enough satellites, you can get a false solution. Have you tried adding Glonass with the GLONASS AR mode enabled?
999 is the maximum value allowed for AR.
1 Like
I belive that this is just the nature of mathematics, a convincing form of fixed solution.
I have seen this several times and it usually happens in a short period of time, when you see it like a roler coster. Peaks rapidly and drops almost in the same pattern.
A solid fix i can see as a confident AR increase over a bit more time. But again, you always measure more then twice to verfiy absolute position.
1 Like
I do agree with you that confidence in readings in a major concern. I defer to the aerial mappers for how they confirm accuracy of surveys. I think they use ground markers and certain reliable software to backup accuracy of their surveys. Beyond my skill level…Lots of info in Forums.
My use involves precise direction from Base to Rover. My confirming checks…
- Magnetic Compass: Good in mid latitudes. Must use declination corrections changing yearly .
or off in local areas. - Sun and or moon shots: Sun sighting dangerous. May be obscured by clouds.
- Earth oriented gyros: Expensive Not good near poles.
- Maps: Not necessarily up to date. Subject to plate movements.
Re: FIX right or wrong: ReachView does not have a lot of the configurations available in RTKLIB. In my case, I’m looking for at least a stable Float that I can use in post processing. The FIX is an added benefit. There are so many different ways to configure RTKLIB. If you have unique situation, I would think about using RTKNAVI for realtime and find what configuration gives you the best results for your application. I know that usually an easier to get FIX configuration means a more likely to get false FIX.
RTKLIB really covers a massive amount of applications. I’m not going to pretend that ReachView is a one size fits all app.
I’ve been testing for over a year. So, I understand your concerns. But, I also have seen great improvements with the Emlid ReachView. I had a lot of false FIX readings before compared to now. Occasionally, I would get glitches in location at 10s of meters and wait for location to reconverge. Now, I am not seeing this. That would certainly be good for drones.
For me, I’m getting more repeatable FIX. I wish you well. Your observations are welcome. Another illustration that precision of measurement is not the same as accuracy of results. Always, question results…Good luck.
Yes, buildings are a problem. In my case, they did not seem to greatly affect the results. Maybe, the solution is less affected by cycle slips and reflections are less of a problem. I hope so. I have two long two story buildings about 18 meters from antennas.
Disclaimer: Position data from post-processing combined forward-backward mode. After 16:30, I switched off SBAS. Somewhere around 16:37 real time when FIX and remained FIX until end. FIX before then is result of Combined post-processing.
1 Like
Its a new day…
With old configuration:
GPS only and SNR 40 and Elevation 20°:
The position of the base station is after 5 min single averaging very close to the real position. Its perhaps also a stupid idea to place the antennas that close together.
I’m looking forward to go into the open field.
Hmm. i bet you could sell your apartment for a nice amount of money to a surveycompany 
vIt’s not the apartment, it’s me 
. You are welcome to hire me 
Ok, pants off, it’s the device, Reach makes surveying 999.9 - great again 
1 Like
Back again. Yesterday, it rained. Not surprising was difficulty in obtaining FIX as all trees and buildings would be wet and attenuating signals. However, FLOAT did not have significant glitches and trended toward expected solution. There is a limit to everything…
Today, I decided to give ReachView beta2.2.2 a little more reasonable test. In this test, The Rover was approximately due east of the Base at about 1.5m. The test lasted about 1/2 hour. (I bore easily). Results were excellent in my opinion. The FIX was obtained in a few minutes. After about 5 minutes, I realized that I was in Kinematic mode and switched to Static mode. Real-time and post-processing showed the Kinematic and Static fixes to be within 1 cm of each other.
EDIT** Solution Plot Removed*** Pilot error
OK, now today’s setup…
Looks worse than it is…
Post-process>>>
I hope someone can look at Solution log…I’m a bit puzzled on this. Otherwise, I think it will be hard to improve on Static performance beyond this.
Thanks to all who persisted. One other improvement suggestion. This is probably low priority as Base receiver should be in clear sky view. For those cases where we are forced to use best possible locations, Is it possible to keep the BASE averaging from resetting before average is complete. I’m not sure what decision criteria is used, but it seems that getting bad single solution may be resetting the averaging to zero time value? Beyond my skill level…
Could not resist post-process Combined forward/reverse after throwing out bad satellites from GPS/Glonass…
Cheers…
If single solution has been lost during averaging it restarts. That makes sense because we consider that the base is either in really bad location or is being moved. Does it fail even on shortest averaging time?
1 Like
Hi Igor,
The averaging sometimes fails in a minute or two. But, it’s no big deal. I’ve been purposely setting up in poor conditions to test the limits of performance. In reality, the failed averaging will let you know that you do not have a good Base location and should find a better location. Even in a poor location, once you establish the Base coordinates, you can set the Base coordinates manually from that point forward.
Looking good! Be interesting to see when Galileo comes on board as that system is supposed to be more forgiving of poor skyviews such as light trees, etc. You have a great team there in responding to so many user requests. Thanks again to all…
Hi Richard,
Thank you! Galileo update is in active phase right now, so should be here soon.
We’ve released a new update, v2.2.3. This should fix the Reach crash some users have experienced in the last couple of days.
4 Likes