Third-Party Data Field Limit is 2, Not 4

KrapfenKringel said:

If Garmin says you can use 4 the expectation is I can use 4 without any limitations.

Again, if you apply the same argument to the previous limit of 2 CIQ fields, it would fail. (Because of the developer data limit that was already mentioned, and which has already caused problems for well-known apps like Stryd Zones. Again this is why Stryd support recommended uninstalling all other CIQ data fields, even when the limit was "only" 2 fields.)

If the expectation did not hold for 2 fields, then there is no reason to believe it should hold for 4 fields.

I'm not saying it's an unreasonable expectation, just that it hasn't held in the past, and nothing has changed in that regard.

KrapfenKringel said:

Correct would be to state "you can use 4 now*" and then describing the limitations *

Yes, that would be nice, but it's also understandable that Garmin would not go into such arcane technical details which would only confuse the majority of users.

A better solution would've been to avoid this type of collective limit in the first place, but I don't think it will ever go away now. (Wouldn't mind being proven wrong tho.)

With the current implementation, it will never be 100% safe to have more than one CIQ data field, because the collective limit on developer FIT fields will always leave room for 2 CIQ data fields to collectively go over the limit, even if no single data field would do so.

I think the only thing Garmin could do to avoid this problem would be to determine the maximum amount of data 1 CIQ data field could ever write (there are certain per-CIQ data field limits), and set the collective limit by multiplying that amount by the max number of CIQ fields for a single activity. It would be kind of tricky since the per-CIQ data field limit isn't the same kind of limit as the collective limit, but it might be possible in theory. However, it doesn't seem like they will ever do this (since they haven't done it yet.) Not sure if there is a strict technical limitation here, or just a desire to save memory.

For example, the current per-CIQ data field limit on developer FIT fields is said to be "32 bytes per message". There are 3 kinds of messages (record, lap and session), and each field has a minimum size of 1 byte. So it seems that the theoretical maximum number of fields for a given CIQ data field is 32 * 3 = 96 developer FIT fields. Ofc this is an impossible scenario irl, since the collective limit is only 16 developer FIT fields.

Theoretically, if Garmin changed the collective limit to 96 * 4 = 384 developer FIT fields on Fenix 8, it would be impossible for any number of CIQ data fields to surpass the collective limit. It would effectively be the same as having no collective limit at all. However, there is a collective limit and it's 16. I don't know how "necessary" this limit is, but is it realistic for us to believe that Garmin will multiply this limit by 24 (384 / 16) to ensure that CIQ data fields never interfere with each other?

I have taken a look at what the 4 CIQ fileds are writing to the .fit file and it isn't onerous at all. One of the CIQ fields I am trying to add, 80/20 zones, doesn't write anything at all. Additionally,  there are a lot of empty columns in the .fit files whi hvappear to be empty placeholders,  so I don't buy the argument that there are space limitations.  My suspicion is that they are intentionally making things difficult for people to use third party sensors.  This is unfortunate as they can't expect to be on the leading edge of everything, let alone, own the patents.

flowstate said:

expectation did not hold for 2 fields

2 isn't 4, apparently not running into any issues with 2 is more likely then 4. 

KrapfenKringel said:

2 isn't 4, apparently not running into any issues with 2 is more likely then 4. 

As I said, this might be explained by the possibility that Garmin has not raised the per-activity developer FIT field limit of 16, even though the CIQ field limit has been changed from 2 to 4.

For watches with 2 CIQ fields, each field can write an average of 8 developer FIT fields.

If what I'm guessing above is correct, then for watches with 4 CIQ fields, each field can write an average of 4 developer FIT fields. If so, it's not surprising that ppl would see more issues with 4 CIQ fields.

But again, even with 2 fields, it's clear that there are issues:

- many users have complained about crashes when using Stryd Zones with other CIQ data fields

- obviously Stryd has noticed as they literally wrote a support article telling people to uninstall all other CIQ data fields (this is long before watches supported 4 CIQ fields)

- at least one popular CIQ data field has an option to record less data than it normally would, again because users are running into this problem, even with watches that only support 2 CIQ fields)

neskery said:

I don't buy the argument that there are space limitations

I didn't say that are space limitations in the FIT file.

I said that the 16 developer FIT field limit is probably to save *memory*. To be clear, I meant RAM (working memory) that's used during an activity. 

neskery said:

My suspicion is that they are intentionally making things difficult for people to use third party sensors.

Except that the 16 developer FIT field limit I mentioned above is *well known* to developers (there are years of discussion about it), and it applies to any kind of 3rd-party data that's written. The data doesn't have to come from sensors.

It's also well-known that Garmin cripples 3rd-party apps in many ways. For example, no 3rd-party app can override built-in data like distance or pace. Garmin doesn't make a secret of this at all.

Furthermore, not all 3rd party sensors require a CIQ data field to work. 3rd party sensors which use a standard ANT+ profile like heart rate monitors and foot pods can connect natively in exactly the same way as Garmin sensors.

There's no need to cook up a conspiracy theory when the facts are already known. I mean it's possible that's their intent, but even if it was, what are you gonna do about it? It would be better to try to determine what the actual technical issue is, so at least you could try to avoid it, and possibly ask Garmin to change it.

You can try to validate my guesswork in so many different ways:

-  Use the Fit Field Waster CIQ data field I mentioned to test FIT field data recording. Increase the amount of data that's recorded until it crashes. This way you could determine whether the limit is still 16 developer FIT fields. If it is, that would validate some of the stuff I'm saying (like how it def makes sense that it would be more likely for 4 fields to crash as opposed to 2 fields).

- Install 4 CIQ data fields which do not record *any* data at all. I would expect you to not have any problems here (unless the problem really has to do with sensors, and not recording data - see next point)

- For bonus points, install 4 CIQ data fields which connect to 3rd party sensors but do not record any data (or have an option to disable recording). If there are no crashes in this case, then it would prove my theory that has nothing to do with 3rd party sensors (at least not directly)

I will say there have also been issues with multiple CIQ data fields that make ANT+ connections, so it's possible these crashes actually are about connecting to sensors, as opposed to recording too much data. It's just another example of the fact that CIQ data fields can interfere with each other. But if so, it's actually possible for a well-written CIQ field to *not* crash when there are ANT+ issues, but to instead display an app error message and/or try to automatically reconnect. 

Or, you could just guess that Garmin is randomly making your CIQ data fields crash because they hate their users and leave it at that. Tbh, idc, you do you.

Speaking of arbitrary memory and storage limits, like I said, I don't know if this 16 developer FIT field limit is truly "necessary". Garmin has a lot of weird arbitrary limits which seem to be 10-20 years old, and which haven't been updated to match modern hardware (or if they've been updated, they still seem too low). Another example is the limit of 25 stored locations on the watch, or the limit of 32 CIQ apps (16 on some devices iirc). These limits don't make much sense for watches which have gigs of storage for maps and music.

neskery said:

One of the CIQ fields I am trying to add, 80/20 zones, doesn't write anything at all.

Do you mean this (80/20 Run Zones): https://apps.garmin.com/apps/597586ff-128f-46ca-a896-1679f8c10d1a

I just tried it on my FR955 and it records 10 fields:

- Charts: HR training zone, power training zone, run power, pace training zone

- Stats (summary): time at low HR, time at high HR, time at low pace, time at high pace, time at low power, time at high power

Hear, hear!

Good day,
Many interesting and important aspects have been described, only one thing is missing.
The good and at the same time emerging problem of Garmin in the constant further development of the software. This leads to overlaps between the new Future and existing apps from third-party providers. If they want to access data, these are now exclusively available for the new Future from Garmin.

Yours sincerely

DK