-
-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Power curve support Tacx Flow&Magic T2020 #153
Comments
You have to switch off calibration (-n) We are working on the power curve. Discussion is in https://github.com/WouterJD/FortiusANT/issues/143 BTW. I have recently increased the tire resistance to prevent slipping. |
@jurgen-iflow Welcome to the FortiusANT community I'm always curious to know who I communicate with, where FortiusANT is used and what configuration is used. Thanks @cyclingflow; a Flow-compatible version will be available shortly. Jurgen, I see you have a powermeter and that will be great to do some tests. |
@jurgen-iflow Please try the version in https://github.com/WouterJD/FortiusANT/tree/%23143-Powercurve-iMagic @cyclingflow This version implements formula's instead of tables @BikeBeppe64 Perhaps you can do a testride with the uploaded version. See uploaded manual for description; also "FortiusANT - Powercurve.xlsm" has a tab for the Magnetic Brake. |
I hope @BikeBeppe64 will enjoy the experience! And it is great to have automatic detection of the brake unit. @WouterJD |
Thanks for you message. Yes I do have a power meter. |
i will try the power curve-Imagic tonight |
To know the relation between resistance and power, I would really appreciate it if you would execute the following test: The test is performed as follows:
Would be very helpful |
Will try to do that tomorrow. Today on Zwift I was overtaken by J Wouter as approaching London Bridge - was that you? |
The version in the current branch is good to execute this test. Mind to use the version in https://github.com/WouterJD/FortiusANT/tree/%23143-Powercurve-iMagic Further developments can be done with described test-results, upon which the power curve will be based. No; that was not me. Currently either riding outside or Trainer Road for structured training. See you on strava |
I dont see it. It does say 'manual power' but the power display suggests "grade mode". Well may be. Just to be sure: did you use lowercase -m switch? case makes a difference |
I planned on commenting on some of the progress, but i came across an issue this afternoon that really puzzled me. 1932 unit issue: wrong configuration. The program was not working correctly at all, which i did not understand, until i remebered i switched 1932 head-units. What was really confusing: This one gave the wrong results. Speed was too low, and some resistance values also seemd off. Power was more off, than just the difference in speed could explain. So apparently, you can setup these 1932 devices for any of the brakes, but you have to do so first. I presume through the original software. I'am not aware if i can do so through FortiusAnt. Makes sense, because for example the motorbrake has a different roll-diameter, than the magnetic brake.. Just wanted to note that this may account for some of the users getting strange results. |
@cyclingflow That is very strange. I have never seen anything to suggest that TTS configures the brake type in any way in the USB traffic. As far as I am aware, 1) the head unit detects the magnetic brake from the 50/60Hz input on pin 4 and 2) the software requests the brake serial/version and knows that a magnetic brake is connected if it gets all zeroes (the magnetic brake is completely analog and can not send a serial number). That being said, I only have a T1932 labelled "Fortius". It was included with an i-Flow bundle and works fine with either magnetic or motor brakes. Maybe they have different firmware versions? The head unit firmware version is sent over USB, but I am not sure if FortiusANT displays it. |
I don't have my Flow unit here right now (haven't used it in years), so I can't do any measurements myself. But I was playing a bit with TTS and simulating the brake by feeding a 50Hz signal and a wheel speed signal from a function generator into the head unit. I was trying to reconstruct the power curves used by TTS, but the results are ... confusing. So I cannot share those (yet) without more tests without maybe having to retract something later. But I did find some interesting bits of information:
|
I thought it did, last time i looked. Have not looked at latest version perhaps.
I agree. I have only used a different value for backwards compatability with antifiers tables. And changed my bike computer accordingly. Comparison with the T1682 would suggest the same.
I think this is a crucial point. I have mathematical ideas for adding an additonal term to the model, and some possibly nice results. However, i'am not sure @wouter would like to go along a more complicated route, if the current models give reasonable results. I might be on my own there. NP. All models can be expressed as a hierarchical series of of models, have a few more or less parameters. They are either all right or all wrong, conceptually. And they are also the same as the legacy approach. There are just some differences in accuracy, due to using more parameters/terms. Same goes for slight differences in estimation procedures. IF everything would perfect, the solutions would coincide. No new data will change these mathematical facts. Moreover, it is hard to conceive of measurement errors such that resampling would break the emerging patterns. Adding a new term however, might be very relevant. For example, the table i'm planning to provide to @WouterJD with, that includes all my calibration runs, is already outdated for my use, because i have increased tire resistance. Therefor, for the immediate future, i'am working on getting the powerreadings out of the T1682. Tedious job. But it gets rid of any differences between sessions and users, due to tire resistance. Once you have set the unit to a particular calibration factor, readings are consistent, whether you deflate the tire or not, as long as the bikewheel is driving the trainer. We may acquire readings for more than one calibration level, and some hints how to setup you trainer and bike, such that once you have completed a run-off, we know what table to use, that can be reasonably reproduced by current models/formula's. I'am thinking of something more intricate, but that's for my fun. |
I also have some conceptual thoughts that can maybe help clear some things up. From what I can see, this is the model that is currently being considered:
There are several reasons to believe that, even if you manage to fit this reasonably well to a limited data set, it may not generalize well to different speeds and other people's trainers.
If I wanted to build a model for this, I would start from the basic physics: we can express the power in terms of the wheel speed and the various forces acting on the wheel
(The flywheel force is non-zero only when accelerating and deccelerating. It should eventually be included, but ignore for now.) The rolling resistance is usually assumed to be independent of speed, but it is highly dependent on the tyre used, the tyre pressure and unfortunately temperature (both through the tyre material and because the pressure increases when it gets hot). Every wheel-on smart trainer I am aware of uses some form of run-down calibration to calculate this. A typical value might be ~2.5N, but this can vary a lot. The brake force is where it gets complicated. Eddy current brakes are notoriously hard to model, in particular across large speed ranges. So some sort of approximation is needed. The crudest possible one would be to assume that it is constant for each resistance setting. This seems to be what TTS does for higher speeds:
I am not entirely sure what TTS does for low speeds. It looks like it could come from a calibration table. For low speeds, it is known that the brake force grows linearly with speed (-> power grows quadratically). Potential models to try that include this effect:
With F_e dependent on bytes 38-39 and a parameter v_k.
I would love to experiment with this to see what works, but I would need the data for this. I have looked in the other issue and @cyclingflow seems to have done a lot of work there, but I didn't find any raw data (maybe I missed something?). It would be good to have not only power readings for all the resistance settings, but also at least some with a detailed set of different speeds. |
Yes, this is what I tried to do with TTS4. It's less tedious because you can just automate it. I have collected a relatively large dataset, but some it looks quite messy, so either something went wrong or the Tacx implementation is just weird. I would not be totally surprised if it is, but in that case it may be less useful than we hope. I should also stress that I am not in favour of introducing many new parameters and look-up-tables (even if it does turn out Tacx did). That will work perfectly for exactly one session. I am interested in a model that is as simple as possible (but no simpler) and allows for a single parameter run-down calibration to account for tyre pressure etc. so it will work reasonably well for everyone. |
When i do this it always starts up at 2% grade and the headhunt up/down has no effect. The readout gives back power as pedalled. |
@Mk2mark please provide logfile, so I can check. |
Use the headunit: UP/DOWN buttons |
All; thanks for the enthusiastic participation in this thread. I am convinced we will get to a clear implementation. Some points from my side:
|
Log files attached. There is no CTP connected. |
Since recent, I detect motor brake version and display it on console and in the logfile. |
To remove any doubt: it sends only 14 different values to the brake too, it is not just what it reports back. I checked with an oscilloscope. This means we really only need to test 14 different settings when collecting data and nothing in between! I don't have a T1902. But from the curve in the manual it seems to change continuously? So, no? Maybe I can load the T1902 firmware onto my old T1942 and test with that.
Yes, I think we can all agree on this. The phsyics can give us a starting point, suggest some sensible things to try (and reject bad ones). But without data, there is nothing more I can do right now either. |
A couple of notes on the test protocol:
|
OK - This is what I will implement. Give me some time. |
Thanks for detailed investigation. For documentation purpose - and to understand what we're doing: the part could you please explain in human language what the correction Thanks for taking time to explain. |
Sure, I'll try to explain in (mostly) words:
Note that this is all formulated in terms of "force" (and speed etc). You could also write it in terms of "torque" and "angular velocity". That would be completely equivalent but more complicated in this case, so I don't do that. I hope this is reasonably clear, if not please let me know. Thanks for your patience with the more technical stuff! I think it is a very good thing that you are making the extra effort and document it properly. |
OK ... achievements today for "Fortius Antifier v3.9.e #153" -G factor/factorDH implemented; default = 1/1; recommended for Rouvy = -G2 @switchabl thanks for quick reaction; did update excel but not py :-) |
For what it's worth, looks good to me! If I am allowed to nit-pick, it probably makes sense to allow float for the grade/downhill factor. For a Fortius (or if you don't ride steep hills) for example, something like G1.5 might make sense. Or someone might decide 2 is not quite enough. But 3 is already quite extreme! Anyway, I think this is not particularly urgent, so maybe we just keep it in mind for the next version. |
I will change to float to avoid future changes. To avoid decimals I decided to use a divider instead of a multiplier:
Please react: what do you prefer: -G 2/2 or -G 0.5/0.5 |
Ah, I see. I have no real strong feelings about this, but would probably prefer multiplier. The most useful range is probably 0.4-1.0 and that feels more intuitive to me than 1/1.0-1/2.5. But maybe just in percent then? So -G 50/50? No decimal points, plenty of fine-adjustment and added bonus -G 100/0 "no downhill mode" (deprecate --uphill eventually?) and -G 0/0 "no hills, feeling lazy mode". Does that make sense? |
Just did a Zwift ride in standard (slope) mode and with no flags set.. Immediate reaction is massively better accuracy and feel. Will try ERG mode tomorrow. |
I have been looking at deprecation of -u so that we also simplify and not only complicate the command line Others please react! So current suggestion: defined integer percentage as a multiplier. |
Wauw. We exchanged more than 228 messages in #143 and #153 to achieve the FortiusAnt 3.9 version with the changes as described on the wiki. I like the implementation as is realized now; it did not rework FortiusAnt but amended it. Thanks all for cooperation so far. |
👍Shows you had the structure right to start with - just needed a bit more real world data to tweak it properly. Well done. |
👍 Some things remain to be done (clean-up and share my code for fitting the model, rolling resistance calibration, port things over to T1902), but that is for another day. I need a break from this brake! Also consider this: I can hopefully finish the Genius support over the weekend. And the Bushido should be easy after that (it is almost the same). So this was probably the last really tough problem we needed to solve to get all the legacy Tacx trainers working! |
It already popped-up in my mind; there is one dataset (see manual) and that could be a basis to fit the formula.
Absolutely! And if you like too exchange some christmas wishes; ping me on Strava or Messenger; after all this hard work would be nice to meet&greet. |
Hi Group, just to say, as first impression, it's all over estimated with 3.9e Slopes |
@BikeBeppe64 There is a command line parameter (-c) to change the calibration value. Start with -c 15 (the default) and try to adjust it down a bit. If it was exactly right for you in 3.9d that was sheer luck. Everyone's value will be different depending on tire pressure and knob setting and so on. Eventually there will be an automated calibration routine I guess, but for now if you want better accuracy you have to tune it by hand. |
Good idea! Ride with -c20 and amaze your friends |
I've been following the thread with interest and as it seemed like you were nearing the end I downloaded this branch 3.9e version to try it out with Zwift. I don't have a power meter to be sure if it is accurate, but TBH that doesn't bother me as much as being repeatable so I can at least directly compare myself from ride to ride. Previously even a few % change up and down I was having to fiddle with the virtual gearbox to try and get the resistance in an area that I can actually put power down. So I could never be sure from ride to ride if I'd gone up or down the same amount on the virtual gearbox at the same point in the ride. The new version is so much better, at no point did I feel the need to touch the virtual gearbox. The resistance changes felt natural and I could happily feel like I could manage the resistance changes using the bike gears alone. I'm definitely happy with the experience of installing and riding without worrying about flags or anything else. Thank you so much to everyone who worked in any way for this improvement, you've transformed my old Flow back into a useful trainer from an ornament in the garage. |
@WouterJD @switchabl @cyclingflow and all of you, thanks indeed for your time & Job done for free, I do appreciate it |
Thanks for evaluation; this is what it's all about! |
Just to add to the general mood of positivity, and following my successful Zwift Slope mode ride yesterday:- Firstly the Power output followed the target really well - significantly better than it used to with TTS4 - GREAT RESULT. Once I upped the wheel speed the power then tracked ok - started to underread from 410W as opposed to over yesterday so I may need to tweak the -c flag a bit. However, in my practical 'working' range of 150-350W it was really good. I am a very happy user. Thanks so much everyone for what you have achieved. |
Thanks all for the positive feedback |
Version 4.0 released :-) |
hello Wouter , is it possible to have a correct powercurve for the Tacx Flow T2250 , the current powercurve is far off and i could not find a good way to adjust it to my Garmin vector 2 powermeter reading
What i noticed , see screenshot is that the calibration of my Flow motor give an error during initialization
![tacxflow-fortiusant](https://user-images.githubusercontent.com/74739374/100339286-f9c86280-2fd9-11eb-999b-ecef29e14ace.jpg)
"calibration stopped because of unexpected resistance value
by FortiusAnt
grt jurgen
The text was updated successfully, but these errors were encountered: