3.2 Next Year

[Mark Liversedge]

As 3.1 gets near to release it would be interesting to get views on what should be in 3.2.

3.11 will be released at the end of this year focussed on enhancements to the train view / opentrainer.

Currently the queue for 3.2 contains the following major new features;

1. Planning

   - interactive "pmc" - e.g. set daily stress as target lts/sts/sb adjusted

   - goal based planning - performance targets w/kg, cp etc

   - predictive / prescriptive model (prescriptive load -> predictive adaptation)

2. Measures

   - support more than just weight/withings !

   - integrate cp,w' (currently separate configuration) for closed loop / feedback from models

3. Advanced Interval Analysis & Discovery

   - segments / interval discovery

   - analyse, rank, order, track, compate intervals like we do rides

   - analysis specific to interval training and fatigue / recovery

4. Foundational

   - store all rides in json

   - implement metrics using opencl

   - subdirectories for athlete data

We always end up ditching the planning piece as focus changes, but I really would like to make this the clear priority for v3.2 -- and especially the use of models to help predict and prescribe training load / workouts.

Mark

[Julian]

Hi Mark, 

This all sounds great!

Going forward if it's of any use I had planed out a vision of how an interactive PMC could work within GC.  It's just an ideas document but of course everything starts there...  Anyhow, I' super excited to see what transpires...

-J

[Mark Liversedge]

Always !

I have a lot of ideas too, but mostly involve setting target lts/sts/tb milestones and then autosolving the load required to get there.

I'll dig out my ideas and we can swap notes.

Mark

[Marc Norfield]

Will 3.2 have better workout planning functions similar to those of garmin connect or similar so that i can plan workout for rides out and about and not just for the turbo

[Mark Liversedge]

I don't use Garmin Connect.

We're talking about setting target metrics such as CP, LTS/SB (aka CTL/TSB), workout days, periodisation cycles and then have the daily load and workouts autosolved and adjustable.

We're talking about using a PMC chart as the UX and making it your planning tool as well as your tracking tool.

Mark

[paull]

I've probably mentioned this before but this is what I'd like to see in 3.2

- Change the underlying data store to a proper database like mysql or sqlserver
- Move all queries, reports, metrics etc into sql queries
- Do not hard code these sql queries into the product - store them either in the DB or in text files
- Allow users to add their own sql queries

That means that an entire community can develop reports, charts, metrics, new measures, etc and we can share what we develop just by dropping in text files to configure the reports avialable in the system.

It also means that to add functionality you don't have to recompile and release, you simply grab a few text files from some web site or even off forums like this.

[Mark Liversedge]

By this you mean the ride file data as well as existing caches and metrics i.e.. sample by sample ?

If so then you are really suggesting we migrate from a desktop application to a BI / Data Warehouse architecture.

I think architecturally it is pretty neat, but it would only really work with powerful PCs and that is a significant down-side; most users seem to be running average PC laptops with limited power, CPU and ram.

But I hear ya !

Mark

[paull]

I have a sql server system running here with 3 years worth of ride files all dumped in. Its fast.

I admit my PCs are fast (SSD, core I7, 24GB ram) BUT its fast because the data model is well designed - and all the fields are integers/doubles. It would still be decent on a slower machine.

You could easily add a segments and rides table which rolls up the ride stats for each section of interest (including the entire ride). Obviously you're then looking at a process which creates those summaries and again we'd allow sql in text files that determines how they are created. Meaning when someone comes along and invents FRC or W' or whatever then you can add those columns and change the sql text file to include whatever logic is needed to calculate them - again without the need to recompile GC. I think thats pretty cool.

So I would suggest that performance is not going to be an issue on any PC which is < 3 years old. And anyway, GC seems pretty slow loading on anything older than that, so its kindof already a prerequisite :)

Anyway, this is a tall order, but please add it to your compost bin and let if fester :)

(if I could get the damn thing compiling in VS2010 I'd do it myself !)

[Mark Liversedge]

On Wednesday, 28 May 2014 14:33:10 UTC+1, paull wrote:

I have a sql server system running here with 3 years worth of ride files all dumped in. Its fast.

I admit my PCs are fast (SSD, core I7, 24GB ram) BUT its fast because the data model is well designed - and all the fields are integers/doubles. It would still be decent on a slower machine.

COOOOL ! :)

 

You could easily add a segments and rides table which rolls up the ride stats for each section of interest (including the entire ride). Obviously you're then looking at a process which creates those summaries and again we'd allow sql in text files that determines how they are created. Meaning when someone comes along and invents FRC or W' or whatever then you can add those columns and change the sql text file to include whatever logic is needed to calculate them - again without the need to recompile GC. I think thats pretty cool.

You do know we already have a metrics SQLite database - its called metricDBv3* ? 

(The updating statistics progress bar appears when these aggregated metrics are computed)

Mark

* we changed the name to this during v3 development to allow running side by side with v2.

[Xplora213]

It might be helpful to be able to highlight the periodisation periods in a "macro PMC", as part of the planning? If you're gunning for FSB -10, and a LTS of 70 at the end of Build 2, this could be helpful if you are able to define a period of time for the next year that you expect to be in each sector, and prepopulate the TSS targets based on that.

The benefits would be an ability to more easily "restart" in the event of unexpected changes like babies, holidays or injuries, as well as giving you something to work with and compare against year on year. Coaches would probably find it useful too.

What do you think? I'm a fan of the visual, so a nice clear chart with targets would help me enormously - integration with GC is the key though.

[Kenn]

Hi Mark,

In the Measures options, I would love to have the option to sync sleep data from Fitbit, Heart Rate Variance (HRV) data (from apps such as ithlete, HRV4Training & SweetbeatLife) & Heart Rate Recovery (HRR) (either from SweetBeatLife or you could analyze the heart rate data from imported files).

[Greg Littleton]

Hi Mark, the planning piece with an interactive PMC is of great interest for me, as long as it works with TRIMP, as I've not succeeded in getting budgetary approval for a power meter, and have too many bikes anyway to have all my rides covered.

I currently have a simple python web app that uses metricDBv3 to publish charts and reports on the net (running on a Raspberry Pi), and had contemplated starting a planning component. One thing I've also thought of doing, is making a command line only build of GC that allows me to import the tcx or fit files from my device and saves them out in json format, as well as update the metrics database, and call this from my webapp. However I think that's a very niche requirement for my particular workflow, so wouldn't see it added to the road map for GC.

Also, thanks for all yours and other dev's hard work!

[Ale]

I think it would be nice if you can set a range of value instead of a single value when you write a new workout. For example if I have to do a rep with power range 55-65 %FTP I could only set 55% or 65% or a middle value but not a range of values as I can do, for example, with garmin training center.

If possible it would be useful to have the possibility to set more goals on same lap, like: 5'@85-90%FTP 80-85rpm

[BK]

When you are referring to planning and prediction, are you referring to something like the planning and predicted performance features in Skiba's RaceDay Apollo? These features alone would convince me (and many others) to leave TP. Keep up the great work! 

[Ruud Goorden]

Next to solving for PMC metrics it would be nice to actually also plan in the workouts in detail like: 10 min , 60% FTP
20 min, 100% FTP
10 min, 60% FTP
Etc.

And PMC could be updated / planned based on this.

What would really be 3.0 is if it would be possible to export this planning bit and someone else can import it to their GC.