Ticket Created
over 5 years ago

WERETECH-7824

Fit Contributor fails to write developer fields to MESG_TYPE_SESSION or MSG_TYPE_LAP messages.

Connect IQ Fit Contributor creates  'developer_data_id' and 'field_description' messages for  MESG_TYPE_RECORD messages in the Activity FIT file, but it fails to create them with MESG_TYPE_SESSION or MESG_TYPE_LAP .

Code - adapted from Module: Toybox::FitContributor


 if ($.session == null)
        	{
            $.session = Record.createSession({ :name => "raceQs", :sport => Record.SPORT_GENERIC});
             $.session.start();
	bananasEarnedField  = $.session.createField(
	"bananas_earned",
	   5,
	   Toybox.FitContributor.DATA_TYPE_UINT16,
	     {:mesgType=>Toybox.FitContributor.MESG_TYPE_SESSION, :units=>"B"}
	        ); 
        }
        totalBananas = 100;
        bananasEarnedField.setData(totalBananas);


Procedure.

Compile and run an app containing the code in the SDK simulator or a physical device (I used a Fenix5)

Save the Activity to a local file.

Run FitCSVTool.jar from the Fit SDK package on the resulting fit file

Expected result:

To find In the Fit File contains 

Definition 9 developer_data_id
Data 9 developer_data_id
Definition 10 field_description
Data 10 field_description

Actual result

No developer_data_id or field_description Definition or Data messages in the output.

Further info

  1. When I modify the code to generate a MSG_TYPE_RECORD, the expected fields are generated and the developer data is found in the 'record' messages
  2. when I run with MSG_TYPE_LAP no developer_data_id or field_description Definition or Data messages in the output.
  3. I have built a Fit file decoding program in PHP to examine session, lap and record messages and to decode developer data by interpreting the developer_data_id and field_description messages. This confirms what I'm finding from FitCSVTool.


[UPDATE]

I have since discovered that when writing a developer field to a MSG_TYPE_LAP message, the data is  in fact written to the message, but there are no developer_data_id or field_description messages which explains why FitCSVTool fails to detect the value.

Alan.raceQs
  • over 5 years ago in reply to Stephen.ConnectIQ

    Former Member

    I have returned to this issue and think I have resolved the inconsistency between your working code and my failing implementation for creating a developer field in the session message.

    If, in your example, you define the bananasEarnedSession variable inside the onSelect() function (instead in the class definition), like

     function onSelect(){
		var bananasEarnedSession = null;
		var boatName = "Harlequin";
        if ($.session == null){
            $.session = ActivityRecording.createSession({ :name => "raceQs", :sport => ActivityRecording.SPORT_GENERIC});
            $.session.start();
	        bananasEarnedSession  = $.session.createField(
                "bananaSessionName",
	            5,
	            Toybox.FitContributor.DATA_TYPE_UINT16,
	            {:mesgType=>Toybox.FitContributor.MESG_TYPE_SESSION, :units=>"SessionUnit"}
	        );

            bananasEarnedLap  = $.session.createField(
                "bananaLapName",
	            6,
	            Toybox.FitContributor.DATA_TYPE_UINT16,
	            {:mesgType=>Toybox.FitContributor.MESG_TYPE_LAP, :units=>"SessionUnit"}
	        );
        }
        var totalBananas = 100;
        bananasEarnedSession.setData(totalBananas);
       	var lapValue = 999;
        bananasEarnedLap.setData(lapValue);

    }

    the code runs, but the  bananasEarnedSession field is not created. 

    It seems to me that the field variable has to be defined in the class scope, like in your code, even though, it's only referenced in the onSelect() function.

    Phew!

  • over 5 years ago in reply to Alan.raceQs

    P.P.S You might have someone look into the scores of "unknown" record types and "unknown" field types generated in the CSV.

  • over 5 years ago in reply to Alan.raceQs

    P.S. I have run your project and can confirm your findings. It confirms that there is a bug in the Garmin code or the documentation. Please follow up as a bug report. I think I am hitting quite a few async issues with writing laps that need to be sorted out.

  • over 5 years ago in reply to Stephen.ConnectIQ

    It's all back to back.

    I think you are saying that you have been able to replicate the issue and are proposing a strategy to work around the possibility that some of functions in ActivityRecording or FitContributor are "non-blocking" and require asynchronous handling.

    There's no hint of this in the documentation, nor are there any handlers provided. That would make it either a bug either in the SDK or in the documentation wouldn't it?

    I can't see there's much to be gained from me testing out your work-around if you believe it is a bug.

    Please could you refer your findings to the bug resolution centre?

    Thanks for your efforts to follow this up. 

  • over 5 years ago in reply to Alan.raceQs

    I'm using FitSDKRelease_20.80.00 FitToCSV.bat.

    In my original comment, everything seems to be working correctly using this FitToCSV and the fitContributor code I supplied.

    When I use this same FitToCSV.bat on the .fit file that you supplied in the email, i get a byte identical .csv file as the out.csv that you attached. This makes me believe that there is no issue with the FitToCSV tool, but there is an issue with the .fit file.

    I'm thinking there may be a synchronization issue in the app.
    I'm able to get similar fit file issues if I have a session where I start(), write fit Data, save() and stop() in 1 code path with no stopping. Doing this is causing the "corrupted" fit file that I believe you are also getting (with "unknown" fields). If I add a timer and setData() inside the timer callback, I'm seeing all the data in the fit file as I would expect.

    Is there time between when you are starting, writing and save/stopping the session? or is it all back to back?

    I'm sending you the working project via email.