This is the Same fix applied to the Computrainer a few months ago to remove the modal dialog that would be issued in a loop upon connection problems. The modal dialog loop made the interface completely unusable. Now a notification is emitted but the interface remains available.
Similar to other DPs, it is what the users expect and it is easier
to try with different parameters.
When called automatically existing watts are preserved
to avoid accidental overwrite.
More recent first intended to avoid the need to scroll to the end
Fingerprint changed to include time to detect changes when adding
more than one on the same day.
Fix inconsistent use of local/UTC dates.
.. MacOS Qt crashes when destroying it, OpenGL is *that*
broken by Apple.
.. applied to Windows too, despite it not being an issue
reported there is no value in doing it so removed.
[publish binaries]
.. saves/loads values to athlete global area, particularly useful when
modelling as you can save away parameter estimates that may have
been expensive to compute, and re-use them across series in a
user chart.
.. they are not saved across restarts, but we could fix that later if
they become more useful
.. store("name", value) and fetch("name"). if the named value does
not exist 0 is returned.
[publish binaries]
Fix the slope and power values in the Fortius Slope mode
Users have complained about incorrect slope and power values for the Fortius. This was due to a few problems. This commit greatly improves the situation with the fixes that solve the following problems:
- The Fortius protocol is better documented in the comments.
- The pedal sensor is on byte 42, not 46, this prevented the pedal sensor echo to keep the trainer operating normally.
- The slope was converted to uint before being scaled, losing the fraction.
- The trainer most likely reports the torque. It must be multiplied by the speed to get the power.
- The scaling factor for the slope was 2x too high but this did not show earlier because of the pedal sensor problem.
- The period for retrieving data was too fast, most packets were empty, the period was changed from 10ms to 50ms (Tacx software uses 100ms).
GoldenCheetah is now quite usable on my Fortius with those changes. The slope appears too easy and the power overestimated but this is similar to the behavior of this trainer with the Tacx software. It would be interesting to get feedback from users with powermeters to refine some of the coefficients involved.
.. MacOS support for OpenGL is unreliable and there are user reports
of issues. We will need to wait till Qt 6 for hardware acceleration
on Metal.
.. Windows support for OpenGL is ok if you use Nvidia GPUs but the
AMD OpenGL driver is slow and broken. So we disable OpenGL here
although Nvidia users are potentially being short changed.
.. Hardware rendering really needs to wait for Qt6 for a more complete
and reliable implementation that has cross platform support.
Fixes#3594
.. the concept of a new gui as a replacement for MainWindow was dropped
in preference for gradually adjusting MainWindow to the new design.
.. this is still in progress, but the 'newgui' concept is dead.
.. Fetch the version of OpenGL available at startup and use it in
ChartSpace to decide if we want to enable openGL rendering.
.. some fixups for X11 builds, which are not needed on the main
OS combinations we use (Linux, Mac, Windows) but may prove
useful when building for X11 vs Wayland in the future
The weight has a direct impact on how fast you climb for a given power.
Other parameters like the wind resistance and the rolling resistance do
not change as much but should still be communicated to devices which can
take them into account. All the needed values were already present in
the BicycleSim and DeviceConfiguration modules. It is simply a matter of
communicating those values in the RealtimeController interface, just like
the gradient.
