Data Field: AppBuilder

By user request, this app lets you define your own data field, based on a simple math formula like cadence / 2.

If you want to get fancy, there's conditional expressions (like IF in Excel), functions for data analysis (like MIN and AVG), and the data field can also display the text of your choice. The resulting data can be (optionally) written to the activity FIT file.

With AppBuilder, you can implement almost any field that involves math, such as: calculating normalized power and saving the data to the FIT activity file, showing the average pace for even-numbered laps, or recording the amount of time you sprinted.

Full documentation and examples here:
http://ciq-appbuilder.blogspot.com/

AppBuilder 5:
Now with new features! AppBuilder 5 is a completely new app, so please check it out in the store if you are interested in any of the new features.
https://apps.garmin.com/en-US/apps/fd690281-9c22-4fee-a81e-3b7f39aa67c5

- Store up to four formulas per app. Switch between formulas directly on the watch, without using a phone or PC. With four clone apps, you can store up to 16 formulas total
- User variables. Allows for powerful formulas where information can be stored at one point, like the start of a lap, and used later. e.g. Lap elevation change
- Improved timeavg() options. Allows for simpler, more flexible normalized power function
- More functions and variables

4 clones of AppBuilder are available in the store, so you can have 2 formulas in the same activity
  • Thanks for the quick reply. I see.
    The labels are shown in Android, as well as iOS in the statistics section, 0 in GC web.

    Why are the labels fixed in the graphs?
    Is this problem going to be fixed (I guess this is a limitation introduced by the Garmin developers)?
  • Assoede it's a design limitation, so I guess it won't change unless there's a good reason. The displayed labels are submitted as part of an XML file in the app resources, so they can't change at runtime. This does allow them to do nice things like supporting multiple languages with alternate resources.

    Pretty much every other app except this one knows what they are going to display/write to FIT in advance, so the design makes sense. It does look a little funny in this case.
  • Former Member
    Former Member over 6 years ago
    First of all, nice job with the new version. Still using the classic version, but will switch to the new version for sure when I got some spare time to properly test it.

    When I started thinking about the added possibilities of the new version, one though came to my mind:

    What kind of identifiers does the recorded IQ data have, is it possible to set this in AppBuilder somehow? I guess what I'm driving at, is that currently running power requires that it's recorded as IQ developer data, then 3rd party websites like Training Peaks, Sporttracks etc. pick that up and show power for the activity (native power is still not supported for running).

    So could it be possible for IQ field like AppBuilder to take power data from a connected power meter (like Stryd or Runscribe), and then write it as IQ data so that it would be recognized by 3rd party sites?

    The reason I'm asking this is that currently the amount of IQ data fields is limited to only 2 slots per activity, and I'd much rather give it to a more flexible datafield like AppBuilder than use Stryd's own datafield that I currently only use for recording power. The extra Stryd metrics don't matter that much to me, but power would be nice to have.

    My guess is that there might very well be some mutual agreement to what kind of identifier to use for IQ power data as most of the current running power solutions write power as IQ data.

    What do you think?
  • JTH9 great idea and something I've thought about from the start. Yes, there is a way for third party apps to write standard data such as power -- it's called "native field numbers".

    The Connect IQ API lets apps declare that their 3rd-party FIT data is equivalent to some native FIT data such as power or cadence. This "native field number" information is written to the FIT file at run time, so AppBuilder can take advantage of it.

    Currently, Garmin Connect ignores "native field number" information when it shows you your activity data. Only certain 3rd-party sites will look at it and override native power data with 3rd-party power data, for example.

    With that in mind, I've rethought the FIT file stuff.



    Update 5.7 [CIQ2 devices only]:
    [as always, replace square brackets with round brackets]
    • Remove "record lap data to FIT file" option
    • When "record data to FIT file" is checked
      • The formula result is still automatically written to the activity graph data (once per second)
      • The result is not automatically written to the lap data
      • The result is not automatically written to the summary data

    • Now if you want values to be recorded to lap or summary data, you need to explicitly call RECORDLAP or RECORDSUMMARY
    • Added new function NORECORD, which takes no parameters. If you call this function, it disables automatic recording to the graph. That way you can avoid having a blank graph when all you wanted to do was record lap or summary data.
      e.g. Record max HR to summary; don't record anything to the graph; display HR:
      RECORDSUMMARY[MAX
      ] ; NORECORD[] ; HR

    • Addded optional second parameter nativeNum to RECORD, RECORDLAP and RECORDSUMMARY
      RECORD[X, nativeNum]
      RECORDLAP[X, nativeNum]
      RECORDSUMMARY[X, nativeNum]

      Records the value X to the graph, lap data or summary data, respectively. If nativeNum is not NULL, this value indicates that this field can be treated equivalently to a field defined in the FIT SDK.
    • To find Native Field Number definitions:
      1) Download the FIT SDK: https://www.thisisant.com/resources/fit
      2) Open profile.xlsx
      3) Switch to the Messages tab
      4) Scroll to the Activity File Messages section
      5) Look up field numbers in the appropriate section (see next post)
  • ...continued from previous post:

    Summary fields - RECORDSUMMARY
    These are found in the "session" subsection. e.g.
    avg_power = 20
    max_power = 21

    Lap fields - RECORDLAP
    These are found in the "lap" subsection. e.g.
    avg_power = 19
    max_power = 20

    Activity graph fields - RECORD:
    These are found in the "record" subsection. e.g.
    speed = 6
    power = 7

    e.g. Record Max Power to the activity summary:
    RECORDSUMMARY[MAX[Power], 21]
    e.g. Record Power to the activity graph:
    RECORD[MAX[Power], 7]

    The FIT profile data also specifies the units for the native fields. E.g. Watts for power and metres/second for speed. I believe these should match the “raw units” AppBuilder used (e.g. Speed_raw), but it’s best double-check to be sure.

    e.g. Record Speed to the activity graph:
    RECORD[Speed_raw, 6]

    Note that this only works if 3rd-party sites are looking for CIQ fields that use "native number" functionality. If some CIQ app records its own data without using "native number", and sites are specifically looking for that app data, setting the native number won't help you mimic that app's data.

    However, I looked at a FIT file created with the Garmin Running Power app, and it *does* use native number, for power, avg_power, etc., so that's good news.
  • Former Member
    Former Member over 6 years ago
    Wow, that was quick. :) I'll see if I can try it out this weekend.
  • Shoutout to any Stryd employees reading this thread:

    Thanks for suggesting your (paying) customers use my (free) app as a workaround for your limitations without a link, with the wrong search keyword and the wrong formula, so it won't work.

    Super-happy to see corporations try to save a few bucks off of someone else's work, especially when they put roughly 30 seconds of effort into it.

    #quality

    You're welcome.
  • Former Member
    Former Member over 6 years ago
    That sucks pretty bad... Luckily they had the comment section so you could correct the information. TBH I didn't even know they had this in their support pages until this, so not sure if many have even read it. But similar lack of effort goes for other stuff as well, like badly documented RSS calculation with a formula that doesn't work etc.

    I think they follow this thread at least occasionally, since they know about the app and it's been mentioned at their user forum a couple of times (by myself and a few others).
  • It did remind me that I wish I'd never defined AVG and TIMEAVG to ignore zeros. I wonder if there's any way to change that now....
  • Former Member
    Former Member over 6 years ago
    I think it's good to have the option if one wants a moving average, also if your powermeter or watch has a drop out issue, which is more common than one might think. Although admittedly I mix them up too, I guess it depends on the logic you think. Perhaps AVG could've been default operation and AVG0 ignore zeroes. But I guess too late to change now as it would mess up formulas currently in use if the user updated the app :)