How is SDK 7.4.3?

7.4.3 is the only version I've used, and it appears to be usable. None of the bugs I've found have been showstoppers.

What bugs have you found?

Again: what bugs do you see in SDK 7.4.3 that you don't see in 7.3.1? All the above seem to be (though not 100% sure I read it correctly) happening for you in all SDKs?

The reason it happens IMHO is because you haven't started a simulation. After you run your app in the simulator open Simulation > Activity Data and in the window click on the black play button in the left-bottom corner. It'll give you correct HR values, I'm pretty sure the rest will be OK as well. If not let me know in the relevant bug report

> Again: what bugs do you see in SDK 7.4.3 that you don't see in 7.3.1

As I said initially, I have only ever used 7.4.3.

The 2**31 -1 number is certainly something I have seen on the watch itself. It appears that Garmin uses the greatest +ve number as a flag sometimes. I would have thought NaN would have been better, but perhaps they use that for something else.

255 is officially the invalid HR, and it's 2^8-1, so it would make sense for the 2^32-1 as well.

1148788 said:

A few functions return the largest possible number (e.g., reading the altitude, which gives 2*31 - 1, and the heart rate gives 255) to signify invalid data, which is undocumented as far as I can see - I guess this affects all SDKs

1148788 said:

The 2**31 -1 number is certainly something I have seen on the watch itself. It appears that Garmin uses the greatest +ve number as a flag sometimes. I would have thought NaN would have been better, but perhaps they use that for something else.

Assuming that the underlying value in question is an integer, it wouldn't be possible to use NaN as a special invalid value, as NaN is a float. Sure, in Monkey C, a given field might have a mutable type, but this might not be possible or feasible in the underlying C implementation, or in the activity FIT file specification. [Quantities like altitude and heart rate are written to activity FIT files.]

It's annoying that this isn't documented in the context of Connect IQ, but I think what you're seeing can be explained by the invalid values in the FIT protocol specification (see below).

I guess it would be nice if the Connect IQ framework would intercept these invalid values [even if they're part of the underlying implementation] and translate them into something like null, but that's probably not gonna happen.

One conceivable advantage of the current scheme is that if the dev happens to read HR data (for example) and write it to the FIT file as a developer field, the value of the developer field should match the value of the native field at any given point. [As a counter-example, it wouldn't be possible for an app to write null to a FIT file. The closest thing to "writing null" would probably be to write the invalid value.]

[https://developer.garmin.com/fit/protocol/]

The specific issue I had was with positionInfo.altitude, which is supposed to return a Float. It returns 2**31 -1 if you don't have a GPS fix.

That is strange because watches with barometer should be able to tell you the elevation based on the last calibration even with GPS off (or GPS on but in a Faraday cage)

It occurs for me if I enter the SUNRISE complication from a watchface, and go further into the complication where it draws a map. When I return to the watchface, I get the altitude 2**31 -1 issue until a new GPS fix is found, e.g., by starting a run.