Non-standard activity types breaks TriScore Calculation (GC 3.5, Build 3991)

[Track Smart]

Hi Folks,

Here's what I've found: If I add an activity to Golden Cheetah that is *not* Run or Bike or Swim, this seems to break the TriScore calculation.  For instance, a mostly Zone 1 (heart rate) hike at 2.2 MPH will yield a TriScore of 220!  This messes up all of my metrics.  If I change the activity to "run", I'll get a much more realistic TriScore value of 21 (one-tenth of the previous value).  

Questions:

1) How is Golden Cheetah making this TriScore calculation on "Hike" and "Walk" and other non-standard activity types?  It seems to be ignoring heart rate (which was very low).  And it doesn't seem to be based on pace (just 2.2 MPH for that last hike).  

2) Is there a fix I can enable?  My current work-around is coding all hikes and walks as "Run" for the activity type.  But its annoying to manually do this.  It also makes sorting by activity type problematic (i.e. hikes are mixed with runs).

Thanks for any insight that folks can provide!  I'm running v3.5 (not the new development builds).

[Ale Martinez]

El lunes, 25 de julio de 2022 a la(s) 04:19:46 UTC-3, track...@gmail.com escribió:

Hi Folks,

Here's what I've found: If I add an activity to Golden Cheetah that is *not* Run or Bike or Swim, this seems to break the TriScore calculation.  For instance, a mostly Zone 1 (heart rate) hike at 2.2 MPH will yield a TriScore of 220!  This messes up all of my metrics.  If I change the activity to "run", I'll get a much more realistic TriScore value of 21 (one-tenth of the previous value).  

Questions:

1) How is Golden Cheetah making this TriScore calculation on "Hike" and "Walk" and other non-standard activity types?  It seems to be ignoring heart rate (which was very low).  And it doesn't seem to be based on pace (just 2.2 MPH for that last hike).  

IIRC there’s a bug in v3.5 fixed in v3.6 which allows a bogus BikeScore value be used in these cases, you can force BikeScore to 0 for the activity in Details > Metrics so TRIMP Zonal points are used for TriScore.

2) Is there a fix I can enable?  My current work-around is coding all hikes and walks as "Run" for the activity type.  But its annoying to manually do this.  It also makes sorting by activity type problematic (i.e. hikes are mixed with runs).

You can setup a filter in your PMC chart to avoid activities other than Swim, Bike and Run. 

[Track Smart]

Hi Ale,

Thanks so much for the reply!  Somehow my notification for your answer ended up in spam.  Gmail doesn't understand when Google itself is sending an email!  Doh!  

I've been hesitating to jump to version 3.6, since it is still listed as a development release, but I might give the hopefully quite stable "Development Release" a try and see if that fixes this problem (and doesn't break anything else).  If that fails, I'll try your workaround (set Bikescore to Zero and see if TRIMP Zonal gets used in calculating TriScore). Thanks again!

[Track Smart]

PS: setting the filter in the PMC chart is another good workaround!  Thanks!

[Track Smart]

Just an update:  This issue persists in version 3.6 of GC (Build 5000).  Changing all non-standard activities to "run" leads to a much more realistic Triscore.  

Example: Instead of an easy hike having a TriScore of ~150 it gets changed to ~15 after labeling it as a Run.  That's a ten-fold decrease in the estimated training load and much more realistic.

Does this issue still exist in the latest stable release?  

[Ale Martinez]

El viernes, 23 de enero de 2026 a la(s) 1:32:00 p.m. UTC-3, track...@gmail.com escribió:

Just an update:  This issue persists in version 3.6 of GC (Build 5000).  Changing all non-standard activities to "run" leads to a much more realistic Triscore.  

What you are doing is to force all that activities to use the GOVSS algorithm to compute TriScore which applies only to isRun activities, that's ok if that floats your boat.

 

Example: Instead of an easy hike having a TriScore of ~150 it gets changed to ~15 after labeling it as a Run.  That's a ten-fold decrease in the estimated training load and much more realistic.

Does this issue still exist in the latest stable release?  

I don't think this is a "issue", but a lack of understanding about the way TriScore works, It is defined in the wiki but lest walk around:

1. if isSwim then SwimScore algorithm based on swim speed is used, provided speed is present.
2. if isRun then GOVSS algorithm base on running speed is used, provided speed is present
3. in any other case we try to compute BikeScore which requires power data and CP, while this is intended for Bike rides it really applies to any sport with power data s.t. Rowing too.
4. finally if the score still is zero (swim or run without speed, other sport without power) we use TRIMP Zonal Points as a fallback.

It is really intended for SBR so you can play it safe using a SBR filter for your PMC, if you want to consider other sports they will default to BikeScore if power is present and TRIMP Zonal points otherwise. So if you hikes have a too high score and no power, the likely reason is anomalous HR Data and/or inadequate HR zones / TRIMP coefficients for that sport.

 

Hope this clarifies the situation and helps to make your call, alternatively you could define your own stress metric to your taste.

[Ale Martinez]

PS: the above refers to current stable version (3.7.1), v3.6 is too old and too much water ran under the bridge to waste my time diagnosing an issue on it.  

[Track Smart]

Hi Ale,

Thanks for the reply!  I agree that it is not worth fixing the older version (3.6).  I was just wondering if the same behavior was present in the new version (possibly yes).

Your explanation of falling back to TRIMP Zonal Points does not appear to be true for my activities - or at least it appears to be miscalculated.  The TRIMP points for these activities are very low (due to low heart rate).  There is no power data, just heart rate (low) and speed (e.g. 1.9 MPH).  Changing the sport from "Hike" to "Run" results in a TriScore that is similar order of magnitude to the TRIMP points (instead of many times higher than the TRIMP points).  I don't think that a TriScore that is 6 - 10x higher than the TRIMP points is likely to be intended behavior.

I upgraded from version 3.5 to 3.6 when I last reported this.  That yielded no change to the behavior.  Maybe it is fixed in 3.7.1.  I guess I'll find out when I upgrade.

[Ale Martinez]

El viernes, 23 de enero de 2026 a la(s) 5:12:53 p.m. UTC-3, track...@gmail.com escribió:

Hi Ale,

Thanks for the reply!  I agree that it is not worth fixing the older version (3.6).  I was just wondering if the same behavior was present in the new version (possibly yes).

Your explanation of falling back to TRIMP Zonal Points does not appear to be true for my activities - or at least it appears to be miscalculated.  The TRIMP points for these activities are very low (due to low heart rate).  There is no power data, just heart rate (low) and speed (e.g. 1.9 MPH).  Changing the sport from "Hike" to "Run" results in a TriScore that is similar order of magnitude to the TRIMP points (instead of many times higher than the TRIMP points).  I don't think that a TriScore that is 6 - 10x higher than the TRIMP points is likely to be intended behavior.

No, but it can happen if there are spikes in Data, it is always a good idea to look at Data > Raw Data > Anomalies in these cases.

You can also look at TriScore, BikeScore and TRIMP Zonal Points for the same workout to see if there is a pattern, beware TRIMP Points are a different kind of animal.  

[Ale Martinez]

BTW and talking in general terms: when you have a problem affecting you and nobody else, perhaps related to your own data, the recommended course of action is to take agency, it is ok to look for help but you have the problem and are in charge to diagnose it.

It can be appealing to think you are a customer and customers are always right, so I report the issue and take a seat while something else fixes it, periodically reactivating the claim, but I have bad news for you: it doesn't work that way for non-sponsored FOSS systems, at least no for GoldenCheetah AFAIK.

[Track Smart]

100% understood!  Thank you for taking the time to respond.  I'll do further troubleshooting on my own.

You've already given me a lot of valuable information (e.g., how TriScore is calculated for non-standard activities; that this isn't a problem reported by others; to look for potential issues on my side - whether data anomalies/spikes or other issues unique to my situation; TRIMP vs TRIMP Zonal, etc).

Thanks again.