search

davidzof / wattzap

2 stars 3 forks source link

Readers as telemetry providers #2

Open pajakgdynia opened 9 years ago

pajakgdynia commented 9 years ago

New class hierarchy to handle training files with different data provided (.GPX, .RLV, .TRN). These "Readers" shall be consumers of Telemetry and provides all the necessary data.

pajakgdynia commented 9 years ago

Hmm. It looks that points in general reader are wrong way.. Cycleops needs two lists, both shall be checked: first one for distance/position/altitude, second one for video time/speed. For POWER profiles.. there isn't distance at all (and videoSpeed as well). TCX files can have totally different sets of data

And what about showing distance/speed in ODO during POWER trainigs? Just for fun? Wheel speed ok (usefull when simulSpeed mode is selected)..

pajakgdynia commented 9 years ago

TRN files must be handled as a reader. It must handle "too big" and "too small" properties of values (on data availability).

Each "reader" has own data, these are not a part of the interface. Some of them must be "left" (max/min Slope: used by simulSpeed), some other are taken from profile data (routeDistance). All "wrong" (in my opinion) are marked as deprecated. Whole behavior of "TIME" (previously "POWER") training must be built, all rules created. Profile panel must handle two formats: distance and time. Video shall have constant speed ("TIME") or power related ("DISTANCE"). In "TIME" mode audio might stay not muted (config flag). ODO panel for "TIME" shall show position as a time (taken from routeTime), speed shall not be available. These shall be set when speed is not available. It must be correctly handled in telemetry provider, too.

pajakgdynia commented 9 years ago

Hmm. It looks pretty easy. TRN is done. Some small issues with ODO (instead "Distance" field "Time" shall be shown) and Profile (number of seconds instead of time). I'm hardly wait for RLV to refactor it.