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.