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

ERA leads to question: Are there problems with 9.50 FW for Edge 1030?

9635560
over 5 years ago

Hi,

Trying to work out whether I need to do anything about an ERA report.

The error report is not very interesting or explanatory:

Error Name: System Error
Occurrences: 1
First Occurrence: 2020-06-09
Last Occurrence: 2020-06-09
Devices:
    Edge® 1030: 9.50
App Versions: 0.0.18
Languages: deu
Backtrace:
    DataField_SingleDialBaseView.initialize:317
    DataField_SingleDialBaseApp.getInitialView:19

Which equates to this code:

do { // Create session and lap couhts
	obj[:mesgType] = mType;
	fitFields.add(createField(fieldLabStub+id, id, dataType, obj));
	id++;
	mType++;
} while(mType < 20);

The line number is the "do {" which means that something probably happened during the loop, and the createField is the most likely issue because... createField is always the most likely issue. I've seen similarly anonymous errors for createField... 

#HINT PLEASE VOTE FOR THIS ISSUE! https://forums.garmin.com/developer/connect-iq/f/app-ideas/223155/please-can-the-next-sdk-give-more-meaningful-errors-session-createfield

However, this code has been there since the beginning and the memory limits that can cause issues should not affect an Edge 1030 that has four times the memory I built for. And the number of field limits that I am guessing at based on experience and various thread discussions [in the absence of any documentation from Garmin on same] should be comfortable for Edge 1030, too. (And hadn't previously caused issues after being live for several months.)

#HINT PLEASE ALSO VOTE FOR THIS ISSUE! https://forums.garmin.com/developer/connect-iq/f/app-ideas/229872/please-can-the-sdk-documentation-be-more-developer-friendly-and-searchable-and-complete

Finally, I checked the FW version which looks to be the most current version... In doing so, I saw a number of error reports in the forum for the 9.5 FW.

Has something changed?

Is this my bug or Garmin's bug?

G

  • 0 over 4 years ago

    Are you being bit by a shared resource issue?

    You are creating 20 fit contributions. If the device has a hard limit of 24 and another data field is providing 16 contributions, there will likely be problems.

    I have not debugged into this particular case, but I've looked at the code previously and it really seems that we need to either throw an exception or return null in this case.

  • 0 over 4 years ago in reply to Travis.ConnectIQ
    Travis.ConnectIQ said:
    Are you being bit by a shared resource issue?

    As per other threads, we do not have, nor do we seem to have any way of finding, the answer to that.

    ETA: Also, in my case, way less than twenty fields.

  • 0 over 4 years ago in reply to Travis.ConnectIQ
    Travis.ConnectIQ said:
    If the device has a hard limit of 24

    Does the device have a hard limit of 24?

    Which device has a hard limit of 24?

    Where is this written and how do we find out?

  • 0 over 4 years ago in reply to 9635560

    while(mType < 20);

    20 is defined in your own code!

  • 0 over 4 years ago in reply to jim_m_58
    jim_m_58 said:
    20 is defined in your own code!

    The code is a snippet and you have jumped to a conclusion about what it does that, in this case, is incorrect.

    Look at where I use mType - it is a FitContributor.MESG_TYPE._* constant that I was obliged to obliterate due to serious memory constraints. It proved to take up a byte or two less to do a loop than to hard code two createFields...

    In reality, I am creating a pair of fields with each loop - one for lap, one for session.

    Yes, I am guilty of the code being ugly and unmaintainable, but that is my fault and my responsibility.

    What is not my fault and not my responsibility is chasing an invisible limit that no matter how many times I ask, I cannot find the way to get to.

    I don't mind having to do a few sums, but i do mind not having the inputs to work out what those sums are.

  • 0 over 4 years ago in reply to 9635560

    I'm only going by the exact code you posted!  Slight smile

    Seems Travis has posted about your "invisible limit" a number of times

  • 0 over 4 years ago in reply to 9635560

    i only have 14 but discovered that when i use MESSAGE_TYPE_FLOAT on all contributions it shows the sdk detects the error on line 10 it only allows 10 fit contributions with float data, maybe we need an advice of transfer data limits

    Error: Out Of Memory Error

    Details: New Field out of memory for FIT data

    it´s a sdk problem

  • 0 over 4 years ago in reply to xuxumatu

    There is a limit as to how much in total can be written to the fit at one time.  Per the API doc:

    • Apps are limited to 256 total bytes per message

    • Data fields are limited to 32 bytes per message

    • Messages larger than the limit will result in a "New Field out of memory for FIT data" error.

  • 0 over 4 years ago in reply to jim_m_58
    jim_m_58 said:
    I'm only going by the exact code you posted! 

    Which I have explained, you made an incorrect assumption on: mType is initialised for the loop at FitContributor.MESG_TYPE_SESSION (18) so it builds a session field, then a lap field, then stops before FitContributor.MESG_TYPE_RECORD (20). Not pretty. Not good practice, but I was at a bits and bytes level to make memory levels safe on older devices. 

    jim_m_58 said:
    Seems Travis has posted about your "invisible limit" a number of times

    About, yes.

    But not answered the pertinent questions, ever.

    It has been a case of squeezing blood out of a stone to get to the few facts that I now do know - the 16 data fields max across all devices, that Garmin fields don't write any FIT, The number (which Travis has acknowledged is hard-coded) of CIQ fields per device Travis has also point-blank refused to share, even on a per-device basis. I have posted in the device forums (as per your recommendation) and found nothing.   

    Specifically, and most recently, after whittling down the number of fields that are created, I have crashes that I cannot resolve without knowing:

    1. How many CIQ fields can run in total at one time (not the "16" limit of data fields, but CIQ fields) on a specific device?
    2. A means to calculate total device limits of FIT fields that can run in one device on any given activity?

    I need those two pieces of information so that I can work out whether my fields are causing the issue or if it is something else. I have already had months of "suck it and see" iterations in the wild to get it down to something where:

    1. I can safely use all three CIQ slots on my 735xt with the maximum FIT fields that I build for low-memory devices (11 in total per field, which includes one MESG_TYPE_RECORD and the rest lap and session - all of them DATA_TYPE_UINT8).
    2. Higher memory devices create some additional string fields with a fixed string length that keeps it down to work safely on devices with up to two (which is probably the limit on most things) of my fields... Leastways, I see no errors with them.
    3. The only errors I am seeing now are coming from a specific, high-end, device (Montana 7XX) for which I do not know the limit in numbers of CIQ fields.

    As it stands, I am flying blind.

    There is no way for me to calculate out to see what needs to change to overcome a limit that I can only notionally hypothesise about. (That said, I am going to double-check sums to see how close the high-memory devices would come to the 256 byte limit in worst case for three simultaneous instances of my fields).