... sync handling of (TM) in all places and Do Not allow translation for
these terms any more, since it's a fixed term anyway - and there are
many dependencies (which outside EN create unexpected results). - in all
Texts/Fields use (TM) in HTML use the TM (special characters).
-- more testing in language other then EN still required - but so far
working fine
... and more tr()
.. metric of the aerobic-ness of a ride based upon the
ratio of a-TISS to an-TISS.
.. bear in mind the curves for a/an TISS are being looked
at as we speak !
Added a few new training stress metrics whilst discussing
and working on a multicomponent view of training stress.
This is all a wip falling out of discussions around stress
metrics beyond the old TSS/BikeScore models.
For now this just includes;
1. Aerobic Training Impact Scoring System on PM/PMC
2. Work (Kj) above/below CP on PM/PMC
3. Aerobic TISS on the Ride Plot
There is lots more to come; specifically around Anaerobic TISS,
looking again at polarised training and personalised training stress
based upon the individual's CP model.
You can now compare seasons / date ranges across or between
athletes on the LTM charts.
This is only shown on the stack chart as we need one chart
per data series - in a similar vein to the AllPlot chart.
There are some tidy ups left to do over the next few days;
- Data table needs updating to support compare mode
- Event markers need to be shown and in the right color
- PMC curve data is slow, needs some kind of optimisation
- The tooltip is missing and needs to be put back
- Ensure the new stack frame looks correct when using a
dark plot background (or anything other than white)
- Consider how to handle zooming when there is only one
data series and hence only one chart for compare
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
.. warnings from Xcode 4.6 (still some remaining)
.. and deprecated Quarqd code (we have native ANT now)
.. and MultiWindow deprecated (it isn't finished)
The code setting metric names and units was moved from constructors to
an initialize method, to be called after translator initialization.
English Name is preserved as InternalName for metadata.xlm compatibility
in metric override.
Q_DECLARE_TR_FUNCTIONS(class-name) macro is used to set tr() context
when class-name is not QObject sub-class.
When calculating TSS, BikeScore et al the user can
set a ride specific value for CP to override the
default zones set within configuration (power.zones).
This is because some users like to have a different CP
for indoor vs outdoor riding.
To use this the user will need to add an "CP" metadata
field and only enter a value when they want to override,
since by default it will be zero, causing the standard
zone CP to be used.
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.
A user configurable chart for showing ride metrics and
other calculated values over time.
* Uses SQLITE database to store metrics
* Supports any metric available from the metric factory
* Adds new MaxHr, VI, Peak Power and Time In Zone metric
* Also includes LTS/STS/SB for PM charting
* Aggregates in days, weeks, months or years
* Reads and Updates seasons.xml
* Adds cycles and adhoc date ranges in seasons.xml
* Date ranges can be selected on the plot with shift-left click
* Allows users to customise preferences for color, symbols et al
* Allows user to customise metric names and unit names
* Supports smooth curves and topN highlighting
* Has a linear regress trend line function
* Allows users to save charts to charts.xml
* A default charts.xml is built-in
* A chart manager to import/export/rename/delete charts etc
* Provides a tooltip to provide basic datapoint information
* Performance Manager adjusted to use the MetricDB
* User configurable setting for SB calculation (today/tomorrow)
The symbol of a ride metric is the string by which we refer to it in the
code, configuration files, and caches (like stress.cache). It should not
be translated, and it should never be shown to the user.
This commit allows every ride file to specify a set of "metric overrides":
values to use in place of those for RideMetrics we would otherwise compute.
The most gratifying immediate result of this change is that we can associate a
"skiba_bike_score" metric override with each Manual CSV file, thereby
eliminating the need for a bogus "bs" parameter in RideFilePoint.
In the future, though, we can also save these overrides to a GcRideFile using
a syntax something like this:
<override>
<metric name="skiba_bike_score" value="100"/>
<metric name="average_speed" secs="3600" km="30"/>
</override>
(Note that average_speed needs to store time and distance in order to
aggregate properly.)
Then we can add a dialog that allows the user to override the computed value
of a metric for any given ride. For example, if my HRM was on the fritz
during a ride, I could estimate my average HR and override that metric.
(We might want to show these overrided metrics in a different color, so that
it was clear they weren't the computed values.)
Finally, I think we could actually use this feature to eliminate the Manual
CSV format altogether, and just use GcRideFiles without any samples or
intervals, but with metric overrides for all the available metrics.
Commit 420b2b6 introduced a bug whereby it used the total workout time,
rather than the time riding, to compute xPower. This should only affect
your data if you take long breaks during rides, like to stop for brunch,
or if you store multiple rides in the same ride file--i.e., you don't
use the split ride feature. Nonetheless, it's worth deleting your
stress.cache file after applying this commit, just in case.
I've also added three rides, notes, and a zones file to the test directory to
illustrate the differences discussed above. The first ride is just an hour at
CP/FTP. It should have a BikeScore of very close to 100, and Daniels Points
very close to 33. The next ride is the same as the first, but followed by 20
minutes of coasting. Its Daniels Points should be the same as the former,
but its BikeScore should be a good bit higher. The final ride is the same as
the first, but interrupted partway through by 30 minutes of no riding at all,
as though the cyclist stopped for coffee and a pastry. It should have
nearly identical BikeScore and Daniels Points to the first ride. In the
broken implementation of xPower that this commit fixes, it did not.
Dan C: I reverted your changes to the xPower calculation in this commit and
went back to my implementation. It's just easier for me to think about the
code that way. My apologies. I kept the other changes you made, though.
