search

ColinPitrat / kalenji-gps-watch-reader

A tool to import data from some Kalenji running watches
GNU General Public License v3.0
30 stars 11 forks source link

Possible firmware bug for OnMove200 #74

Closed fpb closed 4 years ago

fpb commented 5 years ago

Hi,

After buying different gear (Amazfit Pace) I left my OnMove200 for more than a year and I was trying to use it as a GPX logger to geotag my photos.

I was having problems aligning the timestamps of the photos with the GPX stored values and it was not only a matter of UTC or localtime. GPX comes with UTC times and I can handle that easily because my geotag tool allows to do timeshift. The problem is that I discovered that the GPX file comes with absolute times always after the end of the run. So, let's say your run or walk starts at 9h00 and you end it and save it by 9h30. Your GPX times will be measured from 9h30 up to 10h00. The exact same values are present in the GPX file taken from decathlon coach if you transfer the OHM/OHD file with the OnConnect tool and download the GPX from there.

It was driving me mad and it is preventing me from using the damn watch for my intents.

Can someone please confirm? I'm running version 3.00 of the firmware.

Have fun!

ColinPitrat commented 5 years ago

Hi,

interesting. The time is computed from the session time by adding the delta at each point:

This assumes that the time the watch provides for the session is the start time. Your report suggest this assumption is wrong and this is actually the end time.

If you're a bit familiar with C/C++, you can try modifying the code to modify the time used as the startTime with something like (the lines starting with + are the ones to add):

 time.tm_isdst = -1;
+auto timestamp = mktime(&time);
+timestamp -= duration;
+localtime_r(&timestamp, &time);
 session->setTime(time);

I don't have an OnMove200 and never had one to test the software. I'm not sure how many people actually used it so it's possible that it's not right and nobody ever noticed ...

fpb commented 5 years ago

Hi!

What people care is exercise data and it doens't matter that much the absolute time. For geotagging it does.

So, I will make some experiments. Are you sure that no other time is recorded on the original OHM/OHD files? I will make some additional tests to check which exact time it is storing there but I suspect it is the UTC time when you ask to save the session.

I am familiar with C++ so I will be able to tweak it to my purpose :)

I will let you know how it went.

All the best! Fernando Birra

ColinPitrat commented 5 years ago

I searched in my archives and the support was implemented in #56 There's an integrated test case here: https://github.com/ColinPitrat/kalenji-gps-watch-reader/tree/master/test/integrated/case12

It's using the files coming from the watch as input. Comparing the output to the one provided in the issue and coming from the official application, the timings are matching. The official application may have a bug of course ...

Is the time on your watch right? Did you try the official application?

fpb commented 5 years ago

Ok, after some additional tests. Clock was 4 minutes ahead of time and it was set to local time (UTC+1).

When I started to log the watch time was 16h40 (near 16h36 localtime). I let it record around 8 minutes, paused it, waited 2 more minutes, stopped it and waited 4 more minutes until I answered that I wanted to record it. It was then 16h54 (watch time) and 16h50 localtime.

The GPX header has 2019-05-17T15:54:00Z (seems to always be rounded to a full minute) The log starts at 2019-05-17T15:54:05.000Z and goes all the way to 2019-05-17T16:02:10.000Z

So, in conclusion, the base time is the HH:MM (as measured by the watch clock) in UTC at the time I hit the save button.

So, either I stop and save the activity quickly so that I can go back all the length of the recorded track or I simply remember the exact start time and adjust all the GPX times later...

Seems a pretty dumb error in firmware. Quality Control... bah!

fpb commented 5 years ago

I searched in my archives and the support was implemented in #56 There's an integrated test case here: https://github.com/ColinPitrat/kalenji-gps-watch-reader/tree/master/test/integrated/case12

It's using the files coming from the watch as input. Comparing the output to the one provided in the issue and coming from the official application, the timings are matching. The official application may have a bug of course ...

Is the time on your watch right? Did you try the official application?

Yes, I tried the official app. It does not show you the time of the GPS samples but it uploads the data to the decathlon coach cloud and from there you can export a GPX that matches the output of your utility 100%.

That's why I am assuming it is a firmware bug. Unless there is some other time recorded somewhere and it is just a matter of start using that instead of the end time.

And the fact that it is not using GPS time at all but clock time adjusted to UTC (Don't know how they even know in which timezone I am)... WTF?

ColinPitrat commented 5 years ago

The fact that it's UTC comes from the date format: https://en.wikipedia.org/wiki/ISO_8601 The Z in YYYY-MM-DDTHH:MM:SSZ means UTC (the alternative being to provide the timezone with ±hh:mm).

I suppose that the conversion is done, as for kalenji_reader, assuming the timezone is the same as the one on the computer doing the import. This sucks a bit because you may have a wrong timezone on your computer, it messes up if you travel and set your watch to the local time etc ...

I do hate watches that do like that, they gave me a pretty hard time getting things right in the code, with time conversion in all places.

It's indeed very stupid because GPS provides the correct time in UTC. Not using it to sync the watch (and using a timezone offset to display the local time) or changing what is stored to be in local time is clearly a bad design.

I really hate that none of those watches firmware is open source, because there are so many stupid details or bugs that would deserve to be solved but cannot easily be.

Anyway, I welcome a PR to fix this if you manage to do it.

fpb commented 5 years ago

On 17 May 2019, 17:57 +0100, Colin Pitrat notifications@github.com, wrote:

The fact that it's UTC comes from the date format: https://en.wikipedia.org/wiki/ISO_8601 The Z in YYYY-MM-DDTHH:MM:SSZ means UTC (the alternative being to provide the timezone with ±hh:mm). I suppose that the conversion is done, as for kalenji_reader, assuming the timezone is the same as the one on the computer doing the import. This sucks a bit because you may have a wrong timezone on your computer, it messes up if you travel and set your watch to the local time etc … I suspected kalenji_reader was doing it this way. I do hate watches that do like that, they gave me a pretty hard time getting things right in the code, with time conversion in all places. It's indeed very stupid because GPS provides the correct time in UTC. Not using it to sync the watch (and using a timezone offset to display the local time) or changing what is stored to be in local time is clearly a bad design. Totally agree. I really hate that none of those watches firmware is open source, because there are so many stupid details or bugs that would deserve to be solved but cannot easily be. The same applies to almost all gadgets. The amount of bugs that could be solved if they were more open to the community... Anyway, I welcome a PR to fix this if you manage to do it.

Cheers.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

ColinPitrat commented 4 years ago

Closing this issue as it's really an issue on the firmware side. The only thing I can think of that may help is to provide an option to offset the time. Feel free to contribute it or to reopen if you think it's useful.