Statistics on a selection of activities

One feature people repeatedly ask about is the ability to see statistics for a selection of Garmin Activities. It is actually possible by using the search feature.

Let’s say for example I want to see the statistics of all the running activities in july 2015. I first enter that as a search

Simulator Screen Shot 20 Jan 2016, 21.53.35

Then in the statistics page, hit the type button until the term Search appears. It will remind you what the search term was, and then the statistics you see are only using the currently selected list:


This will be the case for the other stats page as well, here for example I show a scatter plot of Pace versus HR for the running activities of July 2015

Simulator Screen Shot 20 Jan 2016, 21.53.54

Another useful application is to run statistics on a specific activity type, for example all the skiing activities as here, I show how much elevation gain I achieved each month in backcountry skiing. You can see more about skiing here

Simulator Screen Shot 20 Jan 2016, 22.01.22

It is limited though by the current search syntax of ConnectStats, which if there is significant demand, I may extend. Just let me know.


Fenix 3: Inconsistent Laps and speed graphs?

Update I added a new option to ConnectStats to mitigate the issue

I started noticing something quite weird with the activities recorded on the Fenix 3 since I updated to firmware 6.5 for my running activities. The pace reported on garmin connect is quite off, while the pace of the splits seems correct. At the very least the two are very inconsistent, the pace on the pace graph is typically quite slower than the correct pace. You can see an example activity here, all the lap pace overlay are clearly toward the minimum of the lap pace, which is not possible.

Screen Shot 2016-01-18 at 21.24.55Screen Shot 2016-01-18 at 21.25.09

While if I look at a similar run but in december (pre 6.5) it’s much better

Screen Shot 2016-01-19 at 22.15.39

Looking at the activity on garmin connect, shows the same issue, so I don’t think it’s a bug in Connectstats (my initial thought). Old activities (pre 6.5) do not show the issue. On Garmin website, while it’s harder to see, if you move around the pace, you can see most values are quite slower than the average pace for the activity.


Screen Shot 2016-01-18 at 21.23.49

If I looked at the same activities on Activity on Strava,  the graph is consistent with the splits. Strava seem to recreate the pace from the GPS points (my guess).

Screen Shot 2016-01-18 at 21.24.20Screen Shot 2016-01-18 at 21.24.10

I then looked at the details in excel, here too, it’s quite clear that the speed recorded for each point is quite slower, while the speed of the split is correct. For example for the first split, I looked for the 1000m point, computed the time to start 308 seconds, which gives 3.24 meter/seconds or 5:08min/km. While a simple average of the speed recorded for each point gives 2.72mps or 6:07min/km. The simple average is inaccurate, it should be weighted by the time between points, but this is way off.



Garmin automatic synchronisation to Strava and implication for ConnectStats

Strava now automatically synchronises with Garmin

Garmin provide now automatic synchronisation with different services, most notably Strava. You can read about it from this post from @dcrainmakerblog.

I find it very useful. I personally use Strava as well, I like their segment functionality and the social aspect of followers.

This is a continuation of the new policy change of Garmin to not support 3rd party app that access the data from garmin directly. You can also read about it here from @dcrainmakerblog

What’s next for ConnectStats

For ConnectStats, this new approach of auto sync just does not work. I do not have the ability, the means nor the time to build my own service to save users data on a web server and use that from ConnectStats.

Garmin announced that they would stop supporting the API ConnectStats uses, but as of beginning of August and the time of writing this, it still continues to work. We just don’t know for how much longer.

To address the potential shutdown, ConnectStats can use Strava as data source instead of Garmin Connect.

I still believe that ConnectStats can be quite useful to many users with extra plots, reports and views it provide currently not available directly from other services on an iOS device. So I will try to continue maintaining ConnectStats even if Garmin shuts down the API access. For that purpose the auto sync to strava is very useful, because it lets ConnectStats use Strava as a service provider to replace Garmin Connect.

What ConnectStats users will loose

It’s not all perfect though, here are some of what will be lost when Garmin Connect shuts down its service and ConnectStats user have to switch fully to Strava:

  • The auto sync service only seems to upload recent activities, long history of data will no longer be available to users.
  • Strava API itself only lets you download the two most recent months of activity via their API. This is quite an issue because a large part of the attraction of ConnectStats is to do comparison and plots that go back in time. My favourite features are to compare my fitness evolution over long period of time
  • Strava API currently will not provide access to all the different fields provided by garmin devices. Training Effects, Normalized Power, Vertical Oscillation, and many other data will no longer be available access to the garmin service stops and ConnectStats user switch to Strava.

Note that to mitigate the issue with only accessing recent history from Strava, I plan to add a merge feature to ConnectStats multiple service support, so at the time Garmin Connect API shuts down for those lucky user that already have their history saved on their device they can continue and use strava only for new activities.

Recent Silence

I have been recently a bit quiet. I admit the idea of potentially not being able to download data from Garmin and the implication of an end of ConnectStats wasn’t a great motivation to build new features.

Recently though I had a couple of ideas that excited me. I am still working on ability to keep track of time in zone, best rolling plots, Critical power plots etc over time. I would love to be able to compare my best rolling plot of current month versus last, or versus a given year, etc.

The other feature I am working on is ability to compare your recent performance (current training) versus your long term built fitness. Somewhat inspired by training peaks’ performance chart, and leveraging ideas from the following articles about how to measure impact of exercise.

Another subtle change in the Garmin API

UPDATE: thanks to a tip from @GViewerPro I have now a fix which will be a next release. Thanks a lot.

Since the login change, another less obvious change to the data service of garmin has resulted in a few issues with ConnectStats.

The track data contains now significantly less points. It used to provide points as often as recorded, but now the track data service returns a lot less points.

Here is an example of an activity downloaded before and after the service change. Notice the scatter point contains a lot less points.



This has a few consequences in the app:


The app smoothing logic is not working as well anymore. We now have a point every 10 to 20 seconds, so it’s harder to figure out how to smooth. Intervals for example may not be plotted properly if they are less than a minute. If that happens turn off the smoothing, by selecting the graph full screen and pressing the Slider Icon to show the smoothing options.


Auto Lap

The logic in auto lap was trying to account for times where the device was on pause. This logic gets mixed up with the new sparse points. A fix and a better logic is on the way for next update.

What I will do about it

I have somewhat tweaked the logic in the smoothing and auto lap feature and this will be incorporated in the new release 1.18. I am also investigating to use the tcx file available. This file seems to still contains all the data point. ConnectStats used to get its data from that file, but it was changed to a different api that contains more information, like the running dynamics of the new ForeRunner 620. I will probably see if I can do a merge of the files, use the tcx file for main data and the sparse data for running dynamics and other fields.

Garmin Connect New Policy Impact on ConnectStats and 3rd party apps

First I want to be clear that I have been a huge fan of Garmin’s for years. I own 6 devices and think they are extremely well done. I have also encouraged a lot of friends, colleagues and family to purchase Garmin devices over the years.

Monday March 2nd, Garmin announced they would stop making their API freely accessible and that 3rd party would have to pay $5,000 to access the data in Garmin connect.

I understand their infrastructure is costly to maintain but I feel such a steep fee risk killing the independent 3rd party applications which I believe adds value to Garmin customers and therefore Garmin as well.

I would propose a multi-tier system where 3rd party apps register and get a first limit of daily access for free, say 50,000 access per day. Heavy user breaching this limit would have to pay the 5,000$ fee.

I believe this system would be to both Garmin’s and its users benefit.

The Policy Change

On wednesday February 19th, Garmin updated its website which resulted in the approach used by most apps and website to access garmin connect data via an API to fail. The api used to have a license saying the following

This is the license file for You are free
to access our API as long as you agree to create great things.

The link to that license has now been disabled

On monday March 2nd, Garmin has notified developers that they are changing their policy and will charge $5,000 dollar fee for access to the API. Here is an extract of the message about the new policy.

Garmin has instituted a new policy regarding the accessibility of our developer programs. The previous strategy of freely available APIs quickly became unsustainable due to increasingly high demand. In response, we have established a new pathway for our Connect API. Firstly, there is a vetting process. We are strategically limiting the scope of this program to specific developers that will enhance the user experience. Secondly, those who are approved for inclusion will be charged one-time $5,000 administrative fee to cover the extensive engineering and server support required for the Connect program.

Consequence of the decision

This decision will likely force the eco system of independently developed 3rd party app to partially or completely disappear. This is a consequence which will affect customers. A lot of innovation can come from independent developers. Niche functionality can make its way to customers. It is likely not worth Garmin’s engineers’ time to cater to all customers software needs or custom data analysis needs. Enabling third party to provide for them helps make the Garmin devices more attractive. The size of the fee will dissuade a lot of experimentation for small players. The cost of entry is too high.

Most disturbingly it means it prevents people to use their own data in more creative ways than just using the data from the website. ConnectStats started as purely a tool for myself to look and slice my own data. I decided to share it as it could be useful to others, but right now it means I would not be able to use my own data in my code without paying $5,000, even if I pull the app from the store. This sounds wrong to me. Savvy users wanting to use a script to import their data efficiently for processing won’t be able to do that either.

In a world where the fitness market is exploding, I feel it would be to Garmin’s and its customers’ interest not to exclude this source of innovation for functionality.

My choices

I have the following choices for ConnectStats:

  1. kill the app. It would really pain me as part of the initial motivation was to provide a service for myself I couldn’t otherwise get: a more advanced viewer for my data on iPhone and iPad that what Garmin offers.
  2. swallow the cost. It’s a lot of money. I intentionally kept the purchase price at the minimum as to cover development cost and devices (money going back to Garmin by the way…) but my key motivation beyond my own use was sharing the app and not really generating large profits.
  3. increase the sell price of the app and hope people will continue to buy it. It somehow feels wrong to charge the users more just for the sake of them accessing the data they should own already. Right now if I increase the price from $.99 to $2.99 for ConnectStats, I am hoping to recover the Garmin fee over time. People pay several hundred dollars for their device. I hope they will accept the few extra dollars to pay Garmin for the right to access their data.
  4. switch ConnectStats to rely on another service. I am already working on that to use strava as primary download service and hope strava will pay the fee to get the data from garmin. This has some downside as some data won’t be available and Strava does not support swimming and skiing which I personally rely on.

Comparison to others services

I also wanted to comment on the fee structure proposed. A fee of $5000 is a lot of money by any standard. Niche independent Apps do not generate much revenue, mostly cover the costs. Here are some other services I use as comparison.

  • Apple charges $99 a year plus 30% of every sale to access their development tools and app distribution infrastructure. And this infrastructure and marketing power is of extremely high quality and adds a lot of value to independent developers like myself and to its customer. It wouldn’t occur to me to complain about this cost.
  • Strava provide an access to its data for free up to a certain rate limit once you are registered. Their API is extremely well documented, modern and their support and help to my questions have been great. I applaud Strava would provide a sophisticated website and API for free when their business model does not include revenue from any hardware.
  • Garmin support and documentation was so far inexistent. There are no or little documentation. I have never received an answer to any of my inquiries. Everything had to be reverse engineered. It doesn’t bother me at all given it was free but for $5,000 it’s a different issue.

I have been inquiring with Garmin about what exactly is provided when I pay the fee. What exactly do I get for that money: same API? Do I need to adapt my code to a new API? Do I get more documentation? Better support? Some marketing/promotion of the app as Apple provides?


I believe the independent and small 3rd party partners add a lot of value to Garmin and the ability for users to access freely their own data is important. I understand the potential infrastructure cost and need to control usage for Garmin.

I suggest they offer a tiered system. Any user of the API would have to register and get some basic number of API access per day, say 50,000. Users above that limit would be required to pay the $5,000 fee to use the service. This would allow them to recoup some infrastructure cost from heavy user but still allow their customers to benefit from 3rd party functionality and access to their data.

What I plan to do for ConnectStats

I am doing 2 things:

  1. I have written to Garmin to explain why I feel a tier system would be better for all parties involved. I hope they will agree.
  2. ConnectStats is somewhat successful, receives good reviews and regular download. I hope by raising the price by an additional $2 this should help sponsor and recover the fee from Garmin. I have applied to be part of the program. Assuming Garmin approves my application, I plan to pay the fee myself and hope people will continue buying the app at the higher price to recover the money over time

Thanks for reading.