Сhange dataLabel for fit fields?

Yeah, to be clear createField() crashes with an uncatchable System Error when you go over the per-activity developer field limit, unfortunately. If there are multiple CIQ fields in an activity which call createField(), the order of execution is indeterminate, so either one of the fields could crash if they collectively go over the limit.

This is why:

- some devs allow you to disable FIT recording in their CIQ data field

- other devs (like Stryd) just tell the end user to uninstall all other CIQ data fields :/ (FIT recording is a crucial part of their data field)

flocsy released a CIQ data field which helps test the developer field limits (e.g. by changing the number of dev FIT fields via a setting): Fit Field Waster DF

3 thoughts:

you could have a setting for the amount of data / size of the table to accommodate other datafields who also record data.

I'm not sure I understand the use case. Can you give us an example of the data that you would record?

To me it sounds that maybe instead of reinventing the wheel and creating some table-like output in the session, maybe you should consider somehow recording the data as lap fields.

The problem is that the data set is huge. We are talking about shifting gears on a bicycle. There can be between 11 and 13 gears, and with a front derailleur, this is multiplied by 2. For each gear, I know the number of shifts, the duration of the shifts. To this I can add cadence, power, gear ratio, number of sprocket teeth and I get a huge amount of data :). All this can be seen in the moment on graphs, but it is difficult to do any statistical analysis. There is a site di2stat, which allows to make some analyses on fit files, but firstly it is not supported for many years, secondly it is not very convenient to upload each separate file.
In the end what I can do is to deduce some of the most important but simply indicators, although importance is a subjective, which can reveal some statistical anomaly, for example some sprocket is used much more often than others or vice versa

???????

What does it matter how many gears you have? All that should go to a 8 bit unsigned integer field.

I don't see what's the value of having the number of times you shifted into gear X during a ride. If this is really that important, then maybe you indeed should add a new lap every time you shift, and then you'll have enough space for data to indicate the gear you've been at and you'll also be able to see where have you been, what was the grade, speed, cadence at the same time.

I also don't understand why do you need all the other data (that are computed) in the fit file?

If you need to save a huge amount of a data (more than can be saved in FIT developer fields), another option could be to persist the data using Storage (include the start time of the activity so it can be correlated to the activity in Connect) and set up your own server to receive the data.

The next time your data field is running and there’s an active network connection, the data field should save any unsynced persisted data to your server. This can happen either in the background (for devices with CIQ < 5) or in the foreground (for devices with CIQ >= 5, which is the majority of devices which are currently supported with major firmware updates.)

Obviously this wouldn’t be the most simple or convenient solution for you, and you could run the risk of running out of Storage space if your field goes too long without connecting to your server [*}.

But if you take your phone with you when you ride, you should hopefully be able to sync your data after every ride, unless you go off the grid.

You could also implement an “on-device settings” view that would allow you to browse the persisted data on the watch. (The settings view can be used for things other than settings, although its utility as a general-purpose view is limited, as last time I checked, the view won’t update based on a timer, only due to user input, so you can’t implement any kind of “live“ UI this way, such as a UI to look at live stats/data.)

[*] According to the docs:

https://developer.garmin.com/connect-iq/core-topics/persisting-data/

> Keys and values are limited to 8 KB each, and a total of 128 KB of storage is available.

I think this might be out of date, since it’s possible to persist a bitmap image downloaded from the internet in Storage, and I’m pretty sure I’ve successfully persisted an image that’s bigger than 8 KB / 128 KB.

We seem to have strayed very far from the original problem, I guess I wasn't expressing myself clearly. All data is already being written to the garmin fit file without my intervention. The problem is that this data is not analysed or displayed in garmin connect (or strava), it is hidden from the end user. Now analysing this data is available in third party apps or sites such as di2stat. You can go to di2stat site and see what it is all about, example report - graphs and tables are available without registration. I don't aim to create a separate site or app from garmin connect, but only to optimally utilise the resources that are provided for the data field to focus only on the main indicators.