ArcPad accuracy issue

[Roli]

Has anyone experienced inconsistent accuracy during data collection with Arcpad? We�??ve just discovered these issues and it appears to be caused by ArcPad.  We are using Trimble ProXT & Pro6T ( submeter) units. We are usually testing the units before deployment and that�??s how we discovered the issue:  ArcPad might introduce an offset ( ~3ft) .

Here is our setup: Windows 7 tablet PC-s , with ArcPad 10.04, connecting BT to Trimble GPS unit. We tested with multiple PC units ( 1 EliteBook HP, 3 Panasonic TB H-2, 2 Xplore iX104C4) as well as multiple GPS units ( 2 ProXT, 2 Pro6T, 1 Pro6H) . Tested with ArcPad 10.04 as well as 10.2 ( same issues).

Test: created ArcPad test project and used 1ft, 2ft,,3ft,�?�5ft radius circles ( layer) to check if the GPS point is within specs. Target point (circle center) was digitized using 3in aerial imagery .

ArcPad GPS settings ( used on all units):
Protocol : NMEA,
Averaging set at  10 positions,
GPS = DGPS only.

All tests were done using real time differential correction ( DGPS). DGPS status is shown in screenshots attached to this post. Initially, we thought the H-2-s are the only PC-s affected but it turned out it is not hardware dependent (tested with multiple PC-s and multiple GPS units, at the same time-almost).

Opened support ticket with ESRI but they were not aware of such issues.

Cause : issues seemed to arise when replacing user computers (came across the issue when deploying  a new H2 tablet, win 7) . When moving files from old PC to new PC, all user files were copied . This included MyDocuments containing the old MyArcPad and ArcPad folder. When installing ArcPad , another ArcPad folder gets created and we discovered both folders showing up in Windows Explorer (in MyDocuments) .

Note: Initially, the GPS was within specs (under 3ft) for some users and out of specs (about 6ft off ) for other users. Later on, not sure why, GPS showed as off for all users. We tested using users with standard permissions as well as local admin. It didn't seem to matter.

Solution: the only workaround for this was to uninstall ArcPad, delete all related folders for all users , restart and reinstall ArcPad. We thought we just need to pay attention to this when replacing computers only�?�. We�??ve also planned on testing the data collection systems, weekly.

Well,�?�today I checked one of our  data collection systems ( H2 + ProXT + Arcpad 10.4) and it was off again, even though no duplicate folders existed in any of the profiles ( not a newly deployed/replaced PC).  Reinstalling  ArcPad did fix the problem.

Questions to be answered:  What is the real cause of this accuracy issue? What do users have to do to prevent it from happening? Has anyone else experienced such issues?

Thanks!

[Anonymous User]

Original User: blackbrett

Are you applying any sort of transformation? You mentioned DGPS, so I am assuming this is via SBAS corrections, is that correct? I am not certain where you are located, but when using SBAS and a NAD83 State Plane projection for example, there needs to be a transformation applied as there is a meter plus shift (depending on your area) that needs to be accounted for to achieve the desired results.

[Roli]

Using SBAS indeed. I am in So Cal ( NAD 83 CA Zone VI). I am not using any transformations ...  I would say we do have the right settings,  since the data collected is within GPS unit specs. However,  we discovered that ...sometimes....an offset is being introduced ..... . That's the problem we are trying to figure out: what causes the offset? 

I am suspecting some ArcPad settings associated with the user profile ( just like having to enter the authorization code for every user , instead of once per install). I've always tested the GPS system ( PC + GPS + ArcPad) using my login and results were always right on. At this point, I would say the safest solution would be to use only one account for each PC ( but that would be against our IT policy/no generic accounts). Maybe that's why there are no similar issues on Windows Mobile devices ( only one user/profile)....and based on the replies I am NOT seeing :-).... that must be the majority of the setups out there ( ArcPad running on Windows Mobile). 

Thanks!

[Anonymous User]

Original User: blackbrett

What is your GPS Datum set to in GPS Preferences? If set to WGS84 and not utilizing a transformation of any sort, then that is your issue. SBAS utilizes ITRF and if you are in a NAD83 State Plane Zone for your projection, you will experience a shift of approximately 1 meter if not more depending on the area. The "offset" or shift here would be constant based on the difference between ITRF and NAD83, the variable you are seeing is likely your GPS accuracy.

[Roli]

I have not set any transformations. I usually create my APM-s using ArcMap ( that's where I make sure data frame is set to NAD83). I would think that ArcPad should resolve these transformation on the fly. Here is a document I found regarding this Understanding Evolution of Datums WGS84 and NAD83  . Attached is my ArcPad datum info - to me , it looks like the transformation is hadled ( even though I didn't define a transformation ). 

I tried to configure the transformation , to test it but there isn't enough documentation out there to help with this task ( find the right values for all the parameters) . I'll keep looking. Feel free to post links to  additional  info on this subject, if you can.

Here are my thoughts: if I have the wrong settings , my data should be off consistently... and that's not the case here. My data looks just as expected ( maybe because ArcPad handles the transformation on the fly)  then.... sometimes is off . This SOMETIMES is what bothers me! 🙂 And this issue , showing up SOMETIMES,  seems to be resolved by uninstalling ArcPad... ( not by changing APM settings).

Thanks again!

[Anonymous User]

Original User: blackbrett

ArcPad can apply transformations on the fly if you have built a transformation in the ArcPad Datum Configuration Tool, but as you mentioned, documentation is limited, so perhaps contact your local dealer to provide more information on this tool as well as tech support on your issue at hand.

The best test is to check into known control monuments to make certain the points your are capturing are within your accuracy specs.

[Roli]

Brett,

Using control points/monuments would be best... 🙂 I'll create an incident with support to get assistance with the transformation. However, I can see this helping us getting tighter points but not resolving the "random" accuracy issue.

BTW, do you think the "once in a  while" issue with accuracy is normal, even with the current datum settings? I suspect there is an ArcPad setting that is affecting this....just because reinstalling ArcPad resolves it. I am suspecting this because I have applied this fix and imediately issues are resolved . I did the reinstall in the field and tested it right away, trying to test under identical conditions - this way I eliminate changes in parameters like satellite configuration, real -time signal...

What is your setup? How many units do you have doing data collection? How many are using tablet PC-s with Win OS? 🙂

Thanks!