Intervals are off by 1 sample because when the temporary
ride is created it stops short of the last sample in both
the ride and interval summary window code.
Fixes#623.
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
[cherry-picked from master cc2a0efe3e]
Kernel 3.11 exposes the Suunto ANT+ stick as a USB serial device,
this prevents GC from opening it in training mode unless the
kernel driver is detached first.
Only detach kernel driver if compiling under Linux (not a portable function)..
In training mode, calculations of speed using wheel size and RPM from
a speed sensor used integer division. This truncated all wheel
circumferences to an integral number of meters. 2100mm wheels were
treated as 2 meters and 1960mm wheels were treated as 1 meter,
effectively reducing calculated speeds by roughly 5% and 50%
respectively.
Fixes#585Fixes#651Fixes#669
Including:
* Fixed a type with slope mode updating the wrong byte array
* Transposed bytes in the definition of the erg and slope messages
* Added power smoothing
Note:
It appears the Fortius is supplying torque not power, some more
testing is being performed but expect to see an update shortly
once this has been fully tested.
as current tcx writer currently doesn't support laps (and tcx doesn't
allow non-linear/overlapping intervals, at all) this patch makes GC upload
exercises as pwx.
Pwx does support for arbitrary sample lengths. No need to chop off
timestamp precision and introduce bad data + jitter.
Instead we should look at fixing data import and consider resampling on
read.
Distance is defined as double, aswell - so, let's keep the precision,
aswell.
As I got it pwx by itself has no concept of recording intervals. "smart
recording" and other strange data require variable recoring intervals.
On the other hand it's not recording the duration of a sample explicitly.
This means the duration needs to be derived from the previous samples
timestamp (assuming the sample timestamps are referring to the end of the
sampled period).
This diff writes an empty timestamp at the end of each gap so that the
next real sample/ridepoint can calculate the correct duration.
Please note that this may unhide some deficiencies in GCs file reading in
exports.
When exporting files to Tcx, it's writing an ActivityExtension to the end
of the file with calculated AvgSpeed and MaxSpeed. Unfortunatly it's using
the km/h values - while Tcx is using m/sec. Schema is a bit unclear about
this, as the ActivityExtension uses "double" as type for both values, but
original Tcx v2 Schema only uses m/sec, GTC exports as m/sec and some
other software is expecting m/sec, aswell.
