I am now stuck at home as many of us. Weather out is beautiful. So I’ll take the opportunity of the extra time to try to write more about the app development. One source of inspiration that never seem to end is chasing bugs in the app! So while I have the time at home, I’ll try to detail them as I chase them! Starting with some database woes…Continue reading
ConnectStats has been around for a while now. It started in 2011, while the Garmin API was in a very different place as today. I have maintained it over the years, but there is still quite a bit of complexity in the code due to the history of the API evolution.
I am pushing a new version that simplifies some of the legacy internals of the code.
As any internal upgrade, it will help in the future and fixes some side effect or bugs coming from the legacy complexity. But it also comes with high risk as it is hard to test all the side effect. I’ll try to fix what comes out.Continue reading
I have a few upgrades of the app about to be released (pending Apple approval). I have pushed minor updates of ConnectStats, a new version of FitFileExplorer
Few bugs out of the way
The version 5.2.2 will contain a few bugs fixes that people have been reported recently.
First it should synchronise better the changes that occurs on the Garmin Connect Website, specifically the names of the activities.Continue reading
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?
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.
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 use 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:00
While the graph is clearly more than 10:00
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
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:
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
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
And the same activity without smoothing, with a much noisier gradient
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.
[UPDATE] This is now fixed with version 3.0.2
Since Yesterday a change in the Garmin API resulted in ConnectStats reporting some activities were deleted from Garmin Connect when trying to download the details.
This happens because the part of the API that ConnectStats use to get the weather is now reporting the same error as when an activity is deleted and that confuses ConnectStats.
I will push a bug fix to the store that will stop downloading the weather for now until I can figure a new API to retrieve it.
Version 3.0.2 was pushed to Apple for approval today, unfortunately pushing a bug fix requires a few days, sometimes up to a week for Apple to approve it. Sorry for the inconvenience caused and thanks for your patience