.. New derived data series representing an estimate of core temperature
on the basis of HR changes.
* shown on AllPlot and RideSummary
* 2 new metrics; max and avg core temperature
.. This has been based upon "Estimation of human core temperature from
sequential heart rate observations" Mark J Buller, William J Tharion,
Samuel N Cheuvront, Scott J Montain, Robert W Kenefick, John
Castellani, William A Latzka, Warren S Roberts, Mark Richter,
Odest Chadwicke Jenkins and Reed W Hoyt. (2013). Physiological
Measurement. IOP Publishing 34 (2013) 781–798.
.. based upon Fiet-type formula elevation^2 / distance.
From an idea on Dan Conelly's blog.
Some examples:
Mt Ventoux - 121
Alpe d'Huez climb - 83
Galibier - 81
Glandon - 66
.. so it's not perfect, but gives a good sense of hard
versus easy !
.. with a sidebar indicator
.. we may need to change when we have planned workouts
as the intervals will need to match the plan.
.. but we can use the same concept of 'quality' when
comparing a full activity with what was planned.
.. heartbeats x joules, when unfit you may generate low watts
but with a high hr, as opposed to the other way around.
.. an attempt to combine central and peripheral stress, can be
used to compare with power only stress metrics
.. removes across the code base
.. need to fixup RideFileCache and Lucene refresh
within the RideItem/RideCache framework, they will
NOT be refreshed at present
.. need to look at how charts get refreshed on data
changes now RideItem provides a more granular
mechanism (look for XXXREFRESH in code)
.. New Intervals code will definitely NOT compile
and needs to be redesigned/reimplemented to fit
in with the ride cache
.. so we can now call that instead of doing the conversion
and formatting all over the code !
NOTE: it still needs to be /called/ in the code, that change
will need to be applied everywhere a metric is displayed
to the user.
Decoupled classes from MainWindow to reference Context
and Athlete (and introduced a couple of new headers).
We no longer pass around a MainWindow pointer to children
but pass a context instead.
There are still a few pieces left in MainWindow that need
to move to a better place;
* Setting/clearing filter selection
* Working with Intervals
* Adding/Deleting Rides
* Save on Exit
As mentioned previously there are lots of other parts to
this refactor left to do;
* break MainWindow Gui elements into Toolbar and Views
* migrate from RideItem and Ridelist to ActivityCollection
and Activity classes that are not tied into gui elements.
* introduce Application Context and AthleteCollection
A few months ago I commented out the calculation of metrics
for manual ride files. This was a hack to avoid fixing the code
to handle metric calculations from overrides where there are no
data points.
This annoyingly meant that the 'rides' metric was zero for manual
ride files, and any derived metrics similarly were zero.
This patch fixes that.
This patch introduces new functionality for working with
Heartrate based data.
* HR Zones can be defined, from Resting, Maximum and Lactate HR
* TRIMP metrics are calculated; TRIMP, TRIMP100 and Zonal TRIMP
* TRIMP metrics can be used to drive the PMC
* Time In Zone metrics for HR have been added
* Histogram window will now work with Power/HR zones
* User Settings have been added to record gender, weight and others
* RideFile has a new tag "Athlete" which is set to the athlete name
Fixes#140
Primarily to make override() a base class function that can be
used for any metric rather than expecting each metric to provide
a local version.
Also, add explicit notion of "average" vs "total" ride metrics, as
it will let us improve how the metrics DB handles averages later.
There is a possibility that ride metrics may become unavailable yet
remain requested by QSettings (stored in
~/Library/Preferences/org.goldencheetah.GoldenCheetah.plist on OS X).
This patch ignores any metrics listed in the preferences yet are not
supported by the running version of Golden Cheetah.
Move the logic for how to compute RideMetrics from a RideFile, including
dependency tracking, out of RideItem and into RideMetric. I'm going to start
using them for intervals as well as rides, and I don't want to construct a
RideItem for each interval. It also seems more natural here. For
performance, RideItem still caches the computed metrics for a RideFile.
