• State Verified Answer
  • Replies 3 replies
  • Subscribers 11 subscribers
  • Views 701 views
  • Users 0 members are here
Options
Related

python SDK weight_scale, weight - potential bug

8294519
I wrote an encoder based on the pythonSDK test_encode_activity_recipe.py. It seemed to work well except for the weight key like below:

mesgs.append({
    'mesg_num': Profile['mesg_num']['WEIGHT_SCALE'],
    'timestamp': scale_date,
    'weight': 8400, #decoding issue?
    'muscle_mass': 66.0,
    })Code


The 'weight' is a weight type and supposed to be in kilograms; however, it seems to scale incorrectly (8400 instead of 84.0kg). The other keys that use mass (eg/ muscle_mass) all convert from to kilograms okay when uploading the FIT file to Connect. Perhaps it's a type weight vs type unit16 issue? Thoughts?

Thanks!
PS Hopefully I'm writing this in the correct place, apologies if not.  
  • 0

    Hello, this is the correct place to raise this question.

    You are right that the issue is due to the weight field in the weight_scale mesg having a type of weight (enum) rather than a uint16. The weight type is a uint16 value under the hood but is interpreted by the Python and JavaScript SDKs as an enum rather than the intended numeric type. 

    This causes both the encoder and decoder to handle the value without applying or reversing the scale/offset. For example, when encoding a weight with a decimal e.g. 85.56, the encoder will currently truncate the value to 85 rather than apply the scale of 100.

    'weight': {
    '0xFFFE': 'calculating',
},

    Thanks for bringing this to our attention! We'll work on getting this fixed in both SDKs and address this post when it has been released.

  • +1

    With the release of the 21.208 SDK, this behavior is now fixed. Weight in the weight_scale mesg is now properly a uint16 and will apply scale as expected when either encoding or decoding data.

    The new version was published to PyPi available here: https://pypi.org/project/garmin-fit-sdk/ 

  • 0 in reply to Eli FIT

    Thanks for the explanation and the fix! I uploaded some new data and it indeed has been corrected.