The Accelerometer senses 25 times/sec, but don't see that in the FIT file?

The app I am working on is a Rowing Stroke Counter (with Companion Android App), I initially tried to use the Activitie's currentCadence but as discussed here  it looks like that isn't going to fly, and I need to calculate strokes myself with Accelerometer data, (yipee!) so  now I'm looking at Pitch Counter....I can see that it records Accelerometer data to FIT file, so I just started the App and rowed 10 strokes at 20strokes per minute...and then downloaded the FIT file, then exported as CSV using this tool 

Just looking at the data (see screenshot) it looks like the Y axis is what I can use to count strokes.

My question though concerns the frequency of data recorded in the FIT file, I understand that the PitchCounter is sensing movements 25times/sec 

var options = {:period => 1, :sampleRate => 25, :enableAccelerometer => true};

But it appears that the FIT file is only recording one entry per second.....can anybody explain? To properly analyse the stroke, I'll need multiple data points per second.

  • On many devices, there are two ways to do recording (Settings>system>data recording on the device.

    There's "every second" and "smart" (some device may only have one of these).

    every second is just that - smart is that it writes to the fit when it needs to (which could be every few seconds).  Smart reduces the size of the fit file.

    There's no way to record 25 times a second (the fit would get huge for one thing)

    You need to analyze the data in your app, so that it can be written only once per second.

  • OK so FIT file is going to have limited data. For development, do you think I could log data more frequently than once per second into some other file format?

  • The only way to log is use something like println() or print() with a log file set up, but at 25 times a second you could get into time issues as it's hitting the file system.  Plus the size of the log is limited before it fills.

  • OK thanks I'll give it a go, I only want to record about 30s of data to analyse

  • Do the export using FIT SDK https://www.thisisant.com/resources/fit-sdk/. I don't know how the simulator handles data at a higher frequency than once every second but it is possible to store information recorded at a higher frequency, HRV is one example.
    What happens is that the device stores the data internally and then writes all that data every second.

    Problem with tools like fitfileviewer, and others, is that they tend to interpret the FIT file to give human readable output. FIT SDK is capable of exporting the raw data to a CSV file.

  • As the developer of the FITFileViewer, I can tell you that there is very little interpretation in this tool. If it does not show in the tool, it is probably not in the FIT file. Do you have an example were the interpretation is different from the raw data?

  • I did something like this to analyze golf swings.  Mostly, I wanted to get the lower level accelerometer data to be able to run simulations on the PC.  Better programming tools there, not to mention better graphing.  I'd use MakeWebRequest to send the raw data to my server (accumulated, not in real time).  A bit easier in that case as I'd only need a few seconds to get a golf swing.  A companion app might be a better route, but I'm not set up for phone development.

    Using the activity fit file for this would be very challenging as it's hard to know for sure exactly when the data is getting recorded to the activity file, so how do you even know when to update the data in your custom fit file fields.  

  • Hi Harry.  I know this is a late reply, but I just started looking into this topic for an app I am writing. When I view the fit file with your tool (which is great by the way - thanks for making it available to us), it seems to only show the first value of the compressed_calibrated_accel_X, Y and Z fields.  But that field actually holds all the values recorded per second in a compressed form, with a vertical bar ( | ) character separating the different values.  For example, in one of my fit files your program show an X value of 2960, which is only the first value of the field that actually looks like this: 2960|2212|212|-1308|-416|548|492|340|308|296|292|300|372|252|284|300|416|436|400|324|272|372|380|396|400

  • I just used Harry's tool to look at one of my fit files and notice it's missing a lot of stuff.  Both a lot of message types, and a lot of fields within each message type.  It seems to ignore fields that it doesn't understand (or maybe that aren't officially public), rather than displaying them with just the message and field ID.  I have my own fit viewer that is a windows program (as opposed to an online tool) which does display all messages and fields in the .fit file.  For messages and fields I don't understand, I just display the ID's rather than friendly names.

  • In response to the latest replies re www.fitfileviewer.com, I recently launched a new version that much better handles subfields/component fields and shows meaningful names for e.g. products. There is also a switch to move into developer mode, where you see all data as it is stored in the FIT file.

    If you visited the site before, you may still see the old version, which has a control menu (gear wheel icon) in the top right. Reload the page (Ctrl-Shft-F5) to get rid of the old version in your browser cache.

    If you find that something is not shown, or not show properly, submit the file so I can fix it. The FIT protocol is not fully documented, manufacturers can add their own properties to it, so it is only by submitting incomplete files that it can be improved.