[8.0 RC2] Sensors tab - Baro Alt graph not updating

[0crap]

Current Behavior

When flashing 8.0 RC2 firmware the Configurator (8.0 RC2) does not update the Baro Alt graph.

The Configurator 8.0 RC2 does show the Baro Alt graph moving correctly when the FC is still on firmware v7.1.2
Which makes me believe it's an FC firmware issue.

Steps to Reproduce

1. Flash MATEKF405 with full erase option to 8.0 RC2
2. Use "Airplane without a tail" defaults
3. Finish the FC Calibration
4. Select the Sensors tab
5. Baro Alt graph (blue line) is stuck at zero.

Expected behavior

Baro Alt graph updates correctly

Additional context

The Configurator shows the correct Baro setting: BMP280

---

version
INAV/MATEKF405 8.0.0 Dec 5 2024 / 11:00:03 (9e8bd553) dev
GCC-13.2.1 20231009

FC Board name and vendor: MATEK F405-STD
INAV version string: MATEKF405

[0crap]

Interesting part is that I have to paste in my "diff all".
Only flashing and load defaults is not enough to get the Baro Alt graph moving.

In any case, FC and Configurator on 8.0 RC2 with a diff all does NOT move the Baro Alt graph.
FC and Configurator on 7.1.2 with a diff all does show the Baro Alt graph moving correctly.

I'll try to find what that specific setting is, if I can find it.
Edit: Yep it needs the Calibration procedure to finish for the Baro Alt graph to start updating.
If I do that all is fine on 7.1.2, still stuck at zero on 8.0 RC2.

[b14ckyy]

Did you update with full chip erase?

[0crap]

Did you update with full chip erase?

Of course, as noted in the opening post.
Added the FC Calibration step as well in the opening post for a 100% reproducible issue on my side.

[breadoven]

Altitude in 8.0 is held essentially at 0 until first arm so it won't change until you've armed. I think vertical acceleration will have some affect before first arm but only if it's significant.

[0crap]

Altitude in 8.0 is held essentially at 0 until first arm so it won't change until you've armed. I think vertical acceleration will have some affect before first arm but only if it's significant.

Can you explain why this is done please?
Since hight can also come from the GPS (e.g. in flight the Alt OSD reading works), checking the blue line was the only option to see if inav was using the Baro sensor data correctly.
Is it possible to make an exception that, if a MSP connection is active (Configurator connection), the Baro Alt, blue line, is working as it did in the v7 Configurator?

I see this new behavior as unwanted for the v8 Configurator.

[breadoven]

Can you explain why this is done please? Since hight can also come from the GPS (e.g. in flight the Alt OSD reading works), checking the blue line was the only option to see if inav was using the Baro sensor data correctly. Is it possible to make an exception that, if a MSP connection is active (Configurator connection), the Baro Alt, blue line, is working as it did in the v7 Configurator?

It actually holds vertical velocity at 0 to avoid issues with false vertical velocities coming from Acc sensor thermal drift which in turn causes false altitude offsets when the FC is in fact static and not moving. This issue is significantly improved by compensating for the Acc thermal drift via iNavFlight/inav#10382 in which case the vertical velocity 0 clamp could be removed perhaps. Should try and get this included in 8.0 rather than slipping it to 8.1.

I'm not sure how the blue line can be used to check the Baro sensor though because unless inav_reset_altitude is set to NEVER the Baro altitude used by position estimator is constantly set to 0 prior to first Arm so wouldn't have any affect on the Altitude (same for GPS altitude used by position estimator). Note: The Baro altitude shown in the sensor tab is the raw calibrated Baro altitude which uses a 0 datum based on the Baro altitude when the Baro was first calibrated at boot up.

It should be possible to change how this works when connected via MSP but it's probably better to fully understand what users are expecting from the sensor tab outputs first.

[0crap]

@breadoven I read your reply a few times.
As you can see the blue line moves fine when firmware v7.1.2 is installed.

As soon as I flash firmware v8.0.0 it does not. (Stuck at zero.)
The setting you mentioned inav_reset_altitude does indeed make the graph move again when set to NEVER.
(Graph is moving a lot less with the same movement, but OK, not stuck at zero when set to NEVER.)

Anyway, the default setting is FIRST_ARM, which makes it look like it's stuck to zero when firmware v8.0.0 is installed on the FC.
Still not sure why this behavior changed between v7 and v8, when using the default setting of inav_reset_altitude = FIRST_ARM.

Simple users like me look at the blue Baro Alt graph to see if the Baro works and INAV uses it for calculating hight.
99% of the users test for this, with the craft on the bench, only connected via USB to the Configurator, with no GPS fix.
Which means, always in a disarmed state.
As it is now, 99% of the users will see a blue Baro Alt line stuck at zero when v8 is installed.
Wondering if there is something wrong with the Baro, when they move the plane up and down on the bench, to verify Baro is working correctly.