Matrix of what SPORT_xx, SUB_SPORT_yy supprted on device FW?

All the devices should support all the sports available in the SDK. These are literally just an enumeration defined in the fit protocol that gets written into the header of the FIT file. The sports types don't do anything other than categorize the activity.

If you are seeing an issue with using a sport type on a device, it is probably something we need to fix. There was a SDK bug in the initial releases that prevented using sub sports above SUB_SPORT_FLEXIBILITY_TRAINING, but that issue should be fixed in all the latest releases.

im still trying to determine how to use sports-multisports. What's the relevant sub sports to be used for running and cycling or swimming to get a MULTISPORT session?

ConnectIQ does not currently support Mulitsport FIT recordings.

ConnectIQ does not currently support Mulitsport FIT recordings.

So, SPORT_MULTISPORT is one of the activities that wouldn't have any checks in the matrix I suggested, correct? :)

So, SPORT_MULTISPORT is one of the activities that wouldn't have any checks in the matrix I suggested, correct? :)

I'm not actually sure what you are saying here, but you can create a session with the sport type of SPORT_MULTISPORT if you want.

What you cannot do is create a multisport recording. Multisport recordings are FIT sessions that have multiple segments with different sport types. ConnectIQ can only create sessions that have a single sport/subsport type for the entire duration of the recording.

Brian, I think we are talking different things. Yes, I understand you can use any of the standard types to label (set the activity type/subtype) an activity on any device.

What I'm talking about is the .fit recording itself. With Multisport, yes, you can label an activity for that, but you can't get the fit file to contain things like switching sports, so why would you use it? The .fit file wouldn't have the info it needs (today at least).

In the case of the va and open water swim, yes, you can label an activity for that, but it seems the FW doesn't handle the specifics of that sub sport correctly, based on many posts I've read. If it did handle it, it would probably just be part of the standard swimming app.

Hi Brian,

I think this is along the same lines as the documentation that I requested here.

https://forums.garmin.com/showthread.php?317111-Documentation-Request

We're left guessing as to what's going to happen when we use different sport types. If I enable a bike cadence sensor, but have a multi-sport activity type what data would .currentCadence return on a VivoActive? What data (if any) would get saved in the FIT file on a 920XT? I don't know how to find this out without testing it on the actual hardware. And when I get the results of the test, I don't know what's intended functionality vs a bug.

I've found with speed, different sport types give different results and the results are different on different watches.

Thanks for the consideration!

Roger

Well...... That Kinda sucks. Been trying to figure out (head banging wall type) how to create a multi sport activity thinking that using sports_multisport is the way to go.

I second moxyRoger request then. There are quite a few clarification items in the doc then.
Although it is appreciated the forum exists and you guys are super helpful - I'm fairly sure that better doc = lesser questions and lesser headache for u guys. (Win win!!)

Jim,

ConnectIQ does not have any control over how files are recorded in FIT on any of the products. Selecting the sport for a session does nothing other than label it as that sport for all sports on all products.

You are correct that the VivoActive does not support open water swimming. From ConnectIQ, none of the other products do either. If we add support to enable things like open water or pool swimming modes in ConnectIQ, it will not be associated with the sport mode for the session. These types of features will require a new API.

Roger,

There are some things that are a bit messy in our internal APIs. You found one of them with the pace filter that is applied to speed in running modes. The speed is behaves in this way because our internal API does some odd things. Cadence is also messy because the same metric is used for two very different things.

We want to know about these things that behave strangely because unfortunately a lot of our internal APIs were not designed with ConenctIQ in mind. We do not however, want to know about them so we can document them; we want to know about them so we can fix them. Explaining how a busted API is behaving doesn't make it less busted.