Notifications
Clear all

Are all GPS's created equal??

14 Posts
6 Users
0 Reactions
1 Views
(@surveydana)
Posts: 10
Registered
Topic starter
 

Our company is currently looking to switch out all of our current GPS units. We are currently having alot of hardware/software issues with our current equipment. We are using both the AZGPS and SmartNet networks. A reocurring issue that we are experiencing in the field are "elevation jumps". We will vertically localize on a known point and when we try to check into that same point hours later.... we will miss vertically by sometimes as much as a foot. Are there any uinits out there that will let you know if your vertical plane has changed??

 
Posted : August 3, 2015 5:16 am
(@mightymoe)
Posts: 9920
Registered
 

surveydana, post: 330152, member: 8658 wrote: Our company is currently looking to switch out all of our current GPS units. We are currently having alot of hardware/software issues with our current equipment. We are using both the AZGPS and SmartNet networks. A reocurring issue that we are experiencing in the field are "elevation jumps". We will vertically localize on a known point and when we try to check into that same point hours later.... we will miss vertically by sometimes as much as a foot. Are there any uinits out there that will let you know if your vertical plane has changed??

I would say you have real problems, haven't had that ever happen to me, and I've been using RTK since 1995, lots of other issues but not that one. Not sure what you mean by localize but that may be part of it.

 
Posted : August 3, 2015 5:20 am
(@surveydana)
Posts: 10
Registered
Topic starter
 

When running on the networks, they are typically close to the city benchmarks however they are off slightly. In order to run on the city datum, I need to localize on the given elevation datum. When arriving to a jobsite for the first time, we localize on the city datum then set our control based off of that point. We then check back in to the same benchmark and thats where the problem lies.
What GPS unit are you using MightyMoe? I have used both Altus and Geomax and have yet to be pleased with either.

 
Posted : August 3, 2015 5:25 am
(@mattsib79)
Posts: 378
Registered
 

I think your problem is procedural. Although I do not know your full procedure. I have used multiple GPS systems and have never had that issue. Maybe a tenth to 0.15' difference with different sattilite geometry but a foot is a real problem and all modern survey grade GPS receivers are capable of better than 1 foot.

My 0.02.

Btw I use Javad Triumph 2 base and Javad Triumph LS rover.

 
Posted : August 3, 2015 6:09 am
(@mightymoe)
Posts: 9920
Registered
 

I have always used trimble, but I don't have any networks to tie to. It seems to me that networks have an issue using fixed control points such as NAVD88 bench marks. These of course are the standard in many areas for elevation control, FEMA maps, city data, DOT projects are often tied to them. What you seem to be doing is trying to shift the network parameters to the local elevation control.

This is a vexing problem, the CORS/OPUS and I presume private networks are constantly changing because of velocities and updates to GEOID models.

The way to handle it using a network rover seems to be to localize (calibrate) which is not something I would do.

What I would do it to occupy good elevation control with a base/rover set-up and use it with a projection and a GEOID model, but that option seems not to work with a network rover cause you have to shift over from the network elevation to the city datum.

Hence your localization.

My guess is that there is an even or almost even shift between the two, it would seem to be a simple thing to apply an up or down in an area to the network elevation to "get to" the real NAVD88 number.

Maybe that's all the localization is doing, however, my experience is with calibrations, and they are doing a lot more than a simple shift, some of it I don't like at all.

I would find out just what the localization does in your data collector, also it would be interesting to see just what the shift is between a number of elevation points and the raw network number, maybe there is a way to shift to the city datum with a simple subtraction or addition. And maybe that's all the localization is doing. Clearly something bad is happening, unacceptably bad.

 
Posted : August 3, 2015 6:25 am
(@surveydana)
Posts: 10
Registered
Topic starter
 

I agree with your methodology MightMoe. The part that is troubling me... besides the vertical shifts is that it is completely inconsitant. One day it works great, the next day it jumps during the day. Localizing on the known point in Carlson is essentially like doing a remote elevation. It takes what the network thinks is 99.9 and calls it what the city calls the elevation... 100.00. It then runs on that vertical plane or at least it should. I am going to try out Leica with Microstation sometime this week... the hard part is re-creating the problem.

 
Posted : August 3, 2015 7:10 am
(@paden-cash)
Posts: 11088
 

I can't say as I've ever heard of anything like that happening. My first guess would be the DC using some stored rover rod height vs. the current height...that just happen to be a foot apart.

Things that make you go "hmmmmm....".

 
Posted : August 3, 2015 7:13 am
(@surveydana)
Posts: 10
Registered
Topic starter
 

That could be the case... hmmm... o.O But I am able to check into existing control and old topo points.... then sometime between point A and B... I get the "SHIFT"

 
Posted : August 3, 2015 7:20 am
(@surveydana)
Posts: 10
Registered
Topic starter
 

The only conclusion that I have been able to come with is either hardware.... Altus... or software... Carlson

 
Posted : August 3, 2015 7:21 am
(@mightymoe)
Posts: 9920
Registered
 

surveydana, post: 330191, member: 8658 wrote: The only conclusion that I have been able to come with is either hardware.... Altus... or software... Carlson

Are you sure you aren't seeing an input issue? One foot is really a red flag, 4.5 rod height instead of 5.4 or something like that.

These kinds of issues are almost always driver error

 
Posted : August 3, 2015 7:28 am
(@toivo1037)
Posts: 788
Registered
 

Are you accepting float shots?

 
Posted : August 3, 2015 7:40 am
(@surveydana)
Posts: 10
Registered
Topic starter
 

I only accept fixed shots and typically take 20 readings on my control. It is definitely not a rod height.... I use a fixed rod and this has happened on various crews. Same issues. The odd part is that I come off of known control and check flat. There are no rod adjustments done in between or at any point after.

 
Posted : August 3, 2015 8:25 am
(@thebionicman)
Posts: 4438
Customer
 

What sort of network are you on? I can go to the next valley and get service with decent QC numbers. Elevations float over a foot as a matter of routine. The network is fine, it just wasn't designed to cover that area..

 
Posted : August 3, 2015 8:37 am
(@surveydana)
Posts: 10
Registered
Topic starter
 

I am using both AZGPS and SmartNet. Have this same issue with both networks. I have a project right next to an AZGPS base station and had 0.90' vertical jump a few weeks ago. That could be the case... but if its the coverage... then shouldnt it bounce around everytimg on that job? Not just randomly?

 
Posted : August 3, 2015 8:41 am