Making sense of cycling dynamics left_power_phase*, right_power_phase*

Greetings,

  I'm trying to understand the FIT_RECORD_MESG struct values of left_power_phase and right_power_phase (and their _peak siblings). The documentation/marketing material for power phase says, that the power phase has a start angle and an end angle.

The power phase fields in the struct are defined as follows:

typedef struct
{
...
   FIT_UINT8 left_power_phase[FIT_RECORD_MESG_LEFT_POWER_PHASE_COUNT];
   FIT_UINT8 left_power_phase_peak[FIT_RECORD_MESG_LEFT_POWER_PHASE_PEAK_COUNT];
   FIT_UINT8 right_power_phase[FIT_RECORD_MESG_RIGHT_POWER_PHASE_COUNT];
   FIT_UINT8 right_power_phase_peak[FIT_RECORD_MESG_RIGHT_POWER_PHASE_PEAK_COUNT];
...
} FIT_RECORD_MESG;

and

#define FIT_RECORD_MESG_LEFT_POWER_PHASE_COUNT           1
#define FIT_RECORD_MESG_LEFT_POWER_PHASE_PEAK_COUNT      1
#define FIT_RECORD_MESG_RIGHT_POWER_PHASE_COUNT          1
#define FIT_RECORD_MESG_RIGHT_POWER_PHASE_PEAK_COUNT     1

So declared as arrays but with an element count of 1. So it's just one field, only one angle value.

The comment for the record fields says:

Data value indexes defined by power_phase_type.

and there are constants declared that I suppose are array indexes

typedef FIT_ENUM FIT_POWER_PHASE_TYPE;
#define FIT_POWER_PHASE_TYPE_INVALID                    FIT_ENUM_INVALID
#define FIT_POWER_PHASE_TYPE_POWER_PHASE_START_ANGLE    ((FIT_POWER_PHASE_TYPE)0)
#define FIT_POWER_PHASE_TYPE_POWER_PHASE_END_ANGLE      ((FIT_POWER_PHASE_TYPE)1)
#define FIT_POWER_PHASE_TYPE_POWER_PHASE_ARC_LENGTH     ((FIT_POWER_PHASE_TYPE)2)
#define FIT_POWER_PHASE_TYPE_POWER_PHASE_CENTER         ((FIT_POWER_PHASE_TYPE)3)
#define FIT_POWER_PHASE_TYPE_COUNT                      4

Seems like I'm missing something that has been configured differently for the SDK generator. Any idea what that is? The C++ implementation doesn't shed any light on this either.

Thanks for any pointers!

Herb

  • OK, so right after sending this I realized that I may have to make the arrays larger by putting their correct dimensions into the config.csv like this:

    ,left_power_phase,,"4"
    ,left_power_phase_peak,,"4"
    ,right_power_phase,,"4"
    ,right_power_phase_peak,,"4"

    Regenerating the SDK turns this into arrays with 4 elements. Compiling the SDK into the decoder application works fine too and I can read the demo file (activity_lowbattery.fit) fine - apparently.

    But I'm puzzled why the decoder worked with a 1 dimensional array declaration just well and it makes me wonder if the solution really is one.

    Regards

    Herb

  • Putting 4 in the config.csv is correct. Messages in the FIT C SDK are C structs and the memory is determined at compile time not runtime. If both the encoder and decoder are using the FIT C SDK, the SDK is smart enough to read the entire array from the file but then only store the number of bytes configured for a field by the decoding SDK. This comes in handy for strings where the server may have written 255 bytes but the device only allocates space for 64. 

    This is not an issue for the other SDKs since the message definitions are dynamic as are array sizes.

    In the SDK .zip is the file Profiles.xlsx. The array column indicates if a field is known to be an array. Sometimes you see a number, and sometimes you will see "[N]". The number will automatically be added to the config.csv file, and the "[N]" means each product defines its own size. Usually for strings. 

    An "[N]" in that column makes the field an opt-in in the config file, whereas an actual number would make that field an opt-out. The value would need to be something that everyone would use in order for it to be opt-out. That is why the phase fields are not hardcoded to 4.

    I say "known to be an array" because in FIT any field can be encoded as an array. But there are some fields that are meant to be arrays. When a field is known to be an array, in the OO based SDKs there will be getters/settings that include and array index parameter. 

  • Sorry for the delayed response on my part and many thanks once again for your elaborateness. Your support is very much appreciated!

    Best Regards

    Herb