Read running power data about activitylog2 HOT 6 OPEN

Data from third party IQ fields should already be supported (#27). Have you tried importing an activity with Running power data? You might have to use "Select Data Series" to select the Stryd specific data. These data series are also available for the Histogram, Scatter and MMAX view, as well as in Trend Charts (you should even be able to estimate CP for running).

Note that all IQ data series have "XData" prepended to their name, so you should be able to easily identify them.

Normally, things should just work, but occasionally, some fields are poorly defined and graphs look wrong, so there is a xdata-defs.json file to define some parameters for it, this is explained in https://github.com/alex-hhh/ActivityLog2/blob/master/docs/xdata.md. However, Stryd should already be supported.

I don't use this functionality myself, so there might be missing features or defects, let me know if you find any.

from activitylog2.

Ah indeed, I can see them in the charts and trends.

I guess it is only that in the Activities summary the VOSC / GCT / Power / Max Power / Weighted Power columns are empty, and I guess the data for them will need to be connected to the XData series. I couldn't understand if the xdata-defs.json definitions can be related to the table columns on the Activities tab.

from activitylog2.

Summary values are not displayed in the activities tab, or in the lap view for an activity -- this is missing functionality. The summary values for an entire activity will be displayed in the overview tab, but only if the IQ application is calculating them.

Also, I decided to keep the XData measurements separated for now, so VOSC from Stryd will be a different data series than VOSC from the main Garmin unit and you won't be able to mix them in the summary trend charts.

The remaining todo items for XDATA is listed in this project https://github.com/alex-hhh/ActivityLog2/projects/1, but last I worked on these was two years ago...

from activitylog2.

I couldn't understand if the xdata-defs.json definitions can be related to the table columns on the Activities tab.

They are not. The xdata-defx.json allows defining what the data series are named and how data aggregation is done when filtering or grouping values for histograms, etc.

from activitylog2.

True, it would make sense to keep them separated as the power metrics from Stryd are likely different from Garmin or another sensor and hence not directly comparable. These are the data from Stryd btw:

I think for summarizing it's fine to calculate average if the IQ app didn't calculate aggregation; eventually customizing this could be supported through the json config as well.

from activitylog2.

There are several challenges with calculating summary values, and the functionality requires some careful design. I will try to summarize the issues below (sorry about being a bit long):

• Data in the Activities Tab comes directly from the database. Average values (e.g. average speed) are not calculated, but read directly. It would not be possible to calculate such aggregate values using SQL queries, due to potentially bad data, calculating them in the code would make things very slow.

• Data in the Activities Tab comes from the V_ACTIVITY_LIST view, which has a fixed number of columns which have all the parameters that can be displayed (the filter is only for rows, that is the activities). This is a limitation, and I am not against changing it, but it is not immediately clear how to do it while maintaining performance.

• Aggregate data values would need to be stored in the database (there is currently no schema for that), and calculated somehow. Calculating them on import is good, but you might already have some already imported activities and the data would have to be calculated for them as well.

• ActivityLog2 does now know about the nature of the XDATA, and I would like to keep it that way (i.e. it does not know about the Stryd in particular). Any changes would have to be generic.

  It is unclear if an "average" or "max" value would always make sense. For example, there is a W'Bal IQ application, which tracks W' depletion during an activity, but the average value for that metric is meaningless. What's more, even the maximum does not make sense, for W'Bal the important aggregate would be the minimum.

  Even calculating "average" is problematic: do you average on time or on distance? If you average on time do you go for moving time (excluding stops) or "clock" time to include stopping time -- some values make more sense on one, some on other.

In the end, my preferred solution is what I suggested in this comment:

• introduce a mechanism to calculate values for segments of an activity (one such segment could be the entire activity, other segments could be the laps. Users should be able to define their own aggregates

• add a database schema to store these values (and code to manage this).

• define aggregates for IQ applications (e.g. by extending fit-defs.json), so users don't have to define their own for common applications.

• implement a mechanism to display these values where it is appropriate in the GUI.

This is a lot of work, and I currently have no time to tackle it. For your purposes, a simple solution would be to just calculate these as I suggested for the TRIMP score and display them in the overview tab.

from activitylog2.