In the Obj-C SDK, FITDeveloperField.getValueFor(0) returns 0 for developer fields with base type sint32 (0x85 / 133) when the value is negative. Positive sint32 values decode correctly on the exact same code path. Java SDK (via FIT CSV Tool and fitfileviewer.com) reads the same files correctly, including negatives.
Same field name (calibration on device_info), same base type, same SDK build — only the sign differs.
Reading code (called from a MesgListener):
let name = devField.definition.getFieldNameforIndex(0)
let rawNumber = devField.getValueFor(0)
let baseType = devField.definition.getFitBaseTypeId()
print("name:\(name ?? "nil") rawNSNumber:\(rawNumber) baseType:\(baseType)")
Output:
// File with negative values on disk (e.g. -45 per Java SDK):
dev field — name:calibration rawNSNumber:0 baseType:133
dev field — name:calibration rawNSNumber:0 baseType:133
// File with positive values:
dev field — name:calibration rawNSNumber:108 baseType:133
dev field — name:calibration rawNSNumber:107 baseType:133
Looks like the sint32 path isn't sign-extending — values with the sign bit set get clamped to 0 instead of returned as negative. Worth checking sint8/sint16/sint64 too.
Happy to share test files. Thanks!