-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repeated set of samples in the SML export #1
Comments
Hi, I've never seen a spec for the SML file format so I don't know if it's allowed to have separate events from different sources at the same timestamp. The GPX file format is not complex IIRC, so I guess that it would be much more efficient and robust to directly output a GPX file without having to go through ambit2gpx. One less step! If you are not afraid of writing a few lines of Ruby code, you can create polar_training2gpx by copying And to know what the final GPX file should look like, an easy way would be to export the training session from Polar Flow as a GPX file, or try https://github.com/pcolby/bipolar. If you go this way: pull request welcome! |
Hi there, thanks.
Maybe I can share some data with you to verify it's not a bug and exclude 1? what would you need? unfortunately, i am not a ruby programmer (that's why I was hoping it was it was something I could fix in python :-)) so i may not help with a new exporter... |
If you know Python, you should be able to adapt to Ruby ;) BTW, you can sync to Polar Flow through the Android/iOS app, no need for Windows or macOS. I gave it a very quick shot (15 min!) : c632f80 This exports the training session track to GPX -- I get the exact same result as the GPX export performed from Polar Flow. Give it a try. |
Thanks! |
Hi, I just bought an M200 and would like to export traces to be used with my local applications, my workflow is:
In step 2 I have an sml file with two repeated sets of data, with the same time reference, but with different data:
against:
And this goes on for every sample. When converting to gpx, things gets messed up, with some of the data being rewritten. I am not familiar with suunto, is this an intended behaviour of the suunto format? in this case the blame would be on ambit2gpx that does not merge the two sets of samples. But why there two set of samples corresponding to the same time with different SampleType?
The text was updated successfully, but these errors were encountered: