We created an Quick Project for ArcPad 10, and it is using a VB script to pull the gps.z value I am assuming from the NMEA string (GPGGA) from the GPS unit. The GPS set up is a survey grade leica unit that passes the NMEA string to a Trimble NOMAD 800 via a serial cable. The NOMAD GPS has ArcPad 10 installed on it.
Examining the NMEA string from the Leica unit, I can see where the altitude is outputted from the unit along with height of geoid (in meters). The antennea height on the Leica GPS unit is set to 2m or ~6.56 ft.
In the ArcPad Quick Project, the map's coordinate system is set to State Plane Florida West (US Feet). The GPS protocol is set to NMEA 0183, Port COM1, Baud 4800, Antennea height 0 (US Ft), Geoid Seperation 0 (US ft). The option to use map units (feet) for height is checked.
There is a custom form created in the project for certain features where the collector can change the value of the antennea height and use the map units as default (which is feet). The default for this field is zero.
Here is the vb code specific for that feature type:
Dim AntHeight, ObjHeight
Dim tmpPage1
Set tmpPage1 = ThisEvent.Object.Pages("page1")
If ThisEvent.Object.Mode = 3 Then
ThisEvent.Object.Fields("Collection").value = Now
ThisEvent.Object.Fields("COLDATE").value = Now
End If
If GPS.IsOpen Then
AntHeight = CInt(tmpPage1.Controls.Item("txtAntenna").value)
ObjHeight = Abs(AntHeight - GPS.Z)
ThisEvent.Object.Fields("ElementZ").value = ObjHeight
End If
When the values come outof ArcPad10 in shapefile format, we run a simple script to correct the elevations against a geoid difference grid, and when these are compared to known bench marks, the elevations are consistently 5 ft higher. I know it is not the script correcting for the geoid difference as it is the same grid and mathematical calculations used in the project version for Arcpad7 run on a PDA and using the same Leica GPS unit to feed the NMEA string to the PDA. (The PDA elevations come in within a few tenths). I know that it is not the Leica Unit which is feeding the NMEA string to the NOMAD GPS unit because it feeds the string correctly to the PDA. It is also not a field collection issue.
Can someone give me an idea as to what might be causing the calculation error?
Below is a sample NMEA string from the leica unit and a known bench mark elevation.
Sample NMEA String:
$GPGGA, 141444.80, 2813.4106465, N, 08243.2780716, W, 4, 07, 1.3, 10.718, M, -25.348, M, 0.02, 0001*7D
Known Bench Mark Elevation: 37.3471
The only way I can get close within 0.4' of this known elevation is if I take the Altitude 10.718 and subtract it from the Geoid Height (-25.348) then convert this from meters to feet (36.066*3.28) and subtract -2' (which adds 2). (This value is supposed to be 2 m or ~6' as the specified antennea height from the gps unit but if I subtract 6' the elevations are ~ 9' higher). Then obtaining the geoid difference grid value (83.40384) for this xy coordinate (converted from meters to feet) and then subtracting the two values (83.40384-120.2965), I get an elevation of 36.89 which is a difference of ~0.42'.
Can someone explain what values ArcPad may be looking at from the NMEA string to calculate the elevation? I suspect that my mathematical procedure of using the altitude and geoid height may not be the right way to calculate the elevation, but it is the only way that I have found to get close to the known benchmark elevation.
Also, does anyone know what ArcPad might be interpreting to get a 5' offset (where the final elevations are higher than the known benchmark data)?
Are there any known issues with ArcPad 10 and calculating elevations from the NMEA stream?
Any help would be greatly appreciated!
Thanks,
Kathy
