Feature Request: Dedicated Altimeter view with Climb Sensitivity, "Alt Steady" state, and detailed metrics (Graph, Ascent/Descent, Slope)

[ficals]

When using the Altimeter set strictly to barometer mode while stationary (e.g., camping at a campsite for extended hours), natural atmospheric pressure changes cause noticeable altitude drift.

Because every small barometric pressure fluctuation is interpreted as an elevation change, it registers false climbs/losses and skews overall elevation stats despite zero physical movement. Relying on GPS altitude mode, which consumes significantly more battery during stationary periods and suffers from signal degradation under dense forest canopy, indoor environment, or cliff sides. Also relying on DEM (Digital Elevation Model) mode often yields inaccurate elevation data depending on the grid resolution and region, making it an unsatisfactory alternative.

I would like to suggest a comprehensive enhancement setting parameter to the Altimeter tool:

Climb Sensitivity & "Alt Steady" State

To prevent altitude drift while stationary:

• Climb Sensitivity Threshold Setting: Allows users to define the sensitivity/threshold required before a pressure change is registered as actual elevation movement (e.g., Off, Low, High). Example Threshold Rule: An elevation change is only recorded if the detected change exceeds 2.4 meters within a 15-minute window. Any pressure variation below this threshold rate is filtered out as weather-induced pressure drift or minor fluctuations (such as wind gusts or raising an arm).
• Altitude Status Indicator ("Alt Steady" vs. Rate of Change): Displays an "Alt Steady" status when pressure changes remain below the set threshold. Dynamically updates to show the rate of altitude change (climb/descent rate) once movement exceeds the threshold.

Dedicated Altimeter Tool Screen with Detailed Metrics

A dedicated view for the Altimeter tool providing in-depth elevation analytics over time

• Detailed Altitude Graph: A time-series chart showing altitude trends over custom timeframes.
• Total Ascent & Total Descent
• Minimum & Maximum Altitude
• Current Slope / Gradient (%)
• Vertical Speed Rate

Combining adjustable climb sensitivity with a dedicated altimeter view would make Trail Sense much more reliable for mountain trekking and overnight camping, keeping elevation logs accurate without relying on power-hungry GPS or inaccurate DEM data.

Furthermore, with a dedicated altimeter tool, users can also utilize it inside tall buildings/skyscrapers (e.g., measuring floor height or elevator speeds) or during activities like cliff rappelling/descending where GPS signals suffer from severe obstruction.

Thank you so much for your hard work and dedication in developing and maintaining Trail Sense! It's an incredible open-source tool for outdoor enthusiasts, and your efforts are greatly appreciated!

[kylecorry31]

Hi, thank you for the suggestions.

• Have you tried the DEM + Barometer or GPS + Barometer modes? I created them specifically for the drift problem and I've used them on several mountain hikes and they've been very accurate.
• Is the 2.4 meters per 15 minutes just an example value or is that backed by some research that you could share?
• Are there other apps/tools (or research which suggests this approach in practice) that you use which perform this type of altimeter algorithms? If so, can you share them so I can take a look and compare?

I had tried out something like this in the past, but struggled with the edge cases. That eventually led me to create the GPS + Barometer and DEM + Barometer sources, they slowly pull the altimeter back down to their reading to account for atmospheric pressure changes, but rely on the barometer for quick movements.

I will think about revisiting this at some point in the future. But if there was a working proof of concept or another app which uses this approach, then I may move that up in priority.

Regarding the data points, most of those can be found in the paths tool for a backtrack recording and some are planned to be added later (#3245). The ability to pause backtrack will also help eliminate readings while stationary (#1004). I have considered a dedicated altimeter tool in the past, but decided against it for a variety of reasons (favoring Paths and Navigation for that info).

[ficals]

Hi @kylecorry31,
Thanks for the detailed response!

Regarding your questions:

• GPS / DEM Modes: I have used those hybrid modes, but keeping GPS enabled continuously drains the battery significantly during long, multi-day stationary periods (like camping or staying multi stories building).
• The $2.4\text{ m} / 15\text{ min}$ Threshold & Reference: This threshold value comes directly from Altimeter & Barometer Pro on iOS (App Store Link).
• They implement an "Alt Steady" state alongside an adjustable Climb Sensitivity Threshold. It locks the altitude when vertical movement falls below a user-defined rate (filtering out stationary pressure drift relying strictly on ambient pressure without needing to trigger GPS/DEM calibration cycles or wake up power-hungry sensors).

I've attached a few screenshots from the app showing this implementation for your reference. Outdoor watches (like Suunto's FusedAlti algorithm) use similar static drift-lock thresholds when no physical motion is detected.

Having a simple pressure filter / stationary altitude lock or toggle for baro-only mode in future updates would be an incredible addition to Trail Sense!

[kylecorry31]

Thank you, I will take a look and potentially create some follow on issues to experiment with a new barometer mode. I'm still not sure how this would recalibrate as drift accumulates errors over time, unless it is manual?

Can you elaborate on how you are using Trail Sense that you are seeing significant battery drain with those altimeter modes? I'm trying to figure out if this new mode would address that issue for you. I'm assuming you are using backtrack for that or opening the navigation tool, neither of which would see a reduction in GPS use with this unless you have the GPS sensor mocked.

[kylecorry31]

Here's an issue to track an experiment / proof of concept: #4028