Barometric pressure data useless

One thing to keep in mind is that most folks using a Garmin wearable in the pre-Connect IQ days had less use for raw pressure. As jim_m_58 stated above, the majority cared about MSL, so that's what we gave them. As Connect IQ has grown and developers are requesting more exposure we have continued to have an internal conversation about what it looks like to reconfigure some of the structures in place to expose more. From the perspective of the Connect IQ team, we're always trying to give our devs what they are looking for. We know that the more we give you, the more you can do and we all benefit from that. The reality is that big ships take a long time to turn and this is an example of that. So, take hope in knowing that real discussion was, is, and will continue to happen around the sensor data available to you.

Thanks,
-Coleman

As I understand, raw pressure value should be available with Connect IQ 2.4.
Now, what I want is raw GPS elevation - not available if the watch has a barometer.
With these two raw data we could implement a sensor fusion algo to have a *really* more precise and stable estimation of the altitude and close the gap with Suunto and their FusedAlti.

Garmin wearables use a one time (optional) GPS calibration for a baro (when you start an activity), while things like the Oregon allow the (optional) one time or continuous calibration.

For devices without a baro, when an activity is uploaded to GC, there is the default of "elevations correction" applied. The reason for this, is GPS elevation can be kind of bad based on a number of factors.

I've done tests with a device with a baro and one without at the same time. The actual change in elevation would be something like 40', and the baro would reflect that, while the elevation changes shown on the non-baro device would be more like 400'. I'm not sure I'd expect using GPS would make things more precise is what I'm saying.

Also, there's another variable involved - the temperature. The internal temp sensor in wearables is known to be imprecise at times, due to the influence of things like body temperature. So you may want to think about using a tempe.

Update: When I'd upload the non baro activity to GC and Elev Corrections are applied, it showed about the same data as the baro devices without elev corrections.

GPS alti estimation and barometer alti estimation have complementary error sources. GPS error can be erratic and coarse but cannot drift, barometer alti is precise but has drift due to weather/temperature changes.
So, they are perfect for sensor fusion, you can compensate each error source and have a good estimation. Drones are good example of this, they can fly at a very precise altitude, they all do sensor fusion.
One paper reference as an example http://www.crocodile.org/lord/baroaltitude.pdf . Other algos are available in literature.

It sounds like you are also taking military grade sensors/components. I kind of doubt those would fit in a watch that people could afford :) I imagine the GPS antenna in a drone is quite different than the GPS antenna in a watch too.

There are things like the D2 Charlie (a pilot's watch) where I'd also expect a different precision (and maybe HW) than in a runner's watch.

Not really. Majority of drones have the same consumer components as mobile phones or watches. Sure, more accurate measurements will yield better estimations - and you are surely right about better antennas in a drone than in a watch, but even with what we have in our watches we can improve accuracy by combining redundant sources and a GPS and a barometer are two sources of data we can mathematically fuse to yield a better estimate than each one alone.
Garmin hasn't done it in their firmware in contrary to Suunto. But Garmin watches have ConnectIQ so it could be great to have access to some raw (barometric pressure) or pre-computed data (GPS altitude) to enable us to work on this type of algorithm.

Next question.. If you do get better data, what will you do with it? You can display it on the watch, but not change what the watch uses when recording, displaying history, with widgets, etc.

You could add it as user/fit Contrib stuff to .fit files, but that doesn't replace the FW's data when you look at it on GC/GCM.

I know after using Garmin Baro devices for a while, the data I see now is fairly good. Yes, there's times it might starts +/-25 feet off, but ascent/descent still seems fine

I support usym view on sensor fusion. I worked on these type of problems quite a bit and you would be surprised how much you can improve the quality of measurements.
Of course, as long as this is not part of the FW it won't be better in every place of the watch SW but at least one can do it for its own app where (more) accurate altitude estimates are viable.

Anyway, I know red a couple of times that since SDK 2.4 raw pressure data is exposed to CIQ but so far I could not find it. Can anyone help? I might be blind, thanks!

It's in Activity.Info

Activity.getActivityInfo().rawAmbientPressue

(you can also see ambientPressure and MeanSeaLevelPressure in the same way)