Altitude mismatch and loss of precision when using External (Mock) position provider on iOS
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 52/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- cpp, ios
- Domain
- mobile-dev
Research direction
Start with the iOS External (Mock) position provider and the handoff of altitude into the MM GPS info panel. Compare that path with the direct Trimble connection, then reproduce using the listed DA2 and iOS versions. Done means the displayed altitude matches TMM's orthometric height and preserves at least centimetre-level precision.
Written by the indexing model from the issue text.
Description
Description
When connecting a Trimble GNSS receiver via the External (Mock) position provider on iOS, the altitude displayed in the MM GPS info panel differs from the value shown in Trimble Mobile Manager by approximately 0.4–0.5 m. Additionally, altitude values in the MM app appear quantised to 0.1 m increments (e.g. 129.00, 129.10, 129.30), indicating sub-decimetre precision is lost in transit through the iOS mock location layer.
The issue does not occur when using a direct Trimble connection — in that case altitudes match between TMM and MM.
Environment
[x] Staging [ ] PROD
Application (+ app version, build, operating system)
Mergin Maps iOS app 2026.4.0 / iOS 26.0
Trimble DA2, Serial: 6238100128, Firmware: 1.75 (Up to date)
Steps to reproduce
- Connect a Trimble DA2 GNSS receiver in the MM app using the External (Mock) provider on iOS
- Open the GPS info panel in MM — note the Altitude value
- Open Trimble Mobile Manager → Status → note the Orthometric height (MSL) value
- Compare the two values
Actual results
- MM GPS info panel shows 129.00 m (External Mock)
- TMM shows Orthometric height (MSL): 128.59 m — a difference of ~0.41 m
- MM altitude values are rounded to 0.1 m steps; sub-decimetre precision from the receiver is lost
Expected results
Altitude in the MM GPS info panel should match the MSL value reported by TMM within the receiver's stated vertical precision (0.02 m RMS). Precision should be preserved to at least centimetre level, consistent with behaviour when using the direct Trimble connection.
Screenshots or logs
(attached — MM GPS info panel + TMM Status screen, both captured at 11:30 CEST)
Conclusion
Created by Claude and supervised by a human test analyst.
- Dominant language
- C++
- Stars
- 388
- Forks
- 87
- Avg merge
- 4d 1h
- Merged PRs (30d)
- 23
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from MerginMaps/mobile
-
bug ui/ux
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
MerginMaps/mobile#4669 ·
-
bug Good first issue ui/ux
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
MerginMaps/mobile#4665 ·
-
bug ui/ux
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
MerginMaps/mobile#4647 · 1 comment ·
-
enhancement sync
MerginMaps/mobile#4713 · 2 assignees ·
-
enhancement performance qgis
Difficulty 4/5 3-5 days Newbie friendliness 35/100
MerginMaps/mobile#4701 ·
All issues in MerginMaps/mobile
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
ArthurSonzogni/FTXUI#1363 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 1/5 Under an hour Newbie friendliness 90/100
ginkgo-project/ginkgo#2108 ·
-
bug build
Difficulty 1/5 Under an hour Newbie friendliness 91/100
facebookincubator/velox#19194 ·
-
JIT-compiled number -> Decimal conversion silently overflows instead of raising DECIMAL_OVERFLOW Openfuzz
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
ClickHouse/ClickHouse#122114 ·