FIT File Processing for Accident Reconstruction

<div class="section abstract"><div class="htmlview paragraph">It is becoming increasingly common for bicyclists to record their rides using specialized bicycle computers and watches, the majority of which save the data they collect using the Flexible and Interoperable Data Transfer (.fit) Protocol. The contents of .fit files are stored in binary and thus not readily accessible to users, so the purpose of this paper is to demonstrate the differences induced by several common methods of analyzing .fit files. We used a Garmin Edge 830 bicycle computer with and without a wireless wheel speed sensor to record naturalistic ride data at 1 Hz. The .fit files were downloaded directly from the computer, uploaded to the chosen test platforms - Strava, Garmin Connect, and GoldenCheetah - and then exported to .gpx, .tcx and .csv formats. Those same .fit files were also parsed directly to .csv using the Garmin FIT Software Developer Kit (SDK) FitCSVTool utility. The data in those .csv files (henceforth referred to as “SDK data”) were then either directly compared to the test platform data or written to .kml files using a custom MATLAB script and uploaded to Google Earth for comparison, which yielded the following conclusions. First, when imported into Google Maps, the latitude, longitude, and timestamp data from the .gpx and .tcx files matched the SDK data almost exactly; however, the speed data for the .gpx and .tcx files all appeared to be calculated via backwards differentiation of the GPS data, regardless of whether a wheel speed sensor was in use or not . Second, when imported into a spreadsheet, .gpx files contain no speed or distance data; on the contrary, .tcx files imported in Excel do report speed and distance data that exactly match the SDK data. Third, all the test files maintained generally the same number of data points as the SDK data (barring some minor discrepancies around auto-pauses) with the exception of the files produced by Golden Cheetah, which interpolated times and positions for missing data points to artificially produce 1 Hz resolution. Fourth, the SDK .csv file contained non-activity data - connected ANT+ and Bluetooth devices, hardware product model, software version, and more - that none of the other exported file types contained.</div></div>