Byte-order in developer fields reversed

Hi Herb, the endianness of the data is defined in the architecture bit of the corresponding definition message and should apply for the whole message, including the developer fields. 

What power values do you see on your device when you do the workout? If the problem lies in your power sensor you should also see wrong values then. If not, the problem lies in the device that created the final fit file.

Workaround can be that you detect this situation (use of Stryd + firmware version of the Stryd + workout type) from the device info messages at the beginning of your fit and in that situation reverse the byte order.  

Hi Frank,

  many thanks for the reply. 

The FIT files we have come from one of our users, and meanwhile we're convinced that this is a firmware issue in the recording device.

We have 2 FIT files where two of the developer fields (Power and LSS) are in the correct byte order (as in "like the rest of the file's native fields") and one (Form Power) is reversed. We have multiple files that have all three fields reversed.

This behavior is consistent with the workout type the user selects. If it's "Structured workout" the device produces fully mangled/swapped developer fields. If it's "Just Run" (not sure if that is the correct term used by Stryd) then he gets files with mixed endianness in the developer fields (in the same message).

Will look into checking the architecture bit but given the endianness mixing happens in a single message, I don't see how this would help. The only idea we have is looking at the data and if implausible values come along, byte swap them see if that looks more reasonable and use those instead. From a robustness perspective this leaves a lot to be desired.

This started happening mid August, so maybe a firmware update was pushed to devices around that time.

Just reporting back that the architecture bit did prove very useful to figure out whether or not to change the byte order. This fixes 75% of the broken developer field values.

I say broken because evidently the generator produces BE or LE field values at random as well as additional garbage value fields that are neither BE nor LE. I guess we will see this mysteriously fix itself by way of firmware update at some point.

Thanks again for your help getting most of it back!