if rawAmbientPressure exist on info, why temperature is not

Yes, if you can, please file a ticket on this. From my own experience I can quite understand the design choices that went to the limitations on DataField apps, but somehow I feel temperature is standing out here. It really should be in the Activity info and I don't think there are a resource penalties connected to that. Nor there should be a compatibility impact.

Here's my Garmin SDK story: I'm an outdoor/winter swimmer. The on-board temperature sensor on Fenix watches is surprisingly precise, when submerged in water, so the built-in temperature data-field is very useful. However, the temperature stored in the FIT record is integer, and the one decimal place of precision that is lost matters (in fall season, that's about how much the water temperature drops between two workouts), so the temperature records in Garmin Connect are not a great data track.

So I thought - I'll design my own datafield (with blackjack and ...) , that work just as the built-in datafield, but has it's own fitcontributor that stores temperature with one decimal precision. (I can then use those records to track the water temperatures in the lake we swim over the year etc.). However, this seemingly trivial task is almost impossible - Temperature is not in the Activity info, so I can't get update on compute call. I can't use Sensor module, because I'm in DataField. If I use the trick with Background, I can anyways read it every 5 minutes, that's not very frequent for swims that usually take 10-15 minutes ;). I can use SensorHistory, but then I'm only slightly better - one update in 2 minutes - that's still too sparse.

To me, this proposed enhancement is really just a tiny bit of API change that could unlock a lot of realistic usages such as mine.

Yes, if you can, please file a ticket on this. From my own experience I can quite understand the design choices that went to the limitations on DataField apps, but somehow I feel temperature is standing out here. It really should be in the Activity info and I don't think there are a resource penalties connected to that. Nor there should be a compatibility impact.

Here's my Garmin SDK story: I'm an outdoor/winter swimmer. The on-board temperature sensor on Fenix watches is surprisingly precise, when submerged in water, so the built-in temperature data-field is very useful. However, the temperature stored in the FIT record is integer, and the one decimal place of precision that is lost matters (in fall season, that's about how much the water temperature drops between two workouts), so the temperature records in Garmin Connect are not a great data track.

So I thought - I'll design my own datafield (with blackjack and ...) , that work just as the built-in datafield, but has it's own fitcontributor that stores temperature with one decimal precision. (I can then use those records to track the water temperatures in the lake we swim over the year etc.). However, this seemingly trivial task is almost impossible - Temperature is not in the Activity info, so I can't get update on compute call. I can't use Sensor module, because I'm in DataField. If I use the trick with Background, I can anyways read it every 5 minutes, that's not very frequent for swims that usually take 10-15 minutes ;). I can use SensorHistory, but then I'm only slightly better - one update in 2 minutes - that's still too sparse.

To me, this proposed enhancement is really just a tiny bit of API change that could unlock a lot of realistic usages such as mine.