2016 year review and double counted activities

It’s time again to look at the past year summary. How did I do?

2016 was a fine year, I ran 1387 km, it is 100km behind 2015. But one aspect bothered me, looking at the distance, there is a clear increase on the graph in December 2015, which put me behind in 2016. It worried me a bit. I couldn’t remember an especially good December last year. Did I have another bug in ConnectStats?

I went to check on Garmin connect and it reported the same distance as connectstats: 1478km for 2015…

Hum. Next step was to go and look at the activities in December last year. The search feature in ConnectStats made it easy, just enter december 2015  in the search box of the activity list. Sure enough, I found some duplicate activities. This started to be very worrying. ConnectStats imported the same activity twice? New bug? After some more investigation, it turned out the problem was in Garmin itself… Quite a few activities in 2015 appear twice on the website as well…

They have a different activity identification number, but they are clearly the same activity except for the altitude gain as you can see on the snapshot above.

Next steps was to add a new feature to ConnectStats to double check for such duplicate activities and ignore them… Well, my stats are now lower only 1310km but correct. And 2016 is ahead of 2015 by 50km! Yeah!

I finally decided to check what Strava reported. My account is linked to import activities automatically. I was curious: would strava have the total including the duplicate as well? It actually didn’t… The total is 5km off from my new corrected total, but I suspect it is simply due to the slightly different way Strava computes the total distance from the gps file.

The fix to search and eliminate duplicate will be included in a new release early next year.

Update on development and new API issues

There is shutterstock_120037903currently quite a few issues with ConnectStats following some changes in the Garmin API. I am working on it but it is quite more involved than I initially thought.

As of last release, the laps are not downloaded anymore, swimming activities do not download properly, nor do the multi sport activities. This is all due to an API access that disappeared from Garmin last week. I released an emergency fix that let people going for the main types of activities (running and biking) but I am aware there are still lot more issues. To fix the rest, I need to upgrade to a newer access point that is significantly different from the old one. I am also trying to future proof the app by removing use of all older API similar to the one that disappeared that ConnectStats is still using. I want in addition to improve the ability to seamlessly switch to Strava should Garmin decide to shut down everything for ConnectStats.

Also because the changes required currently are quite fundamental (completely new APIs), it requires quite a bit of testing and even then the testing is limited by the fact I only have limited set of activities to test (mine plus a few people sent me over the years). So it is possible that after the next release some issues will appear when others try it, but I will do my best to fix as soon as possible.

As I have explained in the past, I work on ConnectStats on the side of a demanding day job and a family, so development can be quite slow, given I can only work on it a few hours a week at best.

I am sorry about this. The most frustrating aspect for me is that I spent the precious few hours I have for development of ConnectStats on pure maintenance and not on new features. It has limited benefit for the users beside keeping the app running…

Currently I estimate it will take another week or two to complete the upgrade.

Yet another change of the API

I guess garmin is making a lot of changes to their API recently. The API I used for the laps is changed. I need to work on a new fix… I have pushed a temporary fix on the store.

While in previous week, some of the changes were subtle modification of the API. Here, ConnectStats is using some older Garmin API to get the laps, which now returns a message saying that this access point is disabled. For now I removed the laps download, because that’s easy and quick, but I need to also work on using a newer API for laps. I am also going to review all the old access point ConnectStats would be using and replace them with a newer one. This will be a subsequent release, and then the laps will come back. I am worried some of these older API point may also get disabled soon.

 

Garmin API changed again

UPDATE: good news, it seems to be an slight API change, but not an attempts to stop 3rd party. So I could get it working again. Will push an update to the store as soon as possible.

It appears Garmin disabled access from ConnectStats again. As before I’ll remove the app from sales and turn off bug reporting until I can figure out the reason. I am sorry but at the moment I have very little time I can put into the app, so it may take a bit of time to get to the bottom of the issue. Also it is quite worrying that Garmin disabled it so soon, while it could be a coincidence and still a side effect of an API change, it’s also possible they just want to stop 3rd party app.

I will update when I can, sorry for the inconvenience.

Fix for Connection Issue (ConnectStats 3.2.1)

So I have a way to get the app to work again. It required a few tweaks, but I can only get it working if I do two login in a row. This is utterly bizarre and sub optimal, but I am giving up at this point trying to do better. I’ll push this version to the store so that people can get a working version as soon as possible. Maybe I’ll figure out a better way later.

I have a lot of other pending fixes and features that I was planning to release along with iOS 10. Because these other changes include iOS 10 specific code, I can’t include them in this release, so this is really a very small patch that only addresses the login issue. I will release the rest shortly after when iOS 10 is available.

Cross finger the API is not going to change again soon…

Garmin API change (again) and Connectstats is not working at the moment

As of tuesday august 30th, Garmin API changed again. ConnectStats fails to connect and download data. I am turning off bug reporting and will remove from sales until I can figure out a solution.

The API returns Access Denied when ConnectStats tries to connect I hope it’s not Garmin deciding they want to shut down ConnectStats. I am unfortunately travelling at the moment and it’s hard to investigate the problem in details. I’ll update as soon as I know more.

Sorry for the problems, but it’s out of my control.

ConnectStats Version 3.2

shutterstock_91834361A new update is available again. It contains quite a few bug fixes and improvements.

First it has better support for large fonts or language with long description. ConnectStats used to try to pack in a cell up to 4 data field, but for some languages or when you used large fonts, it would overlap and be unreadable. It now checks how large the text is and if it does not fit in the cell, will split it into two lines.
I also finally figured out how to fix the login when your username or password has special characters like +, & or =.

This version includes the Improved accuracy of time in zone laps calculations due to the bug reported here.

It includes a fix for a bug that had made the weights graph disappear, for those who had linked their account to withings or health.

I also disabled in this version the import of health workout. They were fairly useless, as they contain little information and were creating duplicate activities for those who had garmin export workouts. If enough people explain to me how they can be useful, I’ll see to add them back.

 

Exciting Bug Reports

You may wonder how bug reports can be exciting. Most of the reports I get are about people having trouble to login or set up the app. Usually either because people Bugsuse the wrong device (vivofit or vivosmart), or have special characters in the password. I actually just fixed the latter, which is great news.

So once in a while I get a bug report from someone that spotted some inconsistency in the stats or numbers reported in the app. This is exciting because it is usually somewhat interesting to track down and also because it helps get the app better and better. It even sometimes happens that people spot inconsistency with other apps or report, and when the other apps was wrong it’s quite satisfying 🙂

Inconsistency between Time in Zone Graphs and Laps

An often overlooked feature of the app is the ability to compute statistics over arbitrary laps. You can of course record laps while you do an activity. But what if later you want to see how you did by kilometres or miles? You may also want to get your stats for all the times you were in a given heart rate zone. Or your half distance split, etc. The app lets you do that, by tapping on the lap header and selecting the type of lap you want.

Someone just noticed that the time in zone was inconsistent between the computed lap and the time in zone graph. As you can see in the graph for instance the 149 to 158 zone is reported with less than 10:00Simulator_Screen_Shot_15_Apr_2016__20_31_00

While the graph is clearly more than 10:00

Simulator_Screen_Shot_15_Apr_2016__20_28_59

Bug feels always silly once you found them. Here I was not accounting properly for each point of the activity where the value changes zone. The laps calculation is somewhat more involved than the time in zone graphs, because it requires keeping track of bunch of stats, like distance, speed or pace, average heart rate, etc. Note that the activity don’t report when the timer was stopped on the watch, so there is also some logic to account for the point where the timer appears to have stopped (long delay between points). It’s not exact and sometimes the logic does not work well.  But here I was just missing one point all together. It’s fixed now for the next version. Here is the correct laps after the fix

Simulator_Screen_Shot_15_Apr_2016__20_29_15

Fast Mile starts in slow section

Sometimes what appears to be a bug, is just a side effect of a feature. One user noticed that sometimes the fastest mile on the map appears to start in a section that is slow (blue). It would appear to not make sense as given the section at the end is faster it should more the fastest mile to be starting on the next point as here:

FastBikeSmoothing

Well, in that case actually the pin is at the exact right location. The blue section is also correct, given how it’s calculated: The gradient color represent the speed modulo some small level of smoothing. Here is the same picture without the smoothing

FastestBikingNoSmoothing

You can see that in that case, the fastest mile start correctly in a red (faster) section. It is hard to decide if this is a bug or a feature. It’s also interesting to see that in the case of a cycling activity (as in the above pictures), the speed is actually quite smooth already, so the smoothing probably not that critical. But in the case of a run, it tends to be much noisier. Given I am first a runner, it was quite obvious to me that without smoothing the gradient was less useful in identifying speed zone.

Here is a running activity with smoothing

SmoothingRun

And the same activity without smoothing, with a much noisier gradient

RunNoSmoothing

ConnectStats does not let you control the smoothing of the gradient on the map. Maybe I’ll add an option for that, or I’ll disable it for biking activities.

 

ConnectStats back online v3.1

ConnectStats just got approved and should show up on the store again. Please update and the issues with downloading activities should be fixed.

I was in the middle of adding new features and bug fixes, so you should also have now a log scale for power curves, which I think work better. I just got my first power meter, so expect a few more improvement on power graphs and data as I play with it 🙂

 

ConnectStats broken after another Garmin API change

This morning, the Garmin API changed again resulting in ConnectStats failing to download activities again. It had happened on a smaller scale a few weeks ago. The issue is the same as before but for different part of the API, so it was quite quick to fix. But as before I need to push that version to apple and wait for them to approve it and release it, which can take up to a week. app review times indicates a 5 days average for release, so we’ll see. As soon as version 3.1 is available, once you update it should work again.

To avoid hate mail and incendiary reviews during the outage I disabled the bug report and removed the app from sale on the store. I made the mistake not to do that last outage… I will re-enable everything as soon as the new version is out.

I do not know if the change means Garmin is trying to play cat and mouse and prevent 3rd party developer to access their API. Their message in the past was a bit unclear. They said they would disabled, but I had registered with them and they could see the activity of ConnectStats, yet didn’t disable it. I hope the current outage is not intentional. We’ll see how the situation evolves. I’ll keep you posted.