We're using Catalyst DA2 with Field Maps on iOS. Normally the receiver name listed on the features we collect starts with "DA2". I noticed the receiver name on features collected using one of our units starts with "Trimble" instead of DA2 (like "Trimble #6156523441"). Is that normal, or does it indicate a configuration issue? I'm troubleshooting some inaccurate elevation values collected with this unit and the name caught my eye.
The device showing up as "Trimble..." will be on an old firmware version and should be updated through TMM (TMM should show a prompt to update the receiver if you connect to the DA2).
Thanks Mark! Good to know. Is there any chance outdated firmware could cause elevation accuracy issues? We got some unexpected results that I'm struggling to explain. As far as I can tell the user configured everything properly in TMM and Field Maps, had it mounted on the pole properly, etc. Outdated firmware is the only thing that seems outside the norm, so I'm grasping at straws.
You shouldn't see elevation issues as far as I remember, I think elevation issues are more likely down to configuration. Feel free to let me know your Field Maps Location profile information as well as how you have your GNSS Config setup in TMM and I'll try to help. Also more information about the accuracy error you are seeing would be useful.
Thanks Mark. The elevations we collected with a DA2 were about 8-10 feet lower than a survey from 2020 and LiDAR data from 2021. The survey and LiDAR agreed with each other within 0.1-0.2 feet. There has been some minor surface grading since then, but not that much. The DA2 was on a 2 meter pole. Vertical accuracy values ranged from 0.03 m to 0.06 m.
I think I found the main issue. For some reason, the orthometric height recorded on the points in Field Maps was off. I performed a vertical datum transformation in ArcGIS Pro from NAD83 2011 to NAVD88 using the ellipsoidal height recorded in the Altitude field. It is about 6 feet higher than the orthometric height recorded to the point geometry in field maps through TMM.
I'm not sure what would have caused this. If the user had forgotten to change the GEOID from the default EGM96, the difference should only be about 1 foot in this area (according to some experimentation I did in NCAT). We've collected hundreds of points with DA2 units and have not seen this issue before (although, we don't normally compare results to previous surveys or LiDAR).
These are the usual settings we use, and the ones the user says were used in this case:
Good morning. I can assure you that the DA2 will hit within a tenth or so if you are comparing apples to apples. You can create an Arcade script as a calculated expression in AGOL within the Field Maps Designer that will calculate orthometric height. The settings that you are reporting in TMM and ESRI Field Maps are set correctly. In my area, i have very old 2010 lidar that will match (in an area where ground hadn't been disturbed) within a tenth or two vertically. Lastly, if you are calculating the orthometric height in ArcGIS Pro post-field, make sure to calculate or apply the geoid 18 separation value on the Z geometry, as that will be in Geoid 18 Conus (NAVD 88 Height FTUS or INTL FOOT).
Hi Zach - Thanks for the comment. I agree with everything you said. The confusing thing in this case is that the actual z geometry on the points populated from TMM is wrong. I already had the Arcade script setup on this layer to populate an elevation field with the z geometry. The value it populated at the time of collection matches the value if I calculate it in ArcGIS Pro. But, if I convert the ellipsoidal height (altitude GNSS field) to orthometric using GEOID18 after the fact, there is about 6 feet of difference.
We've never had an issue like this on hundreds of other collected points over several months. I'm going to chalk it up to the user misconfiguring something somewhere. At this point I was just trying to figure out how it happened so we can avoid it in the future.
My apologies for the crazy long delay here. I hope that you figured it out either way. Keep in mind that the orthometric height (or ellipsoid height) shown in TMM does NOT include the antenna height (you would have keyed this into Field Maps). If you subtract 2m (or 6.562') from your number in TMM, it should equal or be very close to to your arcade-calculated expression for orthometric height.
Hi Zach - I think the final resolution was similar to what you suggested. I still don't understand why the pole height was reflected in the ellipsoidal height but not the ortho height from TMM. I'll assume it was user error and hope that it doesn't happen again.
I wish the pole height setting was captured in Esri's GNSS metadata somehow, but that's a separate topic...
The pole height is not reflected anywhere in TMM. Both the Ellipsoid height and Orthometric Height in TMM do NOT have antenna heights factored in. The antenna height is entered in within your third party software (ESRI, etc.). The pole height is incorporated in the ellipsoid height stored in your attribute table. The Z geometry holds your orthometric height and antenna height is factored in. I have tested this numerous times on 1st order control. Feel free to message me via this platform or email at firstname.lastname@example.org.