Problem with enhanced_altitude when decoding a Zwift FIT file with Java SDK

kcfwpi 1 month ago

I am using the Java SDK to decode a FIT file generated by Zwift. It looks like something is wrong with how enhanced_altitude is encoded by Zwift, or decoded by the Java SDK. When using this file:

https://drive.google.com/file/d/1suDM7ez9kQJvYwvKYPQp7hiqghb83cGa/view?usp=drive_link

The following line of code:

System.out.println("enhanced altitude: " + mesg.getEnhancedAltitude());

Prints this:
enhanced altitude: 4.294967296E9

Note this is on the record message.

Strangely, this file is processed by Garmin Connect and Strava without an issue. The elevation graph is correct.

Is the file encoded incorrectly? Is it a bug in the Java SDK? Am I doing something wrong?

Any help would be greatly appreciated!

0 kcfwpi 1 month ago

Update: the altitude field is populated correctly, unlike enhanced_altitude, so I suspect Strava, Garmin, etc. are using that value. I guess I'll just discard enhanced_altitude if it equals the max unsigned 32 bit int.

0 FlowState 8 hours ago in reply to kcfwpi

kcfwpi said:
I guess I'll just discard enhanced_altitude if it equals the max unsigned 32 bit int.

enhanced_altitude is internally encoded as a uint32, so it's appropriate that an invalid value is signified by the max value for uint32 (see Fit.UINT32_INVALID). (As with altitude, fractional values for enhanced_altitude would be encoded using the scale field in the message definition)

The real question is why the java sdk is returning that value instead of returning null.

Do you build with Fit.ENABLE_LEGACY_BEHAVIOUR set to true (which is the default value)? If so, the decoder should return null for invalid values, instead of the invalid value itself. If ENABLE_LEGACY_BEHAVIOUR is false, then the decoder would return the invalid values themselves.

You never call Decode.showInvalidValues(), right? That would also make the decoder return the invalid values themselves, instead of null.