Complete
over 5 years ago

By Design.

Corrupt time_offset in a watch app FIT file when time zone is negative.

The problem is in the "time_offset" field in the "device_settings" message in the FIT file generated from a watch app.

The time_offset value is correct with a positive time zone but it is corrupt when the time zone is negative.

To replicate

A. to show it works with a positive time zone:

Create an Activity file from a watch app in a time zone east of the Prime Meridian, i.e. with a positive time zone.

I tested in Sydney (UTC+11).

Decode the FIT file with FitCSVTool.jar

Observe the device_settings time_offset field is correct.

I received the correct value of 36900 (11x60x60)

B. to see the error:

Re run in a time zone west of the prime meridian, i.e. a negative time zone, like USA CA (UTC + 8)

Decode the FIT file with FitCSVTool.jar

Observe the device_settings time_offset field is incorrect.

I expect time_offset,"-28800" (-8x60x60), I receive, time_offset,"4294938496",

It's not a problem with FitCSVTool:

I receive the same incorrect value with my FIT file decoder, so the problem is not within FitCSVTool.

The problem appears to be the way the negative time_offset is being generated.

Work-around:

The work around is to subtract 0x1000000 from the incorrect value.



Alan.raceQs
  • over 5 years ago in reply to Travis.ConnectIQ

    You are correct: Base Type #6 is uint32. I was reading my (incorrect) documentation, not my code. Sorry for introducing a red herring.

    When I selectively override the provided base type (6) of the time_offset field with 5, the conversion is correct.

    I think that the bug is that time_offset is supplied with Base Type #6 and it should be #5. 

  • over 5 years ago in reply to Alan.raceQs

    > The baseTypeNumber is indeed coming in as 6: Signed Integer, and I'm processing it as such.

    The time_offset field of device_settings is a uint32. You can see for youself by looking at the Messages tab in Profile.xlsx, by looking at table 4-6 in Flexible & Interoperable Data Transfer (Fit) Protocol.pdf. It clearly documents Base Type #6 is uint32.

    > But when I examine the value I'm getting 0x808FFFFF(4294938496)  not 0xFFFFFF8F80 (-28800)

    The endianness of the data depends on the platform that wrote it out. When you read the data back you need to look at the endian bit to see what endianness the file uses, and if the endianness of the platform your decoder is running on is different, you'll have to swap bytes.

  • over 5 years ago

    Hmm no. The baseTypeNumber is indeed coming in as 6: Signed Integer, and I'm processing it as such.

    But when I examine the value I'm getting 0x808FFFFF(4294938496)  not 0xFFFFFF8F80 (-28800)

    (Looks like an incorrect application of endianness?)

    Remember FitCSVTool is also being confused.




  • over 5 years ago in reply to jim_m_58

    Yes, you're right.  Without delving into my code, I guess that since both FitCSVTool and I use the baseTypeNumber to decode this as an unsigned integer instead of a signed integer, then the baseTypeNumber in the definition record must be wrong. 

  • over 5 years ago in reply to jim_m_58

    4294967295 is -1 if treated as a signed 32 value for example.

    In my last post, I think it should have been -28800 if it was a signed 32 bit value, so the number of seconds in 8 hours, and exactly what you expect.