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.
fopen() was missing 'b' flag, so that mingw and other platforms doing
LF/CR translation screwed data.
This is fixing the astronomic values of direct SRM downloads.
Because the chart settings are modal its a really bad
idea to open up a column chooser from there. So, by
default, we don't have a column chooser option on the
search/filter box -- it must be explicitly requested.
We therefore explicity set the column chooser from the
mainwindow and also from the ride navigator window.
At first it seemed this was caused by setting the time to
a value greater than the length if the ridefile.
It was actually a constructor error, since the settings
class didn't initialise the ride variable.
Ridesummarywindow was using rideitem to get zones to use when
summarising for a date range which was bad because a) the ride
might not be for the date range selected and b) it might have
been deleted.
This fixes that and means we get a summary that is more accurate
and no crashing when rides are deleted.
If you delete and readd an activity after showing it on
the diary view you get a SEGV.
This is an edge case related to deleting the last activity
and going back to the blank state before importing another.
Actually there are 3 technical issues;
1. GcCalendar doesn't get notified by MainWindow when
there are no rides -- so it crashes on refresh
2. RideSummaryWindow doesn't get notified by home window
if its not visible
3. RideSummaryWindow should check rideItem isn't NULL before
trying to plot zones (but only for date range summaries)
Fixes#622
