Is there documentation that describes in detail, what will cause the Simulator to accept or reject a FIT file for playback ? If so, please direct me to it. Thanks
Former Member
The simulator should accept and parse any properly formatted FIT activity file. Note that the data that is being parsed is primarily the FIT "record" messages, which are processed to read the latitude, longitude, speed (or enhanced speed), power, altitude (or enhanced altitude), cadence, distance, heart rate, base pressure, temperature, and calories. If the file is lacking "record" messages, or the messages contained in the file lack the data points that are processed, parsing the file may not produce usable results. If there are large time gaps between the "record" messages in the file, the data parsed will only update at the time interval between the records because the file is parsed real time.
If you have a FIT file that you believe is formatted correctly, but does not give expected results when parsing in the simulator, I can take a look at the file.
Thanks for your response Brian. What I'm looking for, what I need to do rigorous testing of my code, is a way to run selected GPS track data through the simulator... preferably in real time and in accelerated time, so that the time I put into testing is used well, and so that I can repeatedly run the same real world data through my logic. So far, I see no way to use the tools available to accomplish that.
The files attached were created using the following procedure: - Record track data on the watch using an app (not mine). - Transfer that data as a FIT file to my computer using Garmin Connect. Note: Feeding that FIT file into the Simulator works, but there is a lot of data, ~45 minutes or so, that is not interesting and not useful at the beginning of this file. - Also transfer that data as a GPX file to my computer using Garmin Connect. Note: This step is necessary because I have found no tool that allows me to select a part of a FIT file track, and save it as a new FIT file that the Simulator will accept. - Import the GPX file into HomePort to select a useful segment of the track for use in the Simulator. - Export the selected segment as a GPX file. Note: HomePort, a Garmin product, does not export track data as FIT files.... this would solve the problem. - Because I have found no Garmin tool that will take a GPX file as input, and produce a FIT file, I use GPSies.com to produce a FIT file from the GPX file
Sometimes, the resulting FIT file is quietly rejected by the simulator.... no error message, and the "Playback File" menu item is not grayed out, indicating that it's still ready to accept a file. Sometimes, the resulting FIT file seems to be accepted... the "Stop" menu item is available... but no data is being delivered to the app (some time stamp problem apparently).
While looking at my FIT file and telling me what the problem in the file is might be interesting, it will not help me solve the fundamental problem I'm trying to solve.
I need a way to take a segment of a GPX file and produce a FIT file that will run that segment of a track, without delays, through the Simulator, in order to test my code. I've tried using FitFileTools.com..... if you select the start of the track and delete it, you get a file that the Simulator won't accept, or that has a large delay before data arrives in the app. I've tried using the time correction tools there... no success. Since that's not a Garmin product, I don't expect much help here... but where is a tool from Garmin, that works, that fills this gap between Garmin GPS product output, and Garmin Simulator data input ? Or where is a product that allows selection of a part of a FIT file track to be saved as a FIT file that the Simulator will accept ? Or how about reading GPX files into the Simulator to simulate GPS data ?
For anyone who wants to repeatedly run real world data through their code during development, this is a very large hole in the tool set. I sincerely hope that you can point me at a solution that works reliably, that is supported by Garmin, and that does not require that I spend my time learning about the internals of FIT files, in order to take selected GPS data and use it for testing in the Simulator.
Attached are - the GPX file of selected data, that was produced by HomePort - This forum would not load the GPX file. I got a message "Invalid File" - a CSV file of that same data, that was produced by HomePort - the FIT file produced by GPSies.com from that GPX file Note: This file is not accepted by the Simulator.... it's not just a delay issue.
I hope that you, or someone at Garmin, can provide a solution that supports the use of selected track data from GPX files for testing in the Simulator, or -- provide a solution that allows a subset of track data in a FIT file to be selected and saved and used in the Simulator.
Running a GPS track at accelerated time is not something we can easily do. We could speed up the rate at which the file is processed, but this would not generate an effect that matches running the file at normal speed.
I took a look at your file, and the reason it is rejected by the simulator, is that it has been written out as a course file, and our simulator only accepts activity files. At first glance, I don't see any functional reason why we could not parse a course file, so I will propose adding this capacity. Your file does appear to parse properly if I remove this restriction.
If you remove points from the file and are still seeing a large delay before the ones you wish to simulate are reached, then this indicates there are still other messages with offset time stamps in the file (e.g. a lap message). There are tools available in the FIT SDK to convert .fit files to .csv files. It is not the easiest format to manipulate, but you can easily delete messages in this format and convert back to .fit. The FIT SDK can be found here https://www.thisisant.com/resources/fit. Converting files back and forth from CSV to FIT can be troublesome, but I was able to convert your file from a course type to an activity type.
The file you returned does run in the Simulator, without any delay. As I described, the source of the file was HomePort which exported a track as a GPX file, then converted in GPSies. The GPX files that I've exported in HomePort are imported as Tracks into OpenCPN, so I'm fairly sure that they are not being exported as Courses, but as tracks. The output option that I select on the GPSies web site says Track, with a selection box where I choose Garmin FIT (Ant+), so where & how the resulting FIT file contains some indication that it's anything but a track is a mystery, and is outside of my control. And how would I be able to know what the problem was ?
I've looked at the FIT SDK and it looks like a set of tools that, as you said, are likely to be "troublesome"... cryptic and error prone, which translates to burning lots and lots of time with only a marginal likelihood of success.
Hasn't anyone at Garmin recognized that there's value in being able to more easily view and manipulate the contents of FIT files, and that there's tremendous value in being able to do rigorous testing before apps go in the field ?
Are there FIT file tools that you have within Garmin that could solve this problem, that are not cryptic and "troublesome" ?
Playback at various scale factors applied to time is currently supported by Garmin's HomePort from 0.05x to 1000x, including 1x. A similar facility in the Simulator would be very useful indeed for anyone who is writing and testing code that analyzes GPS data, and probably other data. If the simulator still delivers the correct time for each sample arriving (preferably the actual time that it was recorded), the code being tested won't "know" whether the data is arriving in real time or not.
I've built simulators that operate this way, to test code that would run machinery that I could not have access to until very late in a development process, and to test code that operated very long processes. If your goal is to put reliable code in the field and help your app developers do the same, this type of testing is invaluable, and making the process easy is very important so that developers can focus on the code they are trying to develop rather than burning valuable time working against the limitations of the tools that are available to them.
If you don't make testing straight-forward, developers do less testing, and the customer gets to find the problems that the developer should have found.
I think I'm beginning to understand why I've seen apps crash on my watch, and even why the heart rate monitoring function just stops for no apparent reason (support told me to turn off the watch & restart... the CTRL-ALT-DEL "solution").
I'm sure my frustration is obvious, and it comes from having burned WAY too much time on a developer roadblock that should not exist, and going round and round with "almost" and "maybe" "solutions". Garmin should be providing either FIT file editing tools to support creating test data sets, or GPX to FIT conversion that ensures that the resulting files can be used for testing code through he simulator. Leaving that to third parties has lead to the problem I'm stuck with, resulting in me burning valuable time debugging a process that I should never have to think about.... valuable time that I cannot spend developing the app that I set out to develop.
I would love to talk with someone at Garmin who is in a position to allocate resources to actually do something about this.
I understand what you are looking for, and have forwarded your comments.
I identified the file as a course by using the FIT to CSV converter contained in the FIT SDK. We do not have any special internal tools to manipulate these files.
Unfortunately, the current tool wasn't designed to do this type of thing. The file playback does not send points from the file directly through your application. The file points are processed and injected into our data backends, which then generate output via the same mechanisms that drive this data on devices. This preserves the data flow of the application to the greatest extent possible, and allows testing of data callbacks using their native triggers. The original timing of the points is used only to pace the injection of the data into the backend, and does not remain attached to the data.
For the purposes of defect testing using a static data set, the unit test framework is going to be much better suited. However, there is no file reading capability for unit tests, and testing a set of GPS data would require converting that data to a JSON resource that can be consumed by the test.
Hi Brian, I just dove back into this issue and have found that there's good news. I can now use HomePort to create segments of a GPX file for testing, export a resulting GPX file from HomePort, run that GPX through GPSies, to create a FIT file, and the resulting FIT files (so far) are accepted by the simulator for playback.
As I'm sure you gathered from my messages in this thread, this is a very big deal for me. I don't know if there was a change by Garmin in the recent updates to ConnectIQ, or if the developer at GPSies who I spoke to made a change, but I'm happy that I have a method that works to create test files from existing GPX files.
Assuming that the fix was on your end.... thanks. Jeff
