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.
If you attempt to download from a Macro device
and use wrong device or initial read fails then
it crashes, this patch fixes that.
It does not fix more general data errors but should
at least mean incorrect user selections do not result
in GC crashing.
Fixes#366.
The ride import wizard would only allow the user to
change the ride date/time if it was a .gc .json or
.csv file. This was (wrongly) because we could not
update the date/time defined within the ride file itself
(we cannot write in other formats e.g. wko).
Of course, we encode the ride date/time in the filename
and so it could be changed. However, not all the RideFile
readers supported this.
To get around this, the import wizard now does let you
change the date and time for any file type and the ride
file factory method openRideFile() will override whatever
date and time is returned by examining the filename. The
user needs to double click the date or time to edit it.
Additionally, the select date... combo would only register
when you changed the selection, it now defaults back to
the 'select date..' option after each selection.
Lastly, the 'choose date' function now works as advertised
and triggers editing the date for the ride selected.
[commit cd86521 cherry picked into master from release_3.0.0dev]
Fixes#11
Patch to allow v2.1 to read v3.1 .json ridefiles.
Version 3 introduces a new GC file format
using Javascript object notation (json). In
version 3 files are written in this format
as a local, native format thus deprecating the
XML .gc notation.
This backport to 2.1 does not;
* write in json format, it just reads files
* set RideFile::rideId, since it is not present in v2
To build you will need lex/yacc (or flex/bison) the
instructions are within gcconfig.pri.in but are the
same as for version 3.
Fixes#395.
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.
The LogY function for histograms was overlooked
when implementing intervals. The baseline and
start/end values of the interval curve needed to
be set to non-zero values to match the main curve.
Fixes#396.
When a large number of intervals are defined (>50 or so)
then the RideSummary window crashes.
It appears to be a bug in QTextEdit. It does a double free
when setHtml is called, after a 'large' text item was
set. It may be a QString bug.
To avoid the issue we use a QWebView instead of a QTextEdit
to display the summary and then try and set fonts to match
the application.
[cherry-picked and merged from release_3.0.0dev]
If you save a ride and then delete it. The re-import and save
you will end up with two copies of the ride in the ride list.
This is because when we save the first time the original file
is renamed to e.g. ride.tcx.bak and the new ride.json is then
created. All is well.
But then delete the ride and it will rename ride.json to
ride.json.bak. Again, All is well.
Now, re-import the ride. We now have; ride.tcx.bak and
ride.json.bak and ride.tcx. Again, all is well.
But now, if you make changes and save it will attempt to
rename ride.tcx to ride.tcx.bak AND FAIL. This is because
the old ride.tcx.bak file is there. It will then create
ride.json. All is NOT well, since we have two rides with
the same date and time but different extensions.
This patch fixes this by unlinking ride.ext.bak before
trying to rename the file.
[folded in manually from commit #1d135a in branch release_3.0.0dev]
Some ride file formats use -1 to indicate sensor not
present or data loss (e.g. TPX) and on occasion a NaN
or Infinite value will be presented.
This patch handles this by converting negative data sample
values to zero and handling out of bounds values when
selecting zone ranges.
This is not a substitute for better handling of poor ride
data but it reduces the effect.
Also fixes#311.
The find dialog expected the between values
to be small and high, this patch will find
values between regardless of whether the
search values are lo/hi or hi/lo.
Fixes#351.
The recent patch to allow users to configure which
metrics to display on the ride summary window is not
forwards compatible. If metrics referenced no longer
exist (i.e. they are from a future release or have
been deprecated) GC will crash.
There is no need to warn about seasons.xml missing, it
is quite acceptable to have none set. Worse still sending
to the console log is next to useless for users that
don't launch from the command line.
Partial cherry pick from 4972f2472e (v3.0.0dev)
The WKO+ file format appears to record drops in
recording of GPS data with a latlon of 180,180. We
expect this to be 0,0.
This makes the WKO+ file reader consistent with the
GoogleMapControl and removes the need to clean data
there.
If it is found that 180,180 is the standard way of
recording drops in GPS signal then we can change the
code. We use 0,0 since it is conveniently at sea off
the west coast of Africa.
Cherry pick d06c9e97c9 (From v3.0.0dev)
reading Fit files with Smart recording and a certain pattern of timestamps
could cause assertions. This shouldn't happen, as it's no Programming error.
Changed the checks into graceful failures.
Unfortunatly I don't have any files to test this.
fixes#364
reading unsupported SRM files caused assertions. This shouldn't happen, as
it's no Programming error.
Changed the checks into graceful failures.
fixes#364
With realtime data there will often be samples with
timestamps like 940.002 and 940.998. This cuases an
issue on the ride plot, where it believes there is
no sample for 941 and therefore plots a zero value.
This patch rounds the timestamps to the nearest 100th
of a second, which is consistent with the mechanism
used in the ride editor.
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.
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.
