... more tr() changes
... added comparison for both "seconds" OR tr("seconds") to all other
occurences found
... added "Lap" text for Intervalls imported in Garmin FIT format (this
is what Garmin delivers)
(cherry picked from commit ad790f05a386e3ae5c5b9dc129a216ac451b8cfc)
.. 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.
There still some assert left in the code, but removed
a fair number of the examples where, its just as easy
to handle the condition gracefully, without crashing.
By 3.1 we will have eradicated assert from the code.
All are harmless but for the sake of clarity have
fixed them all bar a couple;
- Lucene grumbles about signed/unsigned conversion which
is/isn't valid depending upon the version of CLucene you
compile with. Either way it is harmless.
- QxtScheduleView has a bunch of issues, but since it is a
third party widget its better to leave it unchanged.
Fit ride file contains samples where the distance
is set to zero, even if the previous sample is
non-zero.
The parser has been adjusted to keep the previous
distance used when a zero value is encountered.
Fixes#544.
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.
The header size in FitRideFile has increased from
12 to 14 bytes, but the new field is at the end of
the header, not in the middle.
Additionally, there is a new global record (79) which
we now silently ignore.
Fit file format can now have a 12 and 14 byte header. This
patch adds support for 14 byte headers since this is required
by the latest 310xt firmware.
Fixes#430.
FIT record type '253' occasionally causes time to go
backwards, this might be a decoding error, but for now
we force time to go forward anyway.
Looking at bad files GPS data with this patch suggests
this is the correct behaviour.
Fixes#104.
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.
So far the FIT parser bailed out, whenever it found something
unknown/uninterested to GC. This is quite orthogonal to the FIT design, as
it's supposed to be extended.
renamed read_<foo> functions to match the FIT base_type names.
unified handling of "unavailable/invalid" values - i.e. if sensor data is
temporary unavailable. This allows easier and consistent handling -
especially for the uintXz base_types, which only differ by a different
"invalid" value. Had to change the type of the "values" list to int64 to
fit uint32/int32, as well.
added proper support for signed integer types. I'm wondering, why lon, lat
+ temperature were decoded properly...
added support for currently unsupported base types by just skipping their
bytes. This allows us to continue reading.
... on both, big and little endian machines.
Fit reader only supported little endian data on little endian machines.
All values read from FIT files are now swapped (if neccessary) according
to file and system endianess.
fixes#287
do not bail out on unknown message types. This violates the design of the
Fit format of being extensible.
As this was the last thing using the global_msg_names QMap, I've nuked
this, aswell.
1. Allow FIT reader to recognise the file comes from a Garmin Edge 800
This is Garmin product ID 1169 in the decodeFileId routine.
2. Ignore global_msg_type = 72
This message appeared with the introduction of the Garmin Edge 800.
There is no FIT SDK that tells us what this message is.
It appears only once and has timestamp/device serial number.
Code now recognises the msg_type as valid but we don't process it.
3. Add all decodeEvent types and work only with "timer" events
Not all event_types were present. They are now all in the function.
Previously the decodeEvent would look at all "events"
We now only decode event_types if the event is of type "timer".
Fixes: #250
The FIT parser will attempt to interpolate data when filling in for smart
recording or if a record is missed. A problem occurs if one of the lat/long
points is missing or 0,0.
This patch will record a 0,0 lat,long if the record is missing in the FIT
file and when interpolating, will set any interpolated data points to 0,0
if the start or end record is also 0,0.
A 0,0 record is not plotted on the MAP tab.
Fixes#111
