Mapping and GIS Solutions Community

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.

Thanks!

#Catalyst #esrifieldmaps

Hi Jamie,

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).

Regards,

Mark.

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.

Thanks!

#Catalyst #esrifieldmaps

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.

Hi Jamie,

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).

Regards,

Mark.

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.

Thanks!

#Catalyst #esrifieldmaps

Hi Jamie,

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.

Regards,

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.

Hi Jamie,

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).

Regards,

Mark.

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.

Thanks!

#Catalyst #esrifieldmaps

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:

TMM

• Correction source auto
• Output frame NAD83 2011 EPOCH 2010.00
• GEOID18 (CONUS)

FIeld Maps

• GNSS coordinate system GCS NAD 83 2011 (6318)
• Map coordianate system WGS 84 web mercator (3857)
• Antenna height 2 meters

Hi Jamie,

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.

Regards,

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.

Hi Jamie,

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).

Regards,

Mark.

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.

Thanks!

#Catalyst #esrifieldmaps

Jamie,

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).

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:

TMM

• Correction source auto
• Output frame NAD83 2011 EPOCH 2010.00
• GEOID18 (CONUS)

FIeld Maps

• GNSS coordinate system GCS NAD 83 2011 (6318)
• Map coordianate system WGS 84 web mercator (3857)
• Antenna height 2 meters

Hi Jamie,

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.

Regards,

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.

Hi Jamie,

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).

Regards,

Mark.

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.

Thanks!

#Catalyst #esrifieldmaps

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.

Jamie,

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).

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:

TMM

• Correction source auto
• Output frame NAD83 2011 EPOCH 2010.00
• GEOID18 (CONUS)

FIeld Maps

• GNSS coordinate system GCS NAD 83 2011 (6318)
• Map coordianate system WGS 84 web mercator (3857)
• Antenna height 2 meters

Hi Jamie,

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.

Regards,

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.

Hi Jamie,

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).

Regards,

Mark.

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.

Thanks!

#Catalyst #esrifieldmaps

Jaime,

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 - 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.

Jamie,

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).

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:

TMM

• Correction source auto
• Output frame NAD83 2011 EPOCH 2010.00
• GEOID18 (CONUS)

FIeld Maps

• GNSS coordinate system GCS NAD 83 2011 (6318)
• Map coordianate system WGS 84 web mercator (3857)
• Antenna height 2 meters

Hi Jamie,

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.

Regards,

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.

Hi Jamie,

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).

Regards,

Mark.

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.

Thanks!

#Catalyst #esrifieldmaps

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...

Jaime,

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 - 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.

Jamie,

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).

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:

TMM

• Correction source auto
• Output frame NAD83 2011 EPOCH 2010.00
• GEOID18 (CONUS)

FIeld Maps

• GNSS coordinate system GCS NAD 83 2011 (6318)
• Map coordianate system WGS 84 web mercator (3857)
• Antenna height 2 meters

Hi Jamie,

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.

Regards,

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.

Hi Jamie,

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).

Regards,

Mark.

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.

Thanks!

#Catalyst #esrifieldmaps