DataField to Application: Connect IQ state

Former Member over 7 years ago

I am a developer by trade and have been swimming all my life. I have owned several Garmin watches, from the Garmin Swim to the latest Forerunner 935.

Rightly or not, due to the lack of new features in the last few years, I consider Garmin treats pool swimmers as second class citizens. So I decided to write my own solution to support my hobby.

I missed several things in the pool swim activity; the number of fields per screen was a bit low, and I also required data that I would need to calculate myself. So I decided to write a DataField.

When developing my DataField I found several limitations:

1. Apps for personal use are limited in usefulness: Their FIT field data is not shown in Garmin Connect. I understand the app distribution process uploads the fit contributor json file for GC to know what fields are needed. So no distribution equals capped functionality.

2. No FitContributor override of native fields: Even when using :nativeNum, GC ignores the overrides. I thought :nativeNum would be a solution to my first point (personal use without distribution), but overriding is forbidden. Why implementing :nativeNum then?

3. No MESG_TYPE_LENGTH in FitContributor: Information per length is not allowed. For a pool swimming data field, it is quite important to be able to update computations per length.

4. The native pool swimming activity ignores FitContributor MESG_TYPE_RECORD events: We don't get MESG_TYPE_LENGTH events and cannot set RECORD events, resulting in a very limited landscape of LAP and SESSION messages.

5. FitContributor MESG_TYPE_SESSION doesn't work on some new devices (Fenix 5 series and 935 that I know of).

6. Activity.Info doesn't expose many fields for specific activities: This makes creating really useful data fields very complicated. For example SPL (strokes per length) is not exposed for pool swimming activities. This means you cannot create a complex pool swimming data field with lots of data (and including SPL). I believe the structure should be subclassed per activity type (swimming, running or cycling having different members). In the end what you get now is a big structure where some things work and others don't depending on the type of activity, and it doesn't contain all the data it easily could.

7. No timers on DataField: This could be understandable, as well as not supporting menus.

For all these reasons, after developing my data field, I decided it wasn't enough, so I decided to implement an Application. And again I ran into severe limitations.

You cannot control the Fit stream: A Fit contributor doesn't allow to store messages other than SESSION, LAP or RECORD, and some of them don't work in certain cases (like pool swimming, above). This makes applications that need to write FIT files very limited.

There is no other output type possible from a Connect IQ application. Because of the problems with FIT, I thought maybe I could write my own binary or text files, but Connect IQ limits you to FIT files you cannot fully control.

There is no native development possibility: With all those limitations in the Connect IQ API, I find it very hard to write a pool swimming activity that improves on what the watch already offers and hasn't evolved since the Garmin Swim. I have the experience of working with accelerometers and processing their output, I can compute all the data needed for SPL, distance and more, but I cannot output it in any useful way.

Currently I am a bit disappointed with Connect IQ and my latest purchase (Forerunner 935) from a developer perspective. The watch hardware is amazing: long battery life, waterproof, all the sensors I need. But developing anything really complex for it is severely limited by the Connect IQ API. If Garmin wanted to open the platform for real development they should really open it through a powerful API that really works, or not open it at all.

danielp27 over 7 years ago

I am the developer of a pool swim app for the fr230.
You have perfectly summarized all of the limitations. :)

Still, even if you cannot send length messages, you can send most of the information within record and lap messages. And because third party sites such as www.sporttracks.mobi support connectIQ and override native fields, the result on those sites is quite OK.

Gamin connect sucks, but connectiq is quite powerful given it has been around for not so long. You just have to look for a better place to show your data.

Brandon.ConnectIQ over 7 years ago

I acknowledge many of these shortcomings, particularly the ones you've listed for FIT contributions. We plan to focus on a lot of these issues throughout this year and get them working. I can't promise perfect solutions for everything (for example, I don't expect the behavior of native field mappings will change on Garmin Connect--although, other services can use the native field mappings to override native data if they choose), but we can at least get custom FIT data to show correctly in GC, etc. I'll file tickets for some of the swim-specific issues you've mentioned, because it's worth looking at those a little more closely too.

Former Member over 7 years ago

Still, even if you cannot send length messages, you can send most of the information within record and lap messages. And because third party sites such as www.sporttracks.mobi support connectIQ and override native fields, the result on those sites is quite OK.

Hi Dani, I think you have done a great job with your app considering the limitations of the API.

There are a couple of things I believe you had to do which I would like to avoid. The first one is you need to use a GENERIC SUB_SPORT type if you want to get RECORD messages. By doing this, even if Garmin fixes the LENGTH messages, you will not get them, as they are only for SUB_SPORT_LAP_SWIMMING. On the other hand, if they add LENGTH messages, you will not get RECORD messages because of the way their native lap swimming application works (buffers length data, and outputs it, even heart rate is added at the end, after the SESSION and ACTIVITY messages). I also need LENGTH messages because one of the features I want to implement needs more precision than what you get with a one second period callback. In reality I would like to be able to send the messages myself to the FIT file when I decide to, basically being able to implement an Activity object. But that is not exposed in the API also because FIT output is very limited.

I also don't really want to have to move to another data storage platform just to see my data. I have several years of pool swimming activity on GC, and despite its shortcomings, it is more than enough for what I need. I could also implement my own data storage offline, but Connect IQ doesn't support any file writing other than .FIT files, and having to parse them for the simple swimming data I need (like when you output accelerometer data) is overkill.

Another unrelated thing I found limiting is some of the watches have WiFi, but the Communications module always expects you to connect to the outside world through a phone using BLE. There are very interesting use cases for a short WiFi connection from the watch, even Garmin acknowledges this by having workout auto-upload on these watches. In many cases you don't want to carry your phone around while working out but you may want to write remote control apps using WiFi, etc. I think it would be very useful to expose WiFi connections in the Communications module.

Thank you Brandon for your help.

Willba4 over 2 years ago

4. The native pool swimming activity ignores FitContributor MESG_TYPE_RECORD events: We don't get MESG_TYPE_LENGTH events and cannot set RECORD events, resulting in a very limited landscape of LAP and SESSION messages.

i've been just going through exactly this for pool swimming.

i looked on the connectIQ store for an app that would break down my "laps" into length times. so i'd know if i was maintaining times, or had a slow lap etc.
I saw that no one had done it, so i went to write my own. all the data is right there in the fit file, and times per length were contained in the MESG_TYPE_LENGTH messages, so how hard could it be??

turns out this is STILL IMPOSSIBLE. Garmin have not exposed this message type to the connectIQ API.

i'm wanting to try and get access to their other API's (Elec Engineer) but it looks like they all require you to be a large buisness, who is going to make a professional tool to be used on the garmin, not just some guy who wants to make a data field that doesnt exist, and cant be done with connectIQ