• State Not Answered
  • Replies 14 replies
  • Subscribers 18 subscribers
  • Views 2972 views
  • Users 0 members are here
Options
Related

That old chestnut: Only this time, I _REALLY_ need to know the answer.

9635560
over 4 years ago

Ok. so I have many, many, many times tried to find out some guidance on the number and type of fit fields that an activity or device can handle.

I am aware of the following caveats:

1. It is device and software dependent

2. It depends what else is running

3. There are lots of unknowns

However...

I have code that absolutely works fine on every single device that it is installed on except for one and it crashes only on the Session.createField line. I cannot replicate this one in the simulator at all. I do not have access to (or knowledge of anybody who has ever purchased) the device in question apart from the person who has so far clocked up an identical error on three fields in a related set of fields.

- In the simulator, I have a peak memory of 27.4KB out of an allowed maximum of almost 128KB. So it is not memory.

- In the simulator, despite trying any number of different routes to start and stop activities, I cannot get it to break. So it is not a crass coding error.

- In the simulator, I have tried discarding and restarting new sessions without problems. So it is not an illegal operation overwriting an existing field.

But clearly I have hit some limit or restriction on creating FIT fields.

So, please, one more time with feeling:

I am aware of all the caveats about what you can tell me about FIT field creation and FIT field limits, but I still need to know something helpful about what factors play into FIT field limitations so that I can allow for and build around them.

  • 0 over 4 years ago

    And related to this, again a question I have asked many times, but which might really be relevant here:

    How can I find out the actual number of allowed ConnectIQ fields allowed on a device? It is 100% a hard-coded limit on the device that Garmin developers should be able to make available and it is 100% something that I need to know.

    In particular, I am thinking that the issue is that the combination of three of my fields together might be tripping the device maximum for fit fields. But I have no way to test this as a) the simulator will only allow one at a time and b) the hard-coded Garmin limit that GARMIN absolutely have to have written down somewhere is unavailable to me.

  • 0 over 4 years ago in reply to 9635560

    is this one you can shed some light on?

    Thanks,

  • 0 over 4 years ago in reply to jim_m_58

    According to ERA:  

      Montana® 7 Series: 6.40

  • 0 over 4 years ago in reply to Travis.ConnectIQ

    Not much help, I'm afraid.

    For example, in that thread you state that:

    "There is a constant in the device firmware the controls the maximum number of developer data fields that can be active at once for the entire activity profile. This is the limit that  mentioned in his first response, and it is set to 16 for every device that I checked."

    This is patently incorrect!

    Or, rather...

    The background limit of 16 that is hardcoded in the firmware is absolutely not the limit that is hard-coded in the device when editing data screens of three that is available for my 735xt, two for the Edge 130, Fenix 5 series etc...

    To be absolutely crystal clear here: there is a fundamental difference in Connect IQ treatment of Garmin data fields versus developer data fields.

  • 0 over 4 years ago in reply to 9635560

    Also, reading my reply and rereading the thread, there is quite a lot of looseness in terms. My understanding so far:

    1. There are data fields coded by Garmin that may or may not contain FIT contributions

    3. There are data fields coded by CIQ developers that may or may not contain FIT contributions

    1. There are fit fields for

    - record

    - session

    - lap

    4. There is an arbitrarily hard-coded and obscure maximum limit per activity of n CIQ developer data fields (3 for 735xt, 2 for Edge 130 etc) unknown for everything else

    5. There is a firmware maximum limit per activity that may be developer data fields or Garmin data fields that is hard-coded as 16 per device activity (apparently)

    6. The number of FIT contributions of all three types probably has a device limit somewhere but I have no idea what it is and quite clearly is not the 16 cited earlier because it doesn't match with observations in the wild

    7. The limiting number of record data fields is potentially at least slightly independent of lap and session data fields 

    8. OUTSIDE OF GARMIN, WITHOUT ACCESS TO EVERY SINGLE DEVICE, I HAVE NO WAY TO FIND THE INFORMATION I NEED OR WANT.

  • 0 over 4 years ago
    9635560 said:
    There are data fields coded by Garmin that may or may not contain FIT contributions

    None of the built-in data fields that are provided by Garmin don't use fit contributions. At least none that I know of.

    9635560 said:
    There is an arbitrarily hard-coded and obscure maximum limit per activity of n CIQ developer data fields (3 for 735xt, 2 for Edge 130 etc) unknown for everything else

    Yes. This is a device-specific limit. For the most part this should not affect a developer data field... either the user has enabled your data field or they have not... The device user is subject to this limit.

    9635560 said:
    There is a firmware maximum limit per activity that may be developer data fields or Garmin data fields that is hard-coded as 16 per device activity (apparently)

    Yes.

    9635560 said:
    The number of FIT contributions of all three types probably has a device limit somewhere but I have no idea what it is and quite clearly is not the 16 cited earlier because it doesn't match with observations in the wild

    Yes. Each device has a set amount of memory it reserves for fit contributions. The limit itself is fixed for each device, but the number of contributions you can get will depend on the size of that contribution... a UINT8 contribution should be smaller than a FLOAT contribution, a single value should be smaller than an array, and a SESSION contribution should be smaller than a LAP or RECORD contribution. There is also the potential for hidden overhead (alignment and padding of internal structure data) that will have an impact.

    This makes it difficult to tell you exactly how many fields you can get for a given device.

  • 0 over 4 years ago in reply to Travis.ConnectIQ
    Travis.ConnectIQ said:
    None of the built-in data fields that are provided by Garmin don't use fit contributions.

    Isn't that backwards?
    I get running dynamics data as soon as I run with my HR-Run strap but I have never added a Garmin running dynamics field to my activity at all. Ever. Period.

    AFAIK, the default data is tracked by Garmin at a level removed from the display fields and while I see no reason why individual fields wouldn't introduce additional stored FIT fields, I have no reason to assume that the default Garmin fields are anything more than pure display.

    Certainly, I have not witnessed any changes to the FIT data that is stored by adding or removing default Garmin fields.

    Travis.ConnectIQ said:
    Yes. This is a device-specific limit. For the most part this should not affect a developer data field

    But in my case, and not for the first time it is not only very relevant but at this point is the most likely source of my problems.

    And without knowing the answer, I have absolutely no way to either confirm or deny the possibility.

    Travis.ConnectIQ said:
    Yes. Each device has a set amount of memory it reserves for fit contributions. The limit itself is fixed for each device, but the number of contributions you can get will depend on the size of that contribution... a UINT8 contribution should be smaller than a FLOAT contribution, a single value should be smaller than an array, and a SESSION contribution should be smaller than a LAP or RECORD contribution. There is also the potential for hidden overhead (alignment and padding of internal structure data) that will have an impact.

    To be absolutely clear THIS IS THE DATA I NEED MORE INFORMATION ABOUT!

    This is my specific situation in bullet points:

    1. I have a set of related fields, each of which has the capability to store a large number of related pieces of data about an individual metric
    2. There is not only a valid use case for but the original purpose of these fields was to run multiple fields together to give a detailed picture of multiple metrics combined for pacing 
    3. Each field stores a range of SESSION, LAP and RECORD FIT fields- trimmed and sized to prevent errors in the simulator
    4. I can safely run three of these fields on my 735xt without hitting any limits
    5. AFAIK, other users have been able to run two fields on their devices without hitting any limits
    6. Today, I have a user who has managed to crash out (the first crash I've had in several months) a whole range of my fields on one specific device

    In total, each instance of each of my data fields has the potential to store up to a maximum of:

    • One RECORD field as a DATA_TYPE_UINT8 (a value graph)
    • Five LAP fields as a DATA_TYPE_UINT8 (storing zone values per lap for up to five values)
    • Five SESSION fields as a DATA_TYPE_UINT8 (storing zone values per session for up to five values) 
    • Depending on memory (I toggle at 60KB on the memory limit) I might also store an additional three SESSION fields as DATA_TYPE_STRING with a :count of 6 (five characters plus end of record)

    Therefore, for low memory devices (like my 735xt), I have a maximum of 1 RECORD + 5 LAP + 5 SESSION where all are UINT8 for each instance giving a total UINT8 count of 11. For high memory devices (like everything else), I have that same value plus potentially an additional three STRING fields with a total character count of 18.

    I am aware that there are other device specific limits that might come into play, however, I am also aware that the device in question is a comparatively new, high-end device that has a multiple of the available memory. The only limits I am likely to be close to are hard, Garmin or hardware imposed, limits that Garmin can have visibility of and I, apparently, cannot.

    So in this case, in order to debug the crash (which I absolutely cannot replicate without the device) I need to know my absolute, activity and device specific totals AND how to calculate down from those limits based on record type and data type.