Improve powercurve for Flow/Magic with T1901 brake and T1904/T1932 head unit (antifier)

[WouterJD]

Hi @BikeBeppe64 I have created this issue on your request, so it's not forgotten:

Ciao Wouter tutto bene? Scusa il disturbo...

Just my 2 cents for FortiusAnt

• Negative grade as downhill : while Rouving into my Strava "Up&Down" I got 63km/h during a pedalling downhill (-7/8%) but using with it FortiusAnt max speed was more more less, around 15 km/h
• with no pedalling no speed, but in real biking is not so
• Power at < positive 1.2/1.4% FortiusAnt was 40w. My opinion could be at least 80w as intermediate biker.

I think that Python could do better algorithm... ;-) and I don't know how to help you.

[WouterJD]

Well giuseppe.
Don;t know exactly what to answer; some people are happy with the current implementation and others are not.

The calculations are described in the manual and -if accessible for you- openly available in the python code; suggestions are always welcome.

[BikeBeppe64]

I try to explain better my think

1a) if there is a slow speed in climbing an uphill there should be an higher speed in downhill. I noticed that in a downhill of 12%, fortiusant shows max 20km/h while ROUVY was 63km/h. It's also true that in an uppung hill same grade of 10 % speed of ROUVY was half of Fortiusant

1b) in the same downhill if I pedal or not I got 40w , in real world no pedalling no watts or changing the gear I got more watts.

2. downhill or uphill with a slope of + 1.5% the power was fixed at 40w. in my opinion we intermediate biker , have a force, at least, of 80w

A part of all, as you know, I do appreciate all your work that you are doing for free, I print "IFlow FortiusAnt by Wouter JD" on Strava account to thank you

[WouterJD]

Hi @BikeBeppe64

I print "IFlow FortiusAnt by Wouter JD" on Strava account to thank you
Thank you - highly appreciated!

Zwift commands to ride uphill with -12%
You decide to ride with the wheelspeed of 20km/hr
FortiusANT calculates a required power: (grade/speed --> power --> resistance) see manual page 12
FortiusANT sends power to Zwift
Then Zwift calculates a speed (power/grade --> speed)

The two formula's are not necessarily the same.

At the other hand, this seems related to #102
See also #115 #126 #128
Owners of these types should perform a test, see especially #128 where some progress is being made

[WouterJD]

I'm digging into this "Power curve" subject and get the following impression: headunit/brake combinations T1932/T1941 and T1902/T1901 work, but the others don't.

Please respond to this post: what bundle did you buy, and what brake and what head unit do you use?

Bundle	Brake	Head unit	Remarks
T1930 Tacx Fortius	T1941 Motor	T1932	USB interface tested, see manual 2.6.2
T1900 Tacx i-Magic	T1901 Magnetic	T1902	Legacy USB interface tested, see manual 2.6.3
T???? Tacx Flow	T1901 Magnetic	T1932	Issues: #102 #143
T???? Tacx i-Magic	?	T1904	Issues: #128

[BikeBeppe64]

My bundle T2250 Tacx I-Flow - T1901- T1932

[cyclingflow]

I might have some pointers to help out.

I have a Flow (1901 Brake) and 1932 combination. Could not get FortiusAnt to work. Calibration attempts with error messages,
(Yes i know, i switched it off) flawed power readings, power mode not working well, grade mode totally off.

However, i have downloaded and adapted both antifier(power_curve) and FortiusAnt, now they both do work. I have been calibrating the Flow + software with a powermeter on the bike.

I probably have missed the way it was intended to work, but I basically don't see see how the current implementation in usbTrainer would work correctly with my combination in grade mode.
I have implemented an additional clsTacxUsbTrainer (clsTacx1901UsbTrainer)
that incorperates some of the original logic of antifier, including reading a custum power curve file.

Yesterday I finished an 1 hour time trial in Rouvy AR and everything worked well. Have also used the adapted antifier with Rouvy Workouts and Zwift.

Anyway, thx for FortiusAnt, Wouter, I like it.

[WouterJD]

Welcome @cyclingflow to the FortiusANT community

---

I'm always curious to know who I communicate with, where FortiusANT is used and what configuration is used.
I would therefore appreciate that you introduce yourself; perhaps leave a comment under issue #14.

---

I am very interested in your clsTacx1901UsbTrainer because that seems to solve a set of issues.
I did not manage to get the original antifier work succesfully with Fortius (power curve incorrect) and that is how FortiusANT forked from it and developed to what it is now.

Great to hear that you understand the subject, we can make numerous Flow'ers happy, I think!

[WouterJD]

Based upon who reported power issues and the responses to the question what head unit/brake is used, I can share the following information and this matches with the reaction of @cyclingflow.
The issues regarding the "Power not stable" on Magic/Flow all relate to"New USB interface" and "T1901 brake".
I closed the other issues #115 #126 #128 and modify the title of this issue.

Head unit	Tacx trainer	Contacts	T1901	(blank)
T1904	i-Magic	Mk2mark	1
		Lorangaw	1
T1932	Flow	e7andy	1
		SwitchMcBlade	1
	Fortius	torqueNoFriction		1
	i-Flow	fireone		1
	i-Flow VR	BikeBeppe64	1
	i-Magic	sgtjlanc	1
		Timmenem	1

[cyclingflow]

I have forked FortiusAnt and Antifier. (Antifier will be needed primarily because of the power_curve script. You could include it in FortiusAnt, but is currently certainly not up to your standards. And needs conversion to python3)

I will be uploading modified files.

I think some clarifications of the changes I made my help you in understanding, and may be bold enough to suggest a few minor 'refactor' suggestions.
If and how would you like to receive them?

[WouterJD]

@cyclingflow I could download from your forked/branched implementation - this no issue.
I will certainly study how your clsTacx1901UsbTrainer class works.
As said, I did not manage to understand antifier's approach for the powercurve; the code is quite complex.

But it would be very helpful, if you would want to execute a test as done by @yegorvin, see manual "2.6.3 Test for i-Magic (T1902)". In your case, you have a working model, so no need to tweak.

Purpose is to redefine TargetPower2Resistance(self), converting TargetPower to TargetResistance (using WheelSpeed).

If you don't mind, please merge logfile.py (so you can create the json-file) and add
/~https://github.com/WouterJD/FortiusANT/blob/master/pythoncode/FortiusAntBody.py#L796

Then perform a test in manual mode (-m flag): (16 minutes test time after good warming up)

Target Power	10km/hr	20km/hr	30km/hr	40km/hr
100	1  minute
150
200
250

and [if there is energy left - we could start with the results of the first test] in manual grade mode (-M flag):

Target Power	10km/hr	20km/hr	30km/hr	40km/hr
0%	1  minute
5%	1  minute
10%	1  minute
15%
20%

the JSON file should provide the resulting data.

Using the JSON file contents, I will see whether I can execute the mathematics like done for @yegorvin.
It will also reveal the range of TargetResistance

[WouterJD]

@cyclingflow would you mind doing the test as described? Would help us forward in understanding how i-Magic should be addressed

[cyclingflow]

Well, i have been doing lots of calibration tests to provide curve_factor_power factors.

Have just been doing such a grid test, results not yet satisfactory.

But let me explain where i stand. Your requested test will not fully show the crucial results. The plot below does.

[cyclingflow]

DIFFERENCES IN IMPLEMENTATION

What are the difficulties in the current coding for using 1 Flow type 1901 brake?

• The 1901 only reports back a limited set of resitance values. (14 values, or 14 resistance levels)
• There is no guarantee that these values are really linearly related to a single multiplier,
  moreover, as i will explain in next section, one linear equation is not enough anyway
• each level may need different tuning
• The current mechanism always uses powermode, and updates resistance based upon power,
  which made it difficult for me to implement antifiers approach, and test it, if not false.
  A manual grade to resistance is easier anyway.

So, I took the easy way, and started with antifier's approach, with an estimation per level, a clear grade mode vs power mode,
and manual grades.

It worked, although not completely (next section).
Later on I got a better understanding of the code, and have been reversing the approach to be more in line with FortiusAnt implementation, such that for example the real life grade->power-> resistance can be used.
Although this makes no sense for this brake, as the power grid test will clearly show.

In the end, things might be simplified even more.

[cyclingflow]

THE ANTIFIER APPROACH

Antifier's approach can be easily understood if you take a look at a plot of speed vs reference power (power meter), based upon a run of a adapted power_curve.py script. I have done many the last days, because it introduced a new problem: inconsistent results over reruns.
First the approach. Take the next plot, at resistance level 5, (starting with 0, the sixth), i have cleaned out the outliers:

You can clearly see it is highly linear -as aspected-, but does not go through (0,0) as a single multiplier approach assumes.

Using this approach, with a linear equation (including intercept or constant b in most tutorials) for each level, and a calibration run of power_curve.py, you get reasonable results, for higher wattages!.

My initial run had an average power of 203 as estimated by the new FortiusAnt usbTacx1901Trainer, and an average reference power of 196W. Which is fine, especially given the fact that i use a one crank power meter on a leg with busted knee: a clear tendency to underperform the other leg.

However, consideration of the reason for the unexpected huge intercepts for high resistance levels, made me think of two problems in this approach.

[cyclingflow]

ANTIFIER APPROACH PROBLEMS

First, my suspected reason of the plot as shown above. For lack of data (inobtainable) at low speeds, you cant really see it, but i expect that the plot should curve back to (0,0) at low speeds. What i think the brake does, is slowly increase the brake to the required resistance level at a certain speed, say 10 kph, and being fairly linear afterwards. Makes sense to me given the electro-magnetic nature, but a specialist may comment/explain otherwise. (For example, if possible, it would probably require high currents at low speeds to induce the required resistance.)

Problem1
This approach underestimates powers at low speeds. May be a trivial problem for many users, but it also makes power control at low powers a mess. Bear in mind, that the current estimation of the intercept for the highest resistance level is well over -100W!
I originally expected to be using an integrated spline approach to the estimation if needed. After looking at the plot i decided to use a piecewise linear approach with an knot. Say the knot is at 10 kph, you will have the original linear approach above 10 kph,
and a linear approach from (0,0) to the point at 10 kph on the line. Straightforward, and it solves the estimation at the lower speeds.
The second problem is a bit more serious in my opinion.

Problem2
If you do use a separate estimation for each resistance level, you may violate monotonicity requirements. In practice, it does.
What does this mean? In practical terms, imagine that you cycle at a given speed, and given resistance.
Now, if you either increase resistance, or increase speed, in both cases the estimated power should always increase.
Antifiers approach with separate estimation certainly does not guarantee this over the complete range of speeds,
although it does work at high speeds. But power mode on 100W already showed strange phenomena.
It also does not help that getting consistent empirical data turns out to be difficult. You might also consider this an measurement problem of the current setup: if we would measure more accurately, and the trainer is really consistent, the estimation should automatically satisfy the constraints.

Now, as an estimation problem all equations could be solved in the least squares framework, using an combined approach to all 14 estimation problems with inequality constraints on the parameters. For me fun to do, and not too difficult, but I suspect it to be overkill. If i can find an empirically satisfying relationship between the slopes, possibly related to resistance values, everything can be simplified again.

Moreover, if that is the case, re-calibration for other users could be made much easier. Relevant, because of differences in drive train losses, and tire resistance.

For now, I have manually regularized the parameters to satisfy the constraints (increasing slopes, increasing intercepts).

[cyclingflow]

THE GOOD NEWS
is that i have implemented everything i wanted, and will upload an exe. It's working.

The bad news is that my current power_curve_factors file is not good enough:
I have difficulty getting consistent results when doing power_curve runs (even one shortly after the other, on a warmed up system). So that i need many tests to get accurate results.
I have been testing and testing and manually adjusting factors. And overdone it. An extensive test as you requested
showed that powers at low speed are OK, but now high powers at high speeds are underestimated.

This also shows that this brake has a very limited bandwith. The missing test values are the result of not low enough or not high enough resistance values. They simply can't be done. You cant even do 50W on 10 kph, hence 7.5 kph.
As a consequence, real life grade to power conversion has no use. In stead, you can provide convenient grade factors in the power_curve_factors file, such that you have a reasonable experience in a limited range. Say, -5% to 9%, where a change in slope/grade is felt as a change in resistance when pedaling. In real life you often would have to change gears anyway, and you can do so on the trainer as well, just a smaller range. The required watts stay the same. The virtual speed in the software can be anything you want. True, you can not do strength training like cycling up a steep hill in two high gear. A limit of the machine, not the software.

I guess this a complicated way of saying why tacx developed the fortius and other variants. This brake's concept has limits in simulating reality, but in my opinion does not limit very much it's usefulness for many virtual training sessions, unless you are true powerhouse exceeding the maximum power limits. M2CW

[cyclingflow]

UPLOAD.

Ok, done. My executable was to big. In stead, you can obtain everything by going to the prelease
/~https://github.com/cyclingflow/FortiusANT/releases

click on assets, and download zip "FortiusAnt3.6Test0.1.zip".

Notes:

• test version only. Not 'Wouter approved'.
• please use bat files to run, because they contain necessary new command line arguments.
• I realized that my original power factors might be better.
  You can run as is, (which will use "power_calc_factors_custom.Flow.txt")
  but if you rename that file to something different it will use earlier default factors,
  included in the source.

I will be updating the factor file.

(Wouter, sorry need some help: solve the binary problem, your wishes for versioning etc. Also a pointer for creating the log file, if you want one. I currently used my bike computer's fit files to analyze the true power)

[cyclingflow]

There is a bug in power calculation, i will bring out a new release.

I have now more knowledge of my calibration/reference power issues. I realized that i do not need power_curve.py, but are far better off with using my bike computer and the resulting fit file, to analyze speed vs power, provided i set the wheel circumference exactly right.

Results are much better, but also indicate i have a problem with my stages crank power meter: power readings are not consistent over cadence differences. A couple of months ago i noticed a large difference in the calibration factor of the device, having been consistent in the months before, and being consistently differently after.
So i will have to send in the powermeter to recalibrate it.

[WouterJD]

@cyclingflow great work you perform; thank you very much.
Please proceed to get the data correct for the Flow

Last year, around this time, I started with the antifier software and was impressed by the tables and approach. BUT it works!
I also tried (like many others) to get a power curve defined for the Fortius but did not manage to.
I found TotalReverse's work and combined it and so FortiusANT became antifier 2.0

The Fortius and the Flow both work based upon formula's and hence I believe that also the 1932/1901 combi must be possible to be programmed analogously

What I have done now, to understand the subject better, I have ported the formula's to excel to visualize the calculations.
It's not finished, but it's time to call it a day.
I wanted to share the intermediate result with you anyway; see image of powercurve and attached zipped XLS

Conclusion of the exercise: the FortiusANT/USB formula provides results in the same range as antifier formula's; but not close enough to be satisfying.
Todo: create a formula that provides the power curve that is compliant with the antifier-approach.

Summary:

• I am absolutely impressed by the antifier approach with tables and external files; it looks like too complex for the subject though. But - as said before - it works and therefore provides the data we need.
• Tacx' TTS works for all Flows without parameterization, so one approach should be good for all
• Using your excellent work, I will find out the formula's and work towards a testable version shortly

AntifierCyclingFlow.zip

[cyclingflow]

I will explain a bit about my motivation in pursuing accuracy.
Why accuracy?
Over the last 8 months i have using the flow along side my bike power meter. Because it is one-sided, i tried to use the flow's power readings to help me analyze differences between left and right leg. I definitely have a problem in one leg.

It became clear to me that there were some systematic differences. Generally i have best results if manually put the brake on the 7th resistance level. The differences are fairly consistent, as long as you keep checking your tire presure, and use the calibration procedures.

a couple of months ago, the power meter changed, and differences between flow and power meter are a bit larger. Still, the power meter accurately measures force, at least within 3% accuracy, as i have tested using weights.

Measurement Errors of the setup
We have been talking and commenting about measurement erros and accuracy of the trainers in measureing power, as others have done in reviews. I would like make some clarification on the nature of these errors, after having done a considerable amount of testing my setup.

1. Your typical Random measurement errors are extremely small. When doing one speed run at a particular level, i have
   got extremely consistent results. Such that power vs speed is linear with a correlation of .999, granted with just 5 to 7 observation points. All the time. This is really excellent given the fact that i measure power at the bike, with different gears and varying cadence. With a couple of minutes of warming I can't say i have seen clear indications of addtional effects within the small time of one speed run.

2. Systematic errors are much larger. I have had small inconsistencies when changing between resistance levels, and large inconsistencies between sessions. @WouterJD @switchabl , myself, we have made useful comments on the nature of this.

Given these observation my personal preference is to not introduce additional approximation errors, keeping 1 a small as they are now, while working at an approach that tries to deal with 2 by using a calibration procedure. Note that the 1901 brake does not have a calibration test as a motor brake does.

[cyclingflow]

@WouterJD Comments on current implementation and manual.

I have to admit i'm a bit pissed off right now. After all the work i have done, you seem to ignore the advice and info of an expert on these matters. It's notthat you did not do a great job on the program, the formula's the communication protocols. You did do a great job! It's just that you have showed a little less knowledge in this particular area.

[cyclingflow]

My comments

1. You started off wrong footed. The table you mention in the manual is not from antifier. It is exactly a table i provided in an early stage, and you incidentally missed out on the accompanying info.
   Any statement you made on the natures of these tables based on this one is unfounded. This table does not provide real observed estimates using the antifier approach. I manually adjusted the parameters to reguralize the problem. Everything looks smooth, because i explicitly made them look smooth.
   I did so because i was having trouble getting accurate results through antifiers power_curve.py. These were solved when using fit files.
   I also showed this tables estimation to be at least 10% off at higher speeds and power.
   I have currently much better results.

2. Please, don't use imprecise statements on the 'likely' accuracy of power estimation while you are basicl just messing around with parameter estimates rather than power observation. Because, in contrast many people really appreciate some results on the power estimates. Such as:
   " The current approximation of the table factors leads to power estimates that on average are 3W off" or "the maximum difference is 11 wthat at speed .." or errors are about 11% at 200-250 watt level."
   Now we may differ in opinion on the practical significance of these errors, i don't have a problem with that. But it will make results comparable between our approaches. While opening up the discussion on the implications of these power estimation errors to a much wider audience, in relation to use for training analysis, or fair results in online VR sessions.

[cyclingflow]

3. You have a changed the implementation of TargetGrade2Resistance(self) compared to antifier and my version. It therefore introduces an additional discretization error, by selecting the correct value only approxximately 50% of the time.
   I understand your desire to put in a break statement to cut the loop short, but this is not the way to do it.

4. I'am not sure your statement in the mnual on the nature of these grades is fair to John/antifier. To clarify: these grades are ones i have manually adjusted and provided, to satisfy riding some routes in Rouvy. Indeed to allow for the limited resistance range. To be fair, antifiers approach does use the same type of considerations and calculation you do, using an assumed overall weight, and a simplified version of the nice gribble formula's you have implemented. It's explicitly in power_curve.py and it's comments.

[cyclingflow]

My final comment. Flow's estimates as standard.

A more regularized approach might be justified by fears of overfitting in the 14 equation approach.

As @WouterJD has said, people have appreciated the tacx trainers, and although some critique exist on the accuracy of the power readings, they have been widely perceived as useful tools (based upon comments here, multiple reviews.)
So we can consider it a standard to some extent.

Therefore, we may simplify the extraction of formula's for the purpose of FortiusAntifer, by not looking at external bike power reference values, but also looking at the provided power readings of a device like the T1682 or T2202.
I have one, and have some results. Conclusions so far:

1. neither a two x two factor or a 5 factor approach introducing a quadratic term - for the intercepts in the 14*2 parameterization - does completely cut it. The approach here is similar to the approach @WouterJD has explained in the manual for the legacy formula's, with a little improvement by getting all 5 parameters simultaenously, globally optimal (LS framework).
2. Needless to say that the 14*2 has no problem replicating these power readings. This uses the exact same power formula, while implicitly providing it's own 'resistance' values, rather than the one provided the unit, and therefor is fine.
3. My conclusion is, that t_he tacx is doing things slightly differently than FortiusAnt formula's_. And it confirms my suspicion that the resistance values returned by the unit are optimized for a lightly different objective function, such that @WouterJD approach is compromized. Which is a pity. It could have been very simple.

I was planning to provide you with these 5 factors optimize to work out in your formula's.

I simply assume our paths will diverge.

[WouterJD]

Thanks. Let's work together to get a solid magnetic brake implementation.

My position at this moment is that I prefer formula-based over the table-driven approach [I really prefer to avoid estimation-loops (0...13) as much as possible]. Unless proven that no solid formula can be created.
Since this is possible for the legacy-USB, so I am still positive on it.

Thanks for all time co-invested.

[WouterJD]

/~https://github.com/WouterJD/FortiusANT/blob/%23143-Powercurve-iMagic/supportfiles/FortiusANT%20-%20Powercurve.xlsm

Contains the table-based and formula-based algorithm and I believe the results are very close.
The table-based formula's are based upon your pythoncode in the current version.

[WouterJD]

What I would like to have is the result of the test as described in the manual: 2.6.5 Test for i-Flow (T1901-T1932). This would provide a solid foundation for further development.

[WouterJD]

step down

Daarmee bedoelde ik overigens "doe ff relaxed aub".

[Mk2mark]

Hi Wouter & Cyclingflow,
You have clearly moved beyond my limited capabilities so I will retire from this discussion and await your conclusions.

1. Having now fitted a cadence sensor to my T1901 brake/T1904 headunit, the behaviour has changed significantly and become much more consistent. So cadence is clearly being used by the headunit to make some adjustment.

2. Using with Zwift in slope mode is fine as is - the slopes are adjusted anyway and steeper gets harder so all good. But Zwift does need to read the independent power, not the TACX power, to get speeds correct.

3. Using Zwift in ERG mode is more challenging. The target power set by FortiusANt is not the same as that set by Zwift and is not consistent. However it is perfectly usable with a bit of fiddling to find the gear selection/cadence that works.

4. What you have achieved already is a huge benefit to me and many others. Thank you, and I hope you continue to make progress.

Mark.

[WouterJD]

@Mk2mark; please join issue #153.

I am working on a version that supports your configuration (T1901 magnetic brake on T1904 headunit) as well as T1901 on T1932 headunit next to the Fortius itself (T1941 motor brake on T1932 headunit). Do you happen to have a powermeter?

[cyclingflow]

My speed vs Power Runs

I have done evrything in Matlab sofar, did not get around to compiling a table in xlsx. Have done so now.

/~https://github.com/cyclingflow/FortiusANT/blob/3.6.b.0.3/pythoncode/CyclingFlow.SpeedvsPower.xlsx

Notes:

1. These speeds have been calibrated to a wheel2Speed factor of 279 effectively (goal was 280.54). To find correct values for speeds for your needs, you will have to recalculate to 301 or 289. Should be easy.

2. I started out using much more speed points at Level 0, Level 5, and Level 13 (resistance levels). After seeing the regular results, and requests from @WouterJD, I reduced new runs to these speed points

3. All speeds and power are average values over 5-10 seconds, after confirming that speeds and power are at a constant level. This excludes the big influence of acceleration in power readings. Once you do that, taking a period of 10 seconds or 30 or more does not improve the accuracy, they are virtually the same. And it requires you to be able to really keep things constant, which is hard to do.

4. I have marked cells red. I dont consider them to be accurate. This is the point were I feel my weaker leg failing, and my knee starts hurting. I normally just push a bit harder with the better leg, but that introduces measurement error with a one crank power meter. So i stopped doing those cells of speed vs power.

5 The green rows are the ones i use, based upon the feeling whether i had done the calibration and tire pressure, knob resistance, right.

Right now these tables are a little bit lower than my current readings because i have increased tire resistance to prevent slipping.

[switchabl]

Thanks, this looks really good! More or less exactly what I had hoped for 👍

It would of course still be helpful to gather data from other people's trainer/different settings/two-sided power meters to see how it generalizes and what accuracy to expect. But this should be more than good enough to test my ideas for now.

[cyclingflow]

@switchabl

But this should be more than good enough to test my ideas for now.

Yes. We are using the same line of thinking. But let's see if you come to different conclusions.

[WouterJD]

Didn't see there was active comms on this issue as well...

[Mk2mark]

Here is some data. Tyre pressure 100psi (23mm continental gator skin).
10 min warm up then run down test 8 seconds from 40kph to 0.
There are two sets of data (you can see from the time stamps). Each set is a json, 2xlog & tcx from FortiusAnt and also a tcx from my Garmin/Cycleops.
The first set covers all resistance values at 12kph and 24kph and up to about 2700 at 36kph. Sorry I felt quite fatigued today so couldn't go higher. I waited 5 minutes and had another go (second data set) starting at 3700 & 30kph and dropping down to 2700.
I hope you can extract some meaning fun data from all this. I think I have covered the 0-370W (real power) range fairly well.

i-magic data.zip

[Mk2mark]

I'm sure you have better tools but I have used vim and excel to look at my data.
It is consistent with what you have seen before. The data is good for all resistance levels at 12 & 24kph and good up to resistance level 2858 at 36kph. There may be good data also in the second file for higher levels - I will check.
FA_Garmin.pdf

[Mk2mark]

The second set of files have useful data in the last third of the time period - decreasing from 3700 to 2600. Actual power 500w down to 280w.

[Mk2mark]

I was having trouble correlating the timestamps of th two data sets, so I checked. My Garmin time is running 44s behind my PC time. Maybe because it has been on INDOOR mode and not updating from GPS?

[WouterJD]

I combine the two datasets into one and adjust the time and used 40 seconds; Now adjusted to 44 :-)

I react under issue #153 since discussion has moved there

[WouterJD]

Closed on behalf of #153