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
  • Update 5.5

    Add ability to auto-select formula based on sport.

    - Set "Select Profile" in app settings to "Auto"
    - Enter the formulas to be used when you add AppBuilder to an activity of the following types
    Profile 1 = Running
    Profile 2 = Cycling
    Profile 3 = Swimming
    Profile 4 = Other

    This works on devices which support sport-specific HR zones
  • hotdogpartysausage I dunno, I think the field is way too complex for its own good, but no worries!

    Sorry, I forgot that ALT was only on CIQ2 devices. It's tiny and I managed find yet another way to optimize other code, so I added it for CIQ1.

    I would've expected you to see !AdvFn and not !Name, though. After updating, please copy the example directly from here (tap the copy icon):
    https://ciq-appbuilder.blogspot.com/p/examples.html#power_20_approx



    Thanks for the Fenix3 update. I've installed the equation from the link & although I won't get chance to test it until the weekend it doesn't generate the previous error.
    I've also put the CIQ2 versions of the FTP & 20 Min Power on my Edge1030 so will test those at the weekend too
  • Hi. I was investigating putting text on a datafield. Regardless of the case I use it is always displayed in lower case on the edge 1030. The rules for the Format function seems to suggest that using X should capitalise text but I can't work out how to use it. Could you please point me in the right direction? Cheers
  • hotdogpartysausage thanks for catching that. I tested it and it looks like two things are happening:
    - Once you use text, a smaller font is selected
    - Only lowercase characters are printed

    The first thing is somewhat expected, since the large fonts for numbers don't support alphabetical characters, but I don't see why they should be restricted to lowercase.

    I'll have to update the docs and maybe file a bug report.

    BTW, Format() is only used to format numbers -- it won't work with text....
  • Thanks for the feedback. I thought I might have been doing something silly then the penny dropped regarding the FORMAT function when I was having a look again at the link you posted about the instance method... I've still got a lot of learning to do
  • Food morning, I had this formula on applbuilder5 on my F5x+ and It worked well several times until today when I found the IQ! on datafield without change anything...what I'm doing wrong?

    SETV(1,(Distance - PREVT (Distance,30))) ; SETV(2,(ALTITUDE - PREVT (ALTITUDE,30))) ; SETV(3,Distance + (10 + TotalAscent * 5.5 - TotalDescent * 2.3)/1000 ) ; SETV(4, SUM((GETV(1) GT 0.03) * (GETV(1) * ((GETV(2) GT 0) * 40 * (GETV(2) / (1000 * GETV(1)))^3 + (GETV(2) LT 0) * 6 * (GETV(2) / (1000 * GETV(1)))^2 ) )/30 ) ); ALERT( ((GETV(4)+GETV(3)) MOD 1 ) LT 0.1 ) ; GETV(4)+GETV(3)

    Thank you
  • albertopirro I tested your formula in the simulator and it takes too long to be processed which causes the watch to kill the app. My recent changes for text support pushed it over the edge, apparently.
  • Update 5.5.4
    For large-memory devices only (645 Music, Fenix 5X/ 5 Plus, newer Edges) -- make processing of formulas without text a little faster at the expense of making the app a bit bigger. This fixes certain formulas that broke with the recent change to add text support.

    albertopirro I tested your formula with the new build and it seems to work fine now. This is the very reason is decided to launch a new app -- to avoid breaking changes. Unfortunately I can't make a new app every time I add features.... :/
  • Thank you very mutch, tomorrow I'll test it...I want to give you the best compliments for your work, these apps are fantastic and have allowed me to retire my old Suunto Ambit 2 :-)
  • Former Member
    Former Member over 6 years ago
    I guess the biggest problem is to get the gradient calculation responsive yet stable enough. Garmin Running power and Stryd both are probably using all the possible tricks in the book and have around 10s lag with their gradient calculation. With both of them you sometimes still see your uphill / downhill power when you're already past the steepest slope. Any longer time window and one may argue if it's very usable anymore for real time pacing.

    I experimented with grade adjusted pace in past a bit, running through recorded Stryd distance & watch altimeter values in excel, but seemed simply using two single points in elevation 10s apart would not always result in a stable value. This is because the accuracy of elevation data is not that great and may go up / down slightly from one second to another. This creates jumpy gradient especially when the elevation change is small within the sample window. Better alternative seemed to be taking 3 closest elevation values, average them and calculate gradient based on that.

    I have to say I get a headache trying to think how to fit this in a simple appbuilder formula. You might get a rough and ugly version running, but is it worth actually using?