all functions return NULL

[pyacobellis]

Hi there - thanks for this package, very excited by it.

fitfiles.zip

I am using a Garmin Forerunner 935. I have read in a .fit file, presumably ok, but if I run any function on the FIT object, like records for example, I receive a NULL value.

`

library('FITfileR')

file1 <- readFitFile('70069248542.fit')
file1
Fit File
├╴File created: 2020-10-06 13:00:00
├╴Device: garmin 2691
└╴Number of data messages: 4182>
records(file1)
NULL
laps(file1)
NULL

`

When looking at the object in the list viewer, it looks like everything is there, and looks comparable to the results of your fenix6 example.

Is something wrong with my code?

Thanks so much,
Paul

[grimbough]

It doesn't look like there's anything wrong with the code. Thanks for providing the example file, I'll take a look at what's happening.

[grimbough]

Hi Paul,

Thanks again for the files. FITfileR actually seems to work as expected for one of them, at least as far as using records() goes:

library(FITfileR)
f1 <- readFitFile("/tmp/92820190267.fit")
records(f1)
#> $record_1
#> # A tibble: 247 x 10
#>    timestamp           position_lat position_long distance altitude speed
#>    <dttm>                     <dbl>         <dbl>    <dbl>    <dbl> <dbl>
#>  1 2021-05-21 04:03:14        -33.8          151.     0.22     62.8  0   
#>  2 2021-05-21 04:03:15        -33.8          151.     1.03     62.4  0   
#>  3 2021-05-21 04:03:16        -33.8          151.     6.67     62.8  2.52
#>  4 2021-05-21 04:03:17        -33.8          151.     6.67     62.8  2.52
#>  5 2021-05-21 04:03:18        -33.8          151.    12.7      63    2.64
#> # … with 242 more rows, and 4 more variables: heart_rate <dbl>, cadence <dbl>,
#> #   temperature <dbl>, fractional_cadence <dbl>
#> 
#> $record_2
#> # A tibble: 281 x 10
#>    timestamp           position_lat position_long distance altitude speed
#>    <dttm>                     <dbl>         <dbl>    <dbl>    <dbl> <dbl>
#>  1 2021-05-21 04:14:05        -33.8          151.    2080.     67.2 2.67 
#>  2 2021-05-21 04:14:07        -33.8          151.    2084.     68   2.65 
#>  3 2021-05-21 04:14:10        -33.8          151.    2090.     68.8 2.58 
#>  4 2021-05-21 04:14:11        -33.8          151.    2092.     69   2.55 
#>  5 2021-05-21 04:14:15        -33.8          151.    2100.     70   2.50 
#> # … with 276 more rows, and 4 more variables: heart_rate <dbl>, cadence <dbl>,
#> #   temperature <dbl>, fractional_cadence <dbl>

---

As you've seen that's not the case for 70069248542.fit. We can use the function listMessageTypes() to see what's actually stored in the file:

f2 <- readFitFile("/tmp/70069248542.fit")
listMessageTypes(f2)
#> [1] "file_id"         "event"           "device_info"     "software"       
#> [5] "monitoring"      "monitoring_info" "ohr_settings"    "stress_level"

The no record or lap messages in this file, which is why those functions are returning NULL. My guess is that this file wasn't recorded from an activity, but rather output from one of Garmin's "body tracking" functionalities. I've not looked at these before, but the pertinent message types are probably the "monitoring" messages.

If FITfileR doesn't provide a specific function for the message type you want you can always use getMessagesByType() and give the name of the message type from the list shown above:

getMessagesByType(f2, message_type = "monitoring")
#> $monitoring_1
#> # A tibble: 154 x 2
#>   timestamp           current_activity_type_intensity
#>   <dttm>                                        <dbl>
#> 1 2020-10-06 13:03:00                               8
#> 2 2020-10-06 14:03:00                               8
#> 3 2020-10-06 15:03:00                               8
#> # … with 151 more rows
#> 
#> $monitoring_2
#> # A tibble: 3 x 7
#>   timestamp           distance cycles active_time active_calories duration_min
#>   <dttm>                 <dbl>  <dbl>       <dbl>           <dbl>        <dbl>
#> 1 2020-10-07 13:00:00       0       0          60               6         1440
#> 2 2020-10-07 13:00:00   10347.   6809        7724             228         1440
#> 3 2020-10-07 13:00:00     285.    125         157               3         1440
#> # … with 1 more variable: activity_type <chr>
#> 
#> $monitoring_3
#> # A tibble: 2 x 1
#>   timestamp          
#>   <dttm>             
#> 1 2020-10-06 13:00:00
#> 2 2020-10-07 13:00:00
#> 
#> $monitoring_4
#> # A tibble: 2 x 1
#>   timestamp          
#>   <dttm>             
#> 1 2020-10-06 13:00:00
#> 2 2020-10-07 13:00:00
#> 
#> $monitoring_5
#> # A tibble: 668 x 2
#>   timestamp_16 heart_rate
#>          <int>      <int>
#> 1         8420          0
#> 2         9380          0
#> 3        10340          0
#> # … with 665 more rows
#> 
#> $monitoring_6
#> # A tibble: 19 x 2
#>   ascent timestamp_16
#>    <dbl>        <dbl>
#> 1  7.29         29696
#> 2  2.72         29706
#> 3  0.424        29721
#> # … with 16 more rows
#> 
#> $monitoring_7
#> # A tibble: 24 x 2
#>   descent timestamp_16
#>     <dbl>        <dbl>
#> 1    4.62        29660
#> 2    5.43        29806
#> 3    2.26        29816
#> # … with 21 more rows
#> 
#> $monitoring_8
#> # A tibble: 57 x 5
#>   cycles active_time active_calories timestamp_16 current_activity_type_intensi…
#>    <dbl>       <dbl>           <dbl>        <dbl>                          <dbl>
#> 1      8          60               0        29600                             38
#> 2     20          60               0        29660                             65
#> 3    512         629              46        30260                             70
#> # … with 54 more rows

We can see there's quite a few different types of "monitoring" message. It's not clear to me what they all are, maybe you have a better idea what you're hoping to find in the file and that can shed some light on things.

There's a few things I'll add to FITfileR to try and smooth this out going forward:

• It'd be nice to have a more informative output from the accessor functions like records() if a message type is missing, rather than just returning NULL
• Looks like adding a monitoring() function to explicitly grab this type of message might be useful
• I'll take a look at the timestamp_16 datatype and workout what processing is require to turn that into something more user friendly.

[pyacobellis]

Wow thanks for checking into this Mike and working on updates. I'll take a look at those files and do a bit more digging myself.