Trying to understand what was wrong in my Best Rolling Curve Calculation pushed my ability to use Xcode debugger to its limit. The quirks I was trying to understand were happening on large time series after multiple level of sampling, rolling averages, etc on noisy data.
I ended up in a mixed environment so I could easily exchange time series data between Xcode and pandas in a Jupyter notebook, which enabled me to explore and get to the bottom it!
The harder category of bugs are when it is related to bad numbers generated from the more complex algorithms in ConnectStats. This is what is now happening with the best rolling plots.
The rolling best curve are one of my favorite feature in ConnectStats, they provide insight I don’t see in many other services. It’s quite common to see a power curve, but I feel the concept extended to heart rate or speed help give people a good sense of the characteristic of a workout. While the concept is simple, it actually can be a bit tricky to implement (at least for me it was). The current version of the app shows quite a few quirks that are obviously wrong, like the below.
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…
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.
While I am still preparing a new release of ConnectStats fixing a few issues, right now, the corona virus is a major distraction for most of us. While the virus spreads there is a lot of information floating around and it can be sometimes be a bit confusing. So I decided to see what could I verify on my own at home with basics analysis and tools. I’ll be using python/jupyter/pandas, which is very standard and easy to install or can be run directly on google collab
This may become a bit technical for some, but hopefully will be interesting and may help some people learn more about python and pandas as more of us have to stay home…
Time flies. It has been close to one year since Garmin opened its new API to third party developers and that I embarked on migrating ConnectStats to using it. I had anticipated it would be fairly straight forward, but, boy, it has been quite a ride, and the last few weeks continued to provide a lot of “excitement”. Let me share some of that story…
Quick recap of the service
In the past ConnectStats was connecting to the Garmin Connect website to extract the data for the user activities. While this was the way ConnectStats worked from the beginning (2011!!!), it was simple as I didn’t have to maintain any online servers, but it was not very robust and repeatedly created serious outage as the Garmin Connect website would change its way of getting data without any type of support or documentation. I would typically have to find out via a multitude of bug report and try to reverse engineer what had changed on the web site.
The new service is fully documented and supported, but the flip side is that it works by pushing the fit files of a user to the application web server in the cloud. Which means you need to have a web server in the cloud, which I didn’t…
I recently saw a negative review on the App Store for ConnectStats warning users that ConnectStats is not a Garmin app and therefore people should avoid giving away login information in the app as the data may get stolen.
Keeping data secure both on your phone or online has been a key guiding principle in how I tried to implement the app. So while I understand the concern, I felt it was a bit unfair.
I have been careful to make sure the data isn’t shared and the passwords are never sent to me. I also made the app open source so that people can check for themselves what it is doing.
I felt it may be worth to write a bit of details on what is ConnectStats doing with your data and password, with link to the code. So people can either let me know if I miss something or feel better about using the app.
I spent over a week in the Swiss alps, so it was clearly the time to update ConnectStats with better support for winter sports…
Garmin had made some changes to their API for winter sports, and reorganised a bit the types of activities available. I have a Fenix 6 and it has a nice new activity for backcountry skiing with climbing mode (at least I wasn’t aware before). So I updated ConnectStats to properly recognise it and added a new icon for it. I also made sure it display the elevation gain in the summary as this is more relevant for these type of activities.
So in the last few weeks, ConnectStats had a lot of issues related to online services. That was quite a learning experience. I hope most of it is behind, but could be a few left overs.
Strava made a change in its API related to how it authenticate users for access. This was a documented and announced changed, unlike a lot of the Garmin API changes in the past,. The issue is mostly that I hadn’t understood the change, so I didn’t get the right fix out in time. So I have only myself to blame…