Max FIT Fields (Alpha-HRV)

We've run into an issue I don't think we can prevent. Our field creates 4 FIT fields. There must be a limit that isn't published (maybe 32?) and no way to inquire about the global consumption of fields across all the CIQ apps the user is currently running.

We're figured out that the Alpha-HRV field seems to be causing our field to crash with a SYSTEM ERROR at a line where we create a FIT Field. That seems to suggest (we think) this field must create a WHOLE BUNCH of FIT fields. So our users are having to stop using the Alpha-HRV field.

Anyone know what the limit is? If the author of that field is here... how many are you creating? Is there a way to maybe setup a User Setting to disable some of those so a user can use your field and others? If you are creating dozens of fields and maybe not all are needed by all users? I can't think of another reason why your field and our field don't work together.

The API guide doesn't show I can catch exceptions.

I also might add a User Setting to NOT create FIT Fields as an option if they run into a conflict and are seeing SYSTEM ERRORS likely due to this.

Top Replies

All Replies

flocsy🤠 7 months ago

This came up multiple times in the forum. There are both limits of number of fields per type (session/record/lap) and limits of total number of bytes (i.e even 1 field with a long string can eat it up)

I also created this datafield to help developers debug this Fit Field Waster DF: https://apps.garmin.com/apps/2e8bf443-f030-4bee-b816-35f5eb404550

I'll add that while your observation is correct, it also depends on the order you place things in the layout, and maybe other things (let's call it random), so it's not that always the other DF causes your's to crash, when you move things around it can be the other way around, and I think even not moving them just opening the activity multiple times can cause sometimes one to crash, while other times the other.

Obviously you can't do much about it. There are 2 things I try to do:

1. explain the problem to the users in the FAQ

2. in DFs where it's possible I started to add settings where the user can enable/disable recording certain data or groups of data to FIT. This means I'll still calculate it, so they can see it on the screen but they can decide to not to record it to the fit (in order not to crash), so I don't even create the field in that case. Of course the best would be if all developers would follow similar pattern, or even better if Garmin would somehow "sandbox" each datafield, so they won't effect each other in this annoying way.

DaveBrillhart 7 months ago in reply to flocsy🤠

Thanks! Yes I'll add a User Setting to disable the FIT create lines. Being able to catch create exceptions would be ideal to prevent a crash. I write one SESSION field and test for the 32 byte limit to avoid that issue.. But it does seem to truncate to 32 if you exceed that. I write four RECORD fields.

flocsy🤠 7 months ago in reply to DaveBrillhart

Ah yes, I forget about the uncatchable error... even more annoying, indeed

InigoTolosa 7 months ago

I am the developer of alphaHRV. It saves up to 4 fields ( records) and one session field.

The limit for all data fields is 16, so I guess those users are using some additional data fields that use fit contributor.

Any way, alphaHRV provides settings to enable/disable saving any single field.

It is not accurate saying that alphaHRV kills your data field, this is a situation generated by all data fields running at the same time. Simply, the one that tries to overpass the 16 fields limit crashes. The order is established by Garmin.

But as said, alphaHRV is not abusing on fields number and allows to disable them

DaveBrillhart 7 months ago in reply to InigoTolosa

Thanks! I appreciate the insight. I'll add the FIT Disable setting to mine and let the users know that they just need to watch for multiple fields that include FIT writes and to use the disable settings as desired. Your field is really valuable. I was talking to our mutual friend RW about it.

InigoTolosa 7 months ago in reply to DaveBrillhart

Thank you for your comment about alphaHRV.

Dealing with the limitations on the maximum number of fields that can be written to the FIT file can indeed be frustrating, as it doesn’t depend only on your code and may irritate users who know absolutely nothing about it.

As flocsy has suggested, informing users about this possibility and providing the option to disable saving to the fit file is the only viable approach in this case. It’s unfortunate that this solution relies on reducing the functionality of your own data field.

flocsy🤠 7 months ago in reply to InigoTolosa

Maybe we should create some kind of badge or banner that datafield developers could put in their description (if it would be possible to add images...) something like: "companion datafield friendly datafield" ;)

InigoTolosa 7 months ago in reply to flocsy🤠

It could be an option for users that read the description