Spot a Bad Fix?

[Jim Frame]

Yesterday I ran a 30-minute rapid-static session on a couple of points, and just for fun decided to see if I could get RTN (single-base) positions on them. The base was about 30 miles away, so I knew I was pushing the envelope way beyond the point of reliability, but I wanted to see what would happen.

I shot point 1 before the static session, and got 3 engines fixed and decent stats. I was surprised it fixed at all, but thought "Hey, great!" The counter stalled at 139 epochs and I didn't want to wait around, so I just called it good and stored the point. Here's a screenshot of the point info:

After breaking down the static session, I fired up the LS again and re-shot point 1 for about a minute, then shot it again for another minute. I inversed from the first shot and was dismayed to see that it differed from the last two by over 7 feet horizontal and 4 feet vertical. Here are the screenshots from the last two:

The two 1-minute shots are very close to the OPUS-RS position (sans rapid orbit) I got on the point.

My question isn't "How do I get reliable positions at this distance," but rather "Is there anything in the stats that I should have seen to indicate that the position I was getting the first time was bad?" Did I overlook something, or is this just the level of unreliability to be expected when exceeding recommended distance limits?

Thanks!

 

[Matt Johnson]

There isn't any reliable method to determine if a short observation is bad from these statistics. In longer observations you should be able to see the vertical position drift in the vertical graph. The best method however is to use Verify with Reset and Validate to reset the engines in poor locations and long baselines. I'd recommend using these and collecting 2 minutes of data so that you have independent fixes that agree and are acquired at least 2 minutes apart.

 

[Jim Campi]

Now that we have 5 hz capability I use verify with reset as a min standard on all projects. It would have taken too long to do this at 1 hz. Occasionally I will notice the LS collects a significant number of epochs and then dumps the point during the verify process. I would have missed that and collected a bad point at 1 hz.

 

[Jim Frame]

Now that we have 5 hz capability I use verify with reset as a min standard on all projects. It would have taken too long to do this at 1 hz.

That works great if you're using your own base, but my situation was via RTN. I don't have the ability to make the base pump out more than 1 observation per second. However, I'm going to try setting Verify with Reset as SOP and see how it goes.

 

[Jim Campi]

Hi Jim,

You could set up a TCP connection via cellular with your base on a known point at the office or home and receive 5 hz corrections. I am in the process of setting that up now. Of course your base line length will be limited.

 

[Matt Johnson]

I'm curious what do you guys have the Confidence Level set at when you say Verify with Resets takes too long? I like to use 2 with 1 Hz and 3 with 5 Hz.

 

[Jim Campi]

Hi Matt,

I use the same settings. Most of my work are precise topo and as-built surveys. Virtually all in the unincorporated county with a significant number of sites that have some level of canopy obstruction. The primary delay at 1 hz is moving from point to point and waiting for at least 2 fixed engines. At 5 hz the time in most cases is insignificant. If I am collecting 150 points and it takes 10 to 30 seconds each to fix, verify and reset, then that is an additional 75 to 225 minutes. Of course some points will fix immediately and other will take much longer. I rarely have any issues using the higher base transmission rate.

Please let me know if something about this doesn't seem correct.

 

[Bob Farley]

Jim,

I have been running auto verify all of the time. Today, I was setting a new control point to occupy in the wide open. I shot it 3 different times. Point #3696 was shot earlier while #3702 and #3703 were later in the day and just a few minutes apart. #3696 to #3702 are just 0.03' horizontally and 0.04' vertically, which is plenty good enough. However, #3703 is 0.37' horizontally and 0.08' vertically from #3696. While I understand that these differences are still mighty tight, the screens may work up some discussion. The site is in the wide open on the shoulder of a new bridge. I have attached screen shots of the setup screen and reports for all 3 points.

 

[Matt Johnson]

Bob, I notice that you have correct for tilts on. Are you calibrating the compass and Level Offsets after you turn the LS on at the job site? The Level Offset calibration then needs to be monitored as the temperature of the LS changes and recalibrated if necessary. If I was observing a control point I would use a bipod without correct for tilts and observe the point for at least 2 minutes.

 

[Bob Farley]

Matt,

No I haven't calibrated the compass and level since last week. Yes, I plan to go back and leave a static receiver on the new point before using it. Most of this is academic. I have been putting my surveys on Mississippi or Tennessee state plane coordinates for the past 10 years. Every time I have checked into my old work, it has been within 0.34'. If not, the error has been in the old work and not the LS. This is the first time that i have had a distance of this magnitude where we could compare occupations.

On a side bar, the highway contractor had a guy using a Trimble for his asbuilt shots. My Javad ate his lunch on fixes and the verify routines. He had never seen anything like it. His was stop, drop, and go.

 

[Matt Johnson]

Please note that the level calibration typically only ever needs to be calibrated once. There is a separate calibration route to calibrate the Level Offset found in the quick setup menu and show in your screenshot above. This needs to be done and checked frequently as this calibration changes with the internal temperature of the LS.

 

[Zoltan Varga]

Hi Everybody,
One land surveyor reported too many bad fixes some weeks ago in Budapest. He used a Satlab SL500 receiver (Trimble BD970 board) under tree canopy, correction received from NTRIP provider. I went to the site with my TLS and I found that the initialisation was slower than normal, even not just under the canopy, but the receiver calculated good fix. The surveyor was there too with SL500, and it worked well that time. I used the Interference function which created the screenshots that you can download here. Can anybody analyse the graphs ? I tried to do by the video from Javad, but my knowledge is too little.