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]

Interesting! And they clearly show the monotonicity

Tacx' TTS works for all Flows without parameterization, so one approach should be good for all

True, but perhaps at the sacrifice of accuracy. Will see.

An example of my latest calibration results. I order all values on the time scale and select platforms of speed and power, avoiding the speedup jumps, calculating average speed and power for a platform.

I expect the slopes and intercepts to be very regular, so we can indeed reverse back to simpler formula's. The particular integer values returned for the resistance levels are clearly designed for that purpose, whether accurate or not.

I call it a day too ;-)

[WouterJD]

Do you use the external file or the internal values?

[cyclingflow]

They are actually, the same, there are two correction factors in there i have reset to zero.

But constantly adjusting, it's satisfying to see the much better results. :-) Only using FortiusAnt to select the grades, and check the proceedings.

I'm calibrating now through my bike computers fits files, going through the speeds steps, at one particular resistance level. works fine.

I can hand pick a flat level and get the info at the selected range. Much more accurate than power_curve.py, no additional cleaning of data needed.

[cyclingflow]

I have been thinking about the returned resistance values: do they help, or do we simply need equally spaced values.

Anyways, i have been expecting my approach to be able to come down to this (because slopes and intercepts are highly linearly related): Step 1: (slope = factor 'a' in linear power equation, intercept = factor 'b', power=aspeed+b) Get the slope for resistance level Slope = (resistance or integer)a_1 + b_1 Get the intercept for resistance level Intercept = (resistance or integer)a_2 + b_2 Step 2: Power = speedKph Slope + Intercept.

This will bring the whole table down to at most 4 constants a1, a2, b1, b2. Looks like it's going to be like that. Will certainly ease calibration for other users. Which brings up the calibration values returned by the trainer: are they of any use?

I would like NOT to bring it down exactly to the fortius formula's, because it would imply dumping the intercept. That will always harm the accuracy.

And i'am dreaming of bringing in the acceleration factor in the future. Bear with me a bit, i'am probably as passionate about good estimates as you are about programming :-)

[WouterJD]

You are absolutely right

Note that: 1- Legacy USB works well (magnetic = exponential curve) [although the graph is quite linear] 2- Newer USB has resistance in right range, but the curve is not right

What I think: ==> Formula 1) must be corrected to the range of 2) and then we're done

Doing other things today, just answering some questions :-)

[cyclingflow]

Have fun! Am going outside soon too, nice wheather

[cyclingflow]

(Oh, and BTW, when you have time: could you provide me with power supply details if you have them? I got a bargain on a Fortius yesterday, 50 euros, but without power unit. Fine with me, if i don't get it working, at least i have a second 1932 unit, and get my cycling mate training with my second flow. No rush)

[WouterJD]

I have tried to port the antifier's formula's to Excel to visualize what it does. See attached excel (zipped) AntifierCyclingFlow-V2.zip

Following support would be appreciated:

• who checks whether the formula's are ported to Excel correctly?
• who explains the logic to me?
• who proves that the two formula's CurrentResistance2Power_antifier() and TargetPower2Resistance_antifier() are each other's opposites (as I think they should be)?

Untill now I did not deciphre the logic behind it.

[cyclingflow]

i will check

[cyclingflow]

I have finished calibration runs. Using the Per_level_separate_equation method i get good results now. Will produce an power * speed matrix

I have also implemented the 4-factor-only simplyfication. (new class tacxSimplified1901UsbTrainer, that reads a much simpler customization file if it exists)

Currently studying the results of separate vs simultane estimation

[cyclingflow]

Some more formula's for the simultane - all at once - estimation of the 4 factors directly upon the calibration points Given the earlier equations Step 1:
Slope = resistancea_1 + b_1 Intercept = (resistance or integer)a_2 + b_2 Step 2: Power = speedKph * Slope + Intercept.

Lets substitute step1 into step 2. Let m = number of levels r_i = resistance at level i and per level we have a set of observations O_i = (S_i_j, P_i_j) of size N_i where, P_i_j = power at level i for observation j in O_i S_i_j = speed at level i for observation j in O_i Then we have the equation P_i_j = r_i*S a_1 + S_i_j b_1 + r_i*a_2 + b_2

Consequently, if you setup a matrix of independents X_i for level i with columns r_i*S_i_j, S_i_j, r_i, 1 and stack all levels below each other in X=[X_1',X_2', X_3', ..., X_m']' and Y=[P_1', P2', P_3',...,P_m']' we have the typical linear regression equation Y=X'[a_1, b_1, a_2, b_2] that we can simply solve with LS regresion (or some other method we like). Due to the equation structure, monotonicity is guaranteed.

[cyclingflow]

The problem so far is the lack of linearity of the slopes Vertical = Slopes, Horizontal = resistance values. (NB, the 'send' resistance values have a slightly higher correlation with slope and intercept, than just integers 1;14, or the received resistance values. We send resistance values to the headunit from 1900 - 3750, we receive values from the headunit from 1039 to 4677, two series of 14 integers each, corresponding to the 14 levels of resistance.)

Even if we regard the jump for resistance=3600 in the figure as an outlier, it is still curved, rather than linear. I am now studying the loss in accuracy, for 14 equations= 28 parameters vs 4 parameters

[WouterJD]

Regarding your post

This shows that realized power = requested power (to an acceptable level)

I have the following proposal:

• Since the power curve logic in your fork is satisfactory now (see above)
• Please merge the current Fortius code, so you can export the JSON file
• Execute the test as described https://github.com/WouterJD/FortiusANT/issues/143#issuecomment-730326732

I will then take the figures of the JSON file and create the required formula's.

-- I have also made a decision:

@cyclingflow; great that you have merged the antifier code, so we are able to drive the flow succesfully now.

I also want to be honest: to save a lot of time at my side; this is the way I want to go. I do not want to invest time in the antifier formula's anymore; I have done that last year and now again and I do not see the logic nor support the complexity. A simple formula works as confirmed by all Fortius and legacy/flow users, see also Golden Cheetah and TotalReverse.

So that is the way I want to put time in.

[cyclingflow]

I incidentally made the same kind of decision last night.

If i understand you correctly, in a different direction.

I don't want to invest more time in bringing down the14x2 factor approach to 4 or even less factors/parameters. I have spend significant time (the final formula is more simple, the estimation procedure certainly is not). It's not worth it. If i use the two methods to estimate the power values of all my calibration runs:

• 14*2 parameters: average residual 3.6W, max residual 11W (the approach has .999 correlation between observed and calculated power values, for each resistance level)
• 4 factors: average residual 11W, max residual 35W-45W (depending on estimation procedure) That's way worse. I can mathematically guarantee you that using your formula - only one factor, if we discard the difference in roll diameter- it will be even significantly more worse. Won't bother you now with the details.

What's even worse, the original fortius approach will force the users to using the realistic grade to power approach, that's way beyond the capabilities of this trainer, as is now clear to me.

Suggestion: I can understand you not willing to spend more time on it, but why not accept the 1901 class as it is? May be accept it partly as a black box. I don't see a principal problem in using 28 parameters rather than 1 or 4, since the code is already there, and straightforward. Is it that terrible? i'm willing to do some more clean-up.
Anyway, this is what i do for a living for a large part, providing accurate or fast algorithms /estimates/intelligence for other peoples much larger software solutions.

If you want to proceed with your formula's, i can provide you with the optimal value. I wont be using it. No need to do another calibration run, power meter is suspect anyway. Fed up with it, i have done many :-)

Big Compliment I think you have done a great job, and a lot of work. The current program is way more thorough in its approach to communication protocols, has many more features, and is very nicely setup and programmed, with exceptional documentation. The fact that i was able to quickly adapt it to my needs, and provide a 1901Trainer class, adding command line arguments, changing the background picture, it is all a testament to that. Thanks!

[cyclingflow]

The Future

Ride on the Virtual Trainer! Send in my powercrank for recalibration, and then may be revise my power factors.

May be work on an acceleration factor. Just for the fun of it. I now have the mathematical framework. Although i believe differential equations would be the way to go, i am thinking of something simpler. The main problem i anticipate is inaccuracy in the USB protocol for speed.

Investigate a little the physical resistance inconsistencies i experience. Slip? power meter? brake?

Make a second much smaller GUI window, as an overlay to Rouvy or Zwift. Or decide that i do not need it anyway, the program is doing its job :-)

Hints for understanding antifier 14 equation approach @Wouter, if you dont want to spend any more time on it i understand. But if you ever want to understand the approach, two tips.

1. your comment who proves that the two formula's CurrentResistance2Power_antifier() and TargetPower2Resistance_antifier() are each other's opposites (as I think they should be)? In a strict sense: false. Incorrect assumption. The 1901 brake needs you the convert the required calculated resistance to the best out of limited set of 14 resistance values. If you don't, i believe it does it for you. Also note that the scale of resistance values send to the unit, is different from the scale received. (Probably because the other brakes have a wider range.) When converting that resistance value into power, it will be different, most of the time, because the actual resistance value is way different

2. You have to completely forget about resistance values for the approach to make sense. John/I assume that having set one of the 14 resistance values, the brake will be maintaining that resistance constant (might be false, something is going on in my trainer setup). Because resistance is constant, its no longer needed for the formula estimating Power, it will be implied in the factors. I suspect, it is also the reason you had trouble converting it to the Fortius, makes no sense. I could gave you an approach to do that, but you are satisfied as is. This is also why powermode is not usefull for calibration: you need to keep resistance constant.

[cyclingflow]

Will be providing new release tonight or tomorrow.

If anybody is willing to do a calibration run with good power meter and bike computer providing fit files, great. What is required is simply a flow with a bike computer with power meter, and speed exactly matching the trainer speed. I could give you instructions. THIS WILL HELP OTHER I-FLOW/I_MAGIC USERS

[WouterJD]

@cyclingflow thanks for a lot of explanation It's not that i do not want to spend time anymore; I will not spend it in antifiers formula's. I do not see any justification for the 14-values approach, which is not documented anywhere why that would be a way to go. Enough said on this subject.

For the test to be done, a powermeter is required,. So we are at a temporary stop here. But next steps can be done when repaired.

One last note for now: mind that the T1901 brake on the T1902 headunit works fine, it does not on the T1932 headunit!

[cyclingflow]

OK good to know. I obviously have no idea what would be the difference between the 1902 and 1932. So what i describe as behavior of the 1901, might be the 1932.

BTW, Acceleration, if I want to know more about the formula's involved i will simply look in the literature.

[WouterJD]

(Oh, and BTW, when you have time: could you provide me with power supply details if you have them? I got a bargain on a Fortius yesterday, 50 euros, but without power unit. Fine with me, if i don't get it working, at least i have a second 1932 unit, and get my cycling mate training with my second flow. No rush)

Power unit = T1941.50 Cosmos / Fortius 210-240V 50Hz 300W Succes; many sets@ marktplaats

[cyclingflow]

thx. I'am hunting for an unit, but bidding wars for complete sets.

Wondered if you new something about the pin configuration. May be 2 for power motor unit, 2 more for powerchoke?

[WouterJD]

Refer to totalreverse; fortunately i can limit to sw untill now😉

[switchabl]

The connector should be Hirschmann CA series (https://catalog.belden.com/index.cfm?event=pd&p=PF_CA3GS). The pin to the right of the notch is PE (protective earth). It is actually marked with an earth symbol if you look really closely. The other pins (1-3) go to the motor windings. I'm pretty confident the motor is a permanent-magnet synchronous motor. Not sure about the configuration though. I would have assumed it would be three-phase, but the inductance between the pins is not the same for all pairs, so maybe not. I never seriously considered making my own control unit, so this is not something I ever explored in detail.

[WouterJD]

@cyclingflow check this out: https://link.marktplaats.nl/m1629932165

[cyclingflow]

I never seriously considered making my own control unit, so this is not something I ever explored in detail.

May be not wise to do so, but i always wonder. Thx for the info. Sounds like an advanced motor drive unit rather than just a supply. Or may be some sort of power choke as well.

This tells me the other route is much faster:

Right now i have sealed the deal. WIll be getting 2 different head units, 2 motors, 1 power supply.

[cyclingflow]

@WouterJD regarding your remark about head units being interchangeable

I have also calculated the PowerResistanceFactor as you use it, for each resistance level of the brake, given the speed and power of calibration runs. Both the set of send target resistance values, as well as the set of received current resistance values give large variation for this factor. I.E. What is supoosed to be a single factor, is highly variant over resistance factors.

But i have been thinking of revising those into an other set of resistance integers, such that we could unify it to a single appoach, with a function using this resistance value. Not a question of much less parameters, but it would help recalibrating, and may be is more appealing to you.

[cyclingflow]

*I have submitted a new release, with latest factors, and both the 142 and 4 factor model. It also has a hidden overlay feature: a button (on top of the locate button once started), that will change (and reverse) the window into a much smaller one, with the STAY_AT_TOP flag. (It can also display 6 additional parameters if i need to.)**

[cyclingflow]

The small screen was very useful to monitor while riding Rouvy.

What i noticed was significant slipping of the wheel: lower speeds for the app as from my bike computer, where i started with good calibration. When driving at moderate constant speeds, at low resistance, it is fine. At higher resistance levels, speeds are too low.

Nothing new of course, one of the reasons they went to direct drives, also allowing for higher flywheel weights.

But i will be increasing the tire resistance. I have always used the flow at higher calibration factors (say 6-8). Was trying around 1 (manual head unit), to provide others with normal factors, but does not work for me. And i might change back to the habit of using old tires. The special trainer tire seems to be worse.

[WouterJD]

Hi @cyclingflow thanks for persistance on the subject. I'm on it as well and continue to study your achievements and will respond to some questions you ask. @BikeBeppe64 has conducted a test, using https://github.com/WouterJD/FortiusANT/tree/#143-Powercurve-iMagic

Question here: who could conduct a similar test?

---

The test is performed as follows:

• FortiusANT is operated in manual mode (-m flag), modifying the target power from 10...4000 in 50 Watt steps (read next step!).

• The power as selected is transferred directly to the i-Flow (Resistance = TargetPower) without intermediate formula. (The -r flag is created for this purpose). The assumption is that the i-Flow allowed resistance ranges from 1000…4000 and that is not Watts!

• The data from FortiusANT is saved as json-file (-d127 flag, creating a full logfile).

• A bicycle is used with power meter and Garmin Edge, registering speed and power (and cadence, heartrate). This data is available as FIT file and converted to TCX.

• FortiusANT and Garmin Edge are started.

• Initial TargetPower in FortiusANT is 100Watt ( Resistance = 150)

• Start cycling at 12km/hr.

• Increase TargetPower on the headunit every 10 seconds until 4000 (or that maximum power is reached). This will take 79 steps = 13 minutes.

• Reduce TargetPower to 1000 (I think that is the minimum value, which we will see from the first test). Note that the head unit is sampled every 250ms, so you can press two times per second only! (It’s not as fast as a keyboard).

• Redo the test at 24 and 36 km/hr.

• Stop FortiusANT and Garmin Edge and save .log, .json and .fit files.

• • • Unfortunately, it seems that his Flow does not respond well to (any) resistance setting. I have asked @totalreverse for his view on it and liked to share this

[WouterJD]

What i noticed was significant slipping of the wheel

Note that Fortius does not work at low speeds. I always ride in the highest gear to obtain maximum wheel speed even at low cadence. See manual 5.1. There is a clear reason for direct drive trainers.

[WouterJD]

OK good to know. I obviously have no idea what would be the difference between the 1902 and 1932.

Difference is the USB-protocol (see @totalreverse). Untill recently I assumed that the head unit makes the brake transparent; that is untrue.

See https://github.com/WouterJD/FortiusANT/tree/#143-Powercurve-iMagic where I detect what brake is behind the headunit. So as soon as we know the algorithm, we do not need a command line parameter to know whether there is a Motor brake or Magnetic brake.

[cyclingflow]

See https://github.com/WouterJD/FortiusANT/tree/#143-Powercurve-iMagic where I detect what brake is behind the headunit. So as soon as we know the algorithm, we do not need a command line parameter to know whether there is a Motor brake or Magnetic brake.

Great, was wondering.

The test is performed as follows:

I'am sorry. That protocol might not be efficient and will probably go through the same resistance values multiple times, because there are only 13 values accepted, rest will be converted. [1900, 2030, 2150, 2300, 2400, 2550, 2700, 2900, 3070, 3200, 3350, 3460, 3600, 3750] So it would be better to go through these directly.

If ones uses the forked version, https://github.com/cyclingflow/FortiusANT/releases and chooses manual grade mode (-M) the button will allow you to go through these resistance values, because the grade % will select different resistance values, displayed next to the grade %

@WouterJD One speed is not enough. you need at least two speeds, otherwise no intercept, (which is not only included in the antifier approach, but also in your legacy code.) i go through 10kph 15 20 25 30 35 and 40 IF doable.

A minimal scheme would be [2030, 2700, 3600] x [15kph 30 kph] @WouterJD this would give enough for a regularized 4-factor approach (or 5 if we take a quadratic approach to estimating the intercepts, as you have done in your legacy code)

A full scheme is [1900, 2030, 2150, 2300, 2400, 2550, 2700, 2900, 3070, 3200, 3350, 3460, 3600, 3750] x [10kph, 15, 20, 25, 30, 35, 40] You can skip any speed that is not practically doable.

-d127 flag

Good to know. That was what i was missing. Thought there was an specific 'test log' debug flag.