FIT files, GPX files, Simulator and Playback File

I'd like to use the Playback File feature of the simulator to test my code.
To support that effort, I'd like to create short FIT files with various types of motion data in them.
I have both FIT files and GPX files that contain representative data, but I want to use short segments of the data in those files.
I had hoped that I could use some GPX tools that I have to select a track segment, save it as a separate GPX file, then convert that into a FIT file that the simulator would accept.
I can create small GPX files from selected track segments, and convert to a FIT file using the GPSies web site, but when select that file for Simulator Playback, the simulator does not play the file back. I get no error messages, but the simulator acts as if no data was read in.
So... one solution is some way to convert from a GPX to a FIT that the Simulator will accept.

Another option I've looked for is some way to select a part of a FIT file, save it as another FIT file, and then play that back in the Simulator.
I haven't found any tools that allow me to look at the track contained in a FIT file, select a segment, and save it as a smaller FIT file that the simulator will accept.

If any of you can point me toward a solution, I'd really appreciate it.
Thanks
  • I'd like to use the Playback File feature of the simulator to test my code.

    I think the playback feature is not the right tool to test your code, you should have a look at the run no evil option instead (see the prog doc), I also did a 3-part tutorial about it ( http://starttorun.info/garmin-connect-iq-tutorial-overview/ , see tutorial 4, 5 & 6)

  • Former Member
    Former Member over 7 years ago
    asandweech...
    Partial1 is accepted by the simulator to the extent that it delivers around 63-66 samples from the file.... and then stops delivering samples to the app.
    Partial 2 delivers no samples to the app when selected for playback in the simulator.

    Are you sure they deliver no samples to the simulator? Looking at the contents of both FIT files, they both have a hefty amount of data in them -at least 40 minutes in the first, and a decent amount more in the second- but in the first one, there is nearly an hour long break between the 59th record and the 60th record, and about 9 minutes between the 59th record and the next group of laps. If you wait out that period in the sim playback, it seems to work just fine for me. Looks like that FIT file got joined just fine, it even preserved the time between start and stop, as I would want if I were trying to join them for continuity reasons (autopause).

    The second FIT file is slightly different as it has several laps at the beginning of the FIT file that are timestamped around 45 minutes before the start of any records. I don't know how the sim parses the FIT files time-wise and I don't have the time to check this one as well, but I might guess that it starts at the first lap time in the file, and it would eventually get to the records.

    I might recommend downloading the FIT SDK for future analysis of FIT files. Can be found here: https://www.thisisant.com/resources/fit/
    Also, to second Peter, RunNoEvil can be good for unit testing your fit file playback.

    UPDATE: I did actually get a chance to run the second FIT file. 46.2 minutes in, records started appearing, matching the data in the FIT file. All seems fine.
  • For me, if I want to test something in specific, by way of a .fit, I'll just record a .fit with just that - maybe 10 minutes of a longer activity.

    I went back and looked at this thread, and I guess I'm not quite understanding what you are trying to test that you want parts of .fit to run in the sim. Instead of trying to do it with a long .fit, maybe if we understand a bit more of what you want to do, other things may present themselves, like Peter suggesting RNE for example.
  • Peter.... thanks for the pointer to "run no evil". I'll take a look at that, and your tutorials to see if that looks like a better way for me to test my logic.

    asandweech... my experimental code updates displayed values and calls Sys.println() to report progress every time a GPS sample arrives.
    When running with the files I uploaded, the updates either don't start, or stop prematurely. Given my testing needs, having a 45 minute gap before data from the file begins to run through my code is a pretty severe problem. Thanks for the link to the fit file tools. I'll check that out as well as RunNoEvil.

    jim... creating new files is more complicated than you might think. I don't want to give details of my application at this point, but it involves motion analysis, with specific types of events that can by identified by analyzing motion changes. I have representative data from past data collection (2-4 hrs at a time), and will have an opportunity to collect more as time goes on, but collecting more data involves people and equipment that I don't have regular access to. So.... using data that I have, that includes real representative data that I want to analyze is very valuable, and going out to create a small, test data set isn't easy. There is also a lot of value in using many sets of test data to check the logic, so having an efficient way to do testing is important.

    Thanks all.
    Jeff
  • Peter...
    I've looked through the programmer's guide "how to test" description of Run No Evil, and through the tutorials that you provided a link for.
    I don't see anything about feeding data from a FIT file or any other file into the code for testing.
    Is there something I'm missing ?
    Running data through the logic to see if it is recognizing patterns is the problem I'm trying to solve, and running specific segments of data will save huge amounts of time.
    Does Run No Evil support this kind of testing somehow ??
    Jeff
  • Former Member
    Former Member over 7 years ago
    Given my testing needs, having a 45 minute gap before data from the file begins to run through my code is a pretty severe problem. Thanks for the link to the fit file tools. I'll check that out as well as RunNoEvil.
    ...
    I have representative data from past data collection (2-4 hrs at a time), and will have an opportunity to collect more as time goes on, but collecting more data involves people and equipment that I don't have regular access to. So.... using data that I have, that includes real representative data that I want to analyze is very valuable, and going out to create a small, test data set isn't easy.

    To give an example usage of the FIT SDK, you can use the FitCSVTool to convert between fit files and csv files. After converting them to csv, with a little bit of work in a text editor or excel you could try stringing together multiple records of your test data and then modifying the timestamps to remove the gaps. Then you convert back to a FIT file and the result might be something you could use. It's no graphical editor, but it might give you a bit more control than the online service.
    As for run no evil, it is only a unit testing framework and to my knowledge there is no ability to control FIT file playback from within it. Test data would be controlled by the unit tests and passed into your processing functions. I could see the use for having that control though and it seems like a decent feature request.
  • you shouldn't feed the values through a FIT file when using the run no evil framework, but rather set up a mock and provide it with data-patterns yourself. For the creation of the data patterns you could fetch these from the fit file and convert it to data values yourself though.

    there is no ability to control FIT file playback from within it. Test data would be controlled by the unit tests and passed into your processing functions. I could see the use for having that control though and it seems like a decent feature request.

    Personally I think playing back fit files exceeds the scope of the run no evil framework. It's a unit test framework. The ideal unit test tests a specific part of your business logic and finishes in milliseconds, so that you can rerun your tests often. Whenever one of your tests break it should be a quick pointer to which part of your business code is going wrong.

    I'm not saying that long running integration tests can not be useful and sometimes there is no other way to have things tested, but personally I'm more of a fan of small atomic well aligned tests whenever possible. :)

    If you want the FIT playback feature from within the run no evil framework then you should create a feature request topic in the forum, preferably accompanied with it's usecase and how you expect to call this api and interact with it, then the connect iq team can evaluate whether or not they want to have this functionality made available to the framework.