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.
.. simplified acceleration calculation to convert to m/s before calculation
.. removed distribution for deltas as they were HUGE and introduced a
terrible performance degradation where aggregation took >30s for a
ride set that previously took <5s.
.. Following on from the recent update to add acceleration
this update adds other derived data series based upon the
rate of change.
.. Added to the ride plot and the CP plot.
Not sure of the overall utility of these updates but bear in
mind that they are targetting sprinting and track users and
analysis.
As well as the positive side of this (development of power
cadence etc) we also want to think about and collect data
on fatigue rate (possibly only power and torque)
- fatigue over time
- fatigue over pedal stroke
.. As you mouse over the ride plot it will now highlight
the shortest interval that that point is within.
.. If an interval has been selected in the sidebar it will
refrain from hover highlighting as it is distracting
.. Also fixed up the way the highlight curve works so it
has its own axis and works regardless of the data series
selected.
.. on ride plot, when W'bal is plotted we put a mesage to say
that CP is wrong, and autosolve for W'bal to zero.
.. this patch also optimises WPrime to make it a member of the
ridefile class and this always available (even for intervals).
.. fixed a SEGV when computing metrics for intervals by shifting
the timestamps to always start from zero.
The 4 views have been shown to be confusing -- it is not clear
to new users what their purpose is, and hence how or why they
are different.
So in an effort to reduce the confusion I've renamed a few
things to be much more explicit and specific.
.. We embrace the fact we are a cycling program and use the term
RIDES not ACTIVITIES for all files
.. HOME is confusing, renamed to TRENDS
.. the ANALYSIS view name is confusing, its all about ANALYSIS
to renamed to RIDES
There will no doubt be areas that are not renamed properly we
can fix those when the arise.
Porting the codebase to QT 5 (5.2) to get the
latest bug fixes, performance and improved platform
support.
This first part is to fixup the codebase to compile
on Qt 5, but some aspects have been broken (video).
The second part is to migrate from Qwt 6.0.1 to the
latest Qwt for multiaxis support.
The third part will be to fixup any platform specific
issues or issues identified at runtime.
.. you can now choose to remove reference lines in the
allplot when you double click on the axis.
.. we might want to put the table and buttons for deleting
references into the chart settings too (?)
You can now plot NP, xPower and aPower on the
ride plot.
This has been done to provide transparency &
insight into the relationship between the derived
values and the recorded power values,
Peak aPower durations now computed and cached;
* updated RideFileCache to work with aPower
* CP curve now allows you to plot aPower
* LTM plot allows you to plot aPower peaks
* DataFilter allows 'best(apower, duration)' function
Added comment in ridefile.cpp to reference the book
and research paper that aPower is based upon:
// Calculate derived data series, including a new metric aPower
// aPower is based upon the models and research presented in
// "Altitude training and Athletic Performance" by Randall L. Wilber
// and Peronnet et al. (1991): Peronnet, F., G. Thibault, and D.L. Cousineau 1991.
// "A theoretical analisys of the effect of altitude on running
// performance." Journal of Applied Physiology 70:399-404
Added an average aPower metric.
I also and found and fixed a couple of bugs along the way;
* intervals create a ridefile and need to explicitly call
recalculateDerivedMetrics()
* the aPower calculation was using the calculated vo2max
percentage the wrong way around (!)
Introduce altitude adjusted power 'aPower'.
This is a new ride data series that takes into account
the effect of altitude on power output.
At present we are only adding this as a derived data series
with the intention of making it possible to plot it on
the ride chart.
We will also introduce alternate metrics for average power,
bikescore etc that are based upon the aPower value.
Calculate NP and xPower as a data series so we can
plot on the ride plot.
Have also added 'aPower' which will be coming in the
next few days - altitude adjusted power, which will also
have some associated metrics (a-xPower, a-NP, a-TSS etc).
We know the highesst point on Earth, so any activity that
contains an altitude greater than that is definitely incorrect.
This patch truncates the altitude to the maximum possible, this
has the happy by product of curing a major mem alloc crash in QWT
when trying to plot altitudes with very large values.
Fixes#700
Slowly migrating code and data from the MainWindow
class to Athlete and Context classes.
This update moves the ride and interval lists and
data structures from MainWindow to Athlete.
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
Breaking the MainWindow 'god object' into
separate classes for Athlete and Context.
Further updates will need to;
- 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
Once these are done we will be in a position to decouple
most classes from mainwindow and also introduce tabbed
athletes.
.. the RideFile::data member is used by the ride editor and was deleted
when a ridfefile is deleted, but we have no way of telling the editor.
.. now doesn't delete, which is a small memory leak.
Fixed up the code to use withings weight when calculating watts
per kilogram and the display on the CP chart.
There will be issues when retrospectively refreshing data from a
withings account, but that is such an edge case we can just ask
people to delete old .cpx files to ensure they are refreshed.
This patch adds support for temperature and slope
across the ridefile readers.
For the most part their is no functional change
although it is now possible to view and edit these
data series in the editor.
File formats that can provide temp or slope include;
.bin, .fit, .srm, .sync, .wko
Further updates will be required to display the data
in the ride plot and histograms.
Return value when out of bounds had a fencepost error. Annoyingly
it is exactly the same fencepost error that was fixed in a line
of code 10 lines lower in the source.
This fixes rare issues with rides where intervals start at the
end of the ride file. This can happen with rides that have been
split.
Added support for.fitlog file format. The reader
was written by Mark Liversedge and the writer
was written by Damien Grauser.
There is no support for manual workout files (either
exporting or importing) this can be introduced at a
later date.
SportTracks does not export speed or distance if GPS
data is available. Speed and Distance are derived from
GPS and time. This is sub-optimal and may result in
differrent values between GC and ST.
I would recommend using a common file format to exchange
data between GC and ST (e.g. TCX) to avoid these issues
with their native file format.
Fixes#481.
The export functions in mainwindow are getting quite
cumbersome with multiple menu options.
This patch creates a single menu option "Export.." which
allows the user to select a supported format and a filename.
To support this the ridefile reader code needed to be adjusted
to allow registered readers to declare capability to write and
use a consistent (virtual) method to do so.
By modifying the base class for ride file reader we now allow
new readers to register both read and write capability.
Updates to the version 3 split activity wizard to bring it
back in line with the original v2 functionality;
* Splits at markers, rather than extracting intervals
* Shows a small plot to show the split visually
* Will automatically mark gaps rather than work between gaps
This will not be backported to v2 since the functionality
is working, albeit difficult to understand for this casual user.
A popup bubble when hovering over the activity
history or an entry on the calendar.
It is a pre-cursor for the activity bar for
selecting rides and is available for any
widget to call (it is a member of mainwindow).
To support the data series indicator icons a
new metadata field 'Data' has been added to
store a string to represent the data series
that are present.
In addition, the Sport code is used to decide
if a bike/run/swim icon should be shown instead
of a string (but needs translation support when
we get round to that).
Lastly, it has been coded for horizontal alignment
but will need to be updated for the activity bar
to support vertical alignment.
This is an experimental feature and will develop
over time, specifically;
* you cannot define which metrics are show in the
bubble -- they are hardcoded at present
* the coloring is hardcoded, as is the font size
* Only the activity list and diary use it.
Very basic start, this will now let you plot
VAM on the CP curve. VAM is a measure of climbing
speed and for comparative purposes should be
normalised to the slope climbed.
In this first pass of implementation the VAM metric
is not normalised in any way. It merely represents
the climbing rate, in meters per hour, that was
sustained over each time interval from 5mins to the
ride duration.
If the ride is undulating then only ascension is
included, any time on the flat or descending is
included but meters climbed will be zero. This is
akin to the way we handle power where we include time
when freewheeling.
More sophistication is needed, especially normalising
the value to a common gradient (e.g. 10%). But this
will prove challenging when VAM is comprised of
undulating elements (i.e. gradient is cumulatively
zero, but could contain segments with steep parts).
It may be more appropriate to only measure VAM for
sustained climbing i.e. ignore ride sections when
descending or on the flat.
More thought needed.
Fixes#414.
