.. 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.
Especially for Vectors new metrics
- Left and Righ Platform Center Offset - eg: -8mm and -11mm
- Left and Right Top dead Center - eg: 10° and 11°
- Left and Right Bottom dead Center - eg: 203° and 210°
- Left and Right Peak Power Phase Start - eg: 83° and 76°
- Left and Right Peak Power Phase End - eg: 115° and 125°
datacnt is 16bits so it overflows easily for large files (9 hours with
0.5sec recint).
I've also seen datacnt and block sum to be inconsistent in other cases.
To handle this more graceful, we're now taking the max of both counts and
let the EOF detection do it's job when one of them is wrong.
We do have to use one of these limits as some SRM files have junk after
their last chunk (so, just reading chunks till we get EOF retunrs this
junk, too).
code was blindly trusting datacnt... and kept reading past EOF. That's bad
as datacnt occasionally isn't matching the available data (overflow,
corruption, ...)
"secs" is miscalculated for gaps between blocks: It takes the delta
between last chunks *END*time and next chunks start time - and thereby is
off by RecInt. This error adds up for each block/gap - so, the n'th block
will by off by n seconds.
fixes issue #582.
.. Added the torque effectiveness and pedal smoothness
data series to the RideFile structures.
.. The only file formats that support it at this stage
are Fit and GoldenCheetah JSON.
.. As more file formats support it we will add it here.
.. The charts/editor now need to be updated to support
these new data series.
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.
GTC will export all rides as a single TCX file so they
can be imported en-masse into another application.
We did not support >1 rides in a single ride file. This
patch adds support for reading multiple rides (if the ride
file reader supports it).
The ride import wizard will now extract and parse files from
a GTC export. Many thanks to Damien for writing the TCX file writer.
Fixes#371.
reading unsupported SRM files caused assertions. This shouldn't happen, as
it's no Programming error.
Changed the checks into graceful failures.
fixes#364
seems, the assumption for "speed" in SRM7 files being unsigned was wrong.
Powercontrol/SRMWIN seem to use negative speed as "invalid".
Furthermore altitude may become negative, as well.
To address this, QDataStream now does the bit-swapping and speed +
altitude are read as signed values.
Fixes 346.
SRM5 basically is the same as SRM6, but lacks "blocks". This means, it
only has the date of the exercise and no further absolute time info.
Furthermore it can't flag periods of time, where no data was collected.
Due to lack of absolute time, Exercises start at 0:00, by default.
Fixes#208
While the last patch for misaligned SRM Intervals did fix the out of
bounds indices (and thereby fixed the crash), it got the start/end
swapping wrong. In other words: It swapped start/end where it shouldn't
and therefore broke all interval handling.
in certain circumstances srmwin seems to (have?) written bad files: The
first/last data chunks referenced by a marker were swapped plus the "real"
start index was 0 - although chunks are counted from 1.
This patch checks for this defect and interprets the data in the same way
as recent srmwin versions do when reading files with this defect.
Though the way marker are stored in PCV makes me guess, the refernce the
bad chunk index 0 really means "last" chunk in the recording.
SrmRideFile was setting RideFilePoint::interval correctly for
each RideFilePoint, but it was setting the start and stop of each
RideFileInterval it created to 1 RideFilePoint later than they
should be. This patch fixes things so that RideFilePoint::interval
and RideFileInterval::start|stop agree about the interval bounds.
Added a headwind data field, which is available when using
an iAero head unit, to dramatically improve the calculation
of Chung analysis for users of more recent iAero devices.
All other data files than the iAero have the headwind term set to
zero when they append a point.
If the user forgot to end an interval before downloading a ride, GC
would crash due to an assertion failure. The included ride file
demonstrates the bug.
RideFile data points now include lon and lat members for the longitude
degrees and latitute degrees from the source ride files. As a result
most of the RideFile readers now set longitude and latitude to zero for
each data point, except for:
* Gc Format Files - now support read/write
* Wko Format Files - now support read
* Tcx Format Files - now support read (smoothed if smart recording)
Although there are no features within GC at this point in time that use
positioning data this may change over time. Critically, as users save
files to the new GC file format whilst adding interval data it is
important that this positioning data is not discarded before new
features arrive.
