Bad survey data
- Thread starter Jim Campi
- Start date
Wes Hand
Active Member
Screenshots? Need more info…length of occupation, variety and confidence guard for vertical.
Filip Kłosowski
Member
Our customers recently started to report that they get incorrect position after receiver's first initialization from a cold start. Position start to be indicated correctly since receiver gets reinitialized a second time. Worrying.
ken larson
Active Member
Not sure if related, but may want to look at this thread
RTK, vs RTPK wide open areas, setting control
RTK, vs RTPK wide open areas, setting control
Ben Purvis
New Member
Is there a workaround or some solution to the issue?
Nate The Surveyor
Well-Known Member
Are you running your own local base, or from a rtn?
How much time on each shot?
How much time on each shot?
Jim Campi
Active Member
This was a very small site, say 1/2 acre in unincorporated Napa, CA. Moderately heavy Oak Tree Canapy overhead. All points were collected with the LS and T2 using the precise data topo protocol. Min time is 10 epocs per point. Since I am using the LS and T2, Variety must be zero. I have recently upgraded to the RTKP feature. Shall I send the the file in for review?
Firmware Package GPS + GLO 6ENG
min 2 fixed engines
engine 3d guard 0.328 ft
start when lifted
stop 10 epochs
only rtk fixed
verify 2 w/o enginees reset
rtpk in collect stake
rtpk Environment Category Open (10sec)
rtpk/rtk must agree (no check)
hor rtpk/rtk residual 0.131 ft
ver rtpk/rtk residual 0.23 ft
min rtpk verification level 3
BAse Data SAmpling None
rtpk Ver 1.8.21.208
System up to date
Firmware Package GPS + GLO 6ENG
min 2 fixed engines
engine 3d guard 0.328 ft
start when lifted
stop 10 epochs
only rtk fixed
verify 2 w/o enginees reset
rtpk in collect stake
rtpk Environment Category Open (10sec)
rtpk/rtk must agree (no check)
hor rtpk/rtk residual 0.131 ft
ver rtpk/rtk residual 0.23 ft
min rtpk verification level 3
BAse Data SAmpling None
rtpk Ver 1.8.21.208
System up to date
That configuration in canopy will get you bad shots.
GPS and Glonass only has to have time between fixes to prove a good shot (generally more than 180 seconds). Mutli-constellation with the LS plus will use variety in the solutions to demonstrate a good fix much faster, but just because and LS Plus with 4-constellations in the solution can do it doesn't mean that an LS with Triumph-2 using GPS and Glonass only can. That configuration is still limited to the same rules that have always been understood, mainly time between fixes.
GPS and Glonass only has to have time between fixes to prove a good shot (generally more than 180 seconds). Mutli-constellation with the LS plus will use variety in the solutions to demonstrate a good fix much faster, but just because and LS Plus with 4-constellations in the solution can do it doesn't mean that an LS with Triumph-2 using GPS and Glonass only can. That configuration is still limited to the same rules that have always been understood, mainly time between fixes.
Duane Frymire
Active Member
Try copy that profile and change a couple things; maybe can shave a bit off the 180 seconds.
verify with engine reset confidence level 6, min rtk 2, validate 1
rtpk environment medium and check must agree
min rtpk verification level 2
That will take 120 seconds minimum for rtpk. Name the profile to some canopy, or something like that. Then you can recall between topo used in completely open areas, to this new profile. You may find it still doesn't work and needs 180 seconds at least as Shawn mentioned. But if I get really any kind of canopy I find rtpk doesn't work with less than a minute per solution. I know it says "precise" topo but I have found the profile you are using is for wide open spaces. If you get 2 engine solution verified by reset with one, and 2 rtpk in agreement, then I would suspect it's a good solution (essentially 5 independant solutions using differing algorithms over a couple minutes change in geometry of GPS/Glonass satellites).
I haven't tried this, I don't have regular LS. Just a suggestion to try. But the idea is to create and test some profiles for different situations, then quickly recall between them for whatever situation you encounter. Verify with engine reset might screw with the rtpk so you might have to go back to verify without reset.
verify with engine reset confidence level 6, min rtk 2, validate 1
rtpk environment medium and check must agree
min rtpk verification level 2
That will take 120 seconds minimum for rtpk. Name the profile to some canopy, or something like that. Then you can recall between topo used in completely open areas, to this new profile. You may find it still doesn't work and needs 180 seconds at least as Shawn mentioned. But if I get really any kind of canopy I find rtpk doesn't work with less than a minute per solution. I know it says "precise" topo but I have found the profile you are using is for wide open spaces. If you get 2 engine solution verified by reset with one, and 2 rtpk in agreement, then I would suspect it's a good solution (essentially 5 independant solutions using differing algorithms over a couple minutes change in geometry of GPS/Glonass satellites).
I haven't tried this, I don't have regular LS. Just a suggestion to try. But the idea is to create and test some profiles for different situations, then quickly recall between them for whatever situation you encounter. Verify with engine reset might screw with the rtpk so you might have to go back to verify without reset.
Nate The Surveyor
Well-Known Member
Well, Jim, it will work well. IF IF IF, it's just dirt work, and + - 0.10' is ok. IF you are working with concrete, and the like, it's the wrong tool. But, as Shawn above says, it needs MORE time to mitigate the bad data.
GPS IS a statistical measuring tool. IF the sample is too small, then it can be a bad sample. Short observation time, = small sample. (Which is fine in FULL open sky). But, it's NOT ok in the woods.
Get your sample BIGGER, (More time per shot, in canopy) and Javad will do the job.
Nate
GPS IS a statistical measuring tool. IF the sample is too small, then it can be a bad sample. Short observation time, = small sample. (Which is fine in FULL open sky). But, it's NOT ok in the woods.
Get your sample BIGGER, (More time per shot, in canopy) and Javad will do the job.
Nate
Jim Frame
Well-Known Member
When I said "wrong tool" I didn't mean that you *can't* get good data with GNSS, I meant that getting that good data may take an unreasonable amount of time. If you're doing topo and need 200 shots and each one is going to take 3 minutes (or more) excluding move time, and a robot will get those shots in 3 seconds each, then maybe it's time to break out the robot.
Nate The Surveyor
Well-Known Member
Agreed, Jim. A robot is FASTER.
Many times, the places I go, are going to need 50 shots. And, of that 50 shots, only 10-20 need 3 minutes. Many times I get the thumbs up, at around 20" into the shot.
I just leave mine on boundary mode, and watch it. I can pretty well tell for topo shots.
Nate
Many times, the places I go, are going to need 50 shots. And, of that 50 shots, only 10-20 need 3 minutes. Many times I get the thumbs up, at around 20" into the shot.
I just leave mine on boundary mode, and watch it. I can pretty well tell for topo shots.
Nate