Data Field: AppBuilder

Big-Dave-Road-MTB, try this formula:
formatdecimal(avg(power) / userweight, 3)

Assuming your weight units are set to kg.

The same formula, regardless of unit settings:
formatdecimal(avg(power) / (userweight_raw / 1000), 3)

---

Latest update:

Add formatdecimal(x, n) function: formats x to n decimal places.

e.g. formatdecimal(power, 3)

formatdecimal(x) still formats x to 2 decimal places, by default.

There was some discussion of Grade adjusted pace in this thread awhile ago, mainly Strava's new HR adjusted GAP. I've been toying with the idea for a while now to test it out in practice and have found a pretty close approximation for the adjustment curve.

Only thing missing now is grade calculation. Only example I found on the document page was to use prevd, but for more accurate results I think comparing values in a fixed time window would be better.

Could this be possible using prevt? Only that the description suggests it's not very accurate:

• prevt(value, t) [N]
  Retrieves the last sample of value from at least t seconds ago, as measured by the activity timer. Returns null while the timer is not running.
  (data is not sampled once per second; the total number of samples will always be around 10)
  

I already have a working model running on Excel spreadsheet, but to make this work with real time data I'd need some method to keep an accurate rolling value of exactly x seconds ago to compare to current value. Is this currently possible with AppBuilder somehow?

JTH9 No it's not accurate, as you pointed out. PREVT basically divides your time period into 10 and only ever stores 10 samples. It's lame, but I did it because storing more samples just didn't seem feasible and there wasn't a good use case for PREVT/PREVD except for grade, which is already an approximation.

I don't have a function for N samples ago, although you could mimic it by nesting prev[] functions.... Like prev[prev[x]] is the sample of x from 2 seconds ago....That would obv only work for very small values of N, and it would be very inefficient. I can take a look at PREVN or something like that...the equivalent of TIMEAVG, but with samples, not averages. It would use up lots of memory, so I'm not sure if it would work on any of the devices that don't support AppBuilder 5+.

Speaking of which...

Update: AppBuilder 0.5beta

Optimized startup code so the data field has less chance of crashing on a "timeout". This means that formulas can be a bit more complex on startup. This also means that the data field won't just crash out of the box.

Having said that....

Just wanted to give anyone currently using AppBuilder 5+ the heads up, because what you're using right now is going to change in the near future.

With 6 data fields, a huge problem with AppBuilder is more and more apparent. This is something I realized a while ago, but tried to ignore as long as people weren't using formulas that were too complex.

It just isn't feasible to process human-readable formulas in the data field. Data fields have a strict limit on startup time, and AppBuilder wastes a lot of operations translating your formulas into something it can use, especially on older devices, because things are done very inefficiently to save valuable memory.

Now that newer watches have more memory, the main bottleneck is AppBuilder's startup complexity.

I think moving forward, AppBuilder 5+ will only be feasible if you copy your formulas into a web app, like DIY Data Field. You'll get some weird strings of letters and numbers that you'll have to paste into your app settings.

The huge advantage here is that AppBuilder will no longer be severely hamstrung by the complexity of the symbols in your formula. Sure, there'll still be practical limits, but they won't be reached so easily.

The disadvantage is that you'll have to rely on the web app being available for the foreseeable future. For simple formulas like "Cadence / 2", this will be pretty annoying for sure. Now it will be that much harder for you to switch formulas using your phone.

With that in mind:
1. I plan to host on the same website as the docs: blogger.com, owned by Google.
2. I plan for it to be a fairly dumb webpage with static HTML and Javascript. This means that you'll be able to save it to your PC -- who does that tho? -- and run it locally if things ever go wrong. However, app updates will require that you have the latest version of the web app.
3. I don't plan for it to be super-fancy or anything. It'll probably just be two text boxes and the same basic error checking as AppBuilder itself. The advantage is I'll be able to highlight exactly where the formula went wrong.

I can't give a solid ETA, but probably sometime in January. Can't make any promises, but I might be able to add support for CIQ2 devices with less memory like 935 and 645 [non-music], once I rip out all the formula processing code.

---

Sorry for the multiple posts, the forum just wouldn't accept them all as one post.

Thanks, I thought about nesting prev already so will give it a try if nothing better is available. My models have been hovering around 7s, but will have to see how it turns out. I'm trying to keep it simple as possible, at least the model in excel seems promising, so definitely worth a try at least.

Also for me the web wouldn't be a problem. I already got used to copying strings with DIY. I actually think this is much more preferred workflow for an app like this than trying to edit on the mobile app where typing is slow anyway.

First test was at least promising. I got recorded a grade graph and it was very close to what Sporttracks displays for example and it seemed pretty responsive too. Quite similar lag to what Stryd has for example. I had 5 x nested prevs for both altitude and distance. Could be a bit more stable on the go I guess, but I already had 5s averaging added on top of it and don't want to make it too complex. Once I add speed correction is the final test... will post hopefully here when I got a final working version.

JTH9 nice! Thanks for the effort. I'll look at prevn() (or whatever it should be called) in the future. Probably early 2019.

AppBuilder 5+: Major update [1.0beta]

I pulled the trigger and ripped out support for direct entry of formulas. For each formula, you now have to generate code at https://ciq-appbuilder.blogspot.com/p/5plus.html and paste it into your settings.

These codes can get pretty long (over 200 characters). There used to be an issue with settings lengths over 256 characters in Garmin Connect, but it seems to be fixed now ,at least on iOS. Let me know if you have any issues with longer codes.

If there's a problem with your code, 5+ will helpfully display "!Code" in the corresponding field.

I also had to remove support for Edge 1000, Oregon and Rino, as the data field now requires CIQ3. Hopefully nobody was banking on that support.

Notes
- All your other settings are still in the GC app
- You need a separate code for each of your 6 formulas
- The web app, as promised, is static HTML/Javascript, so you can save it to your PC and use it forever. You will need to save the latest version whenever new functions or variables are added.
Note: Loading the page from a saved file on your PC currently works out of the box with Firefox. With Chrome, you might need to change some flags.

- The web app will check your formula for syntax errors, misspelled/unknown names, and unbalanced brackets, but it isn't perfect [yet]. If you try really hard and type random brackets, you can get code that the watch will reject with a "!Syntax" error. Eventually I'd like to make the error checking bulletproof.
- There's currently no way to get your original formula back from the code. And there may never be, due to the way the formula is transformed for consumption by the watch. I recommend making a text file on your pc or phone with formulas and codes. With this in mind, the web app has a "Copy Formula and Code" button.

Re: support for devices with less memory like 935 and Fenix 5. This is probably not going to happen any time soon, or ever. Even if I could somehow get the datafield to run on a 935, it probably wouldn't be very useful since there wouldn't be a whole lot of memory available.