cetom

So I'm going to ask a question, that once I get the answer, I'm going to feel like the dumbest person in the world...but here it goes. I'm writing a math channel that requires me to have, as one of it's parameters, lap time in seconds. RS2 reports lap time in mm.ss.ms. I don't know how to convert this to seconds.

What I'm trying to do is write a channel that tells me what percentage of a particular lap time, I'm at full throttle. Obviously, the issue is "lap time". Does anybody have an easy answer for this?

Just multiplying by 60 will not work becuase of the way rs2 reports lap time ...I think

Thank you!

Matt Romanowski

Two channels to get there

WOT = IF(GT(Throttle_Posit,90),1,0)
% WOT = lap_integ(WOT)

If you just want to compare things, it's probably easier and quicker to just do a histogram of throttle position.

cetom

matt thank you . i will give them a try

Matt Romanowski

Make sure you change the "Throttle_Posit" to whatever you have your throttle position channel named.

cetom

thanks matt, yes i did that . actually mr caddell has this in his suite of math channels but he calls it a different name
the channel WOT will get me close to what i am looking for .it does tell me how many seconds in a lap i am at wot . but it doesnt tell me exactly what i want (i think).
a wot of lets say 62 seconds in a lap that is 122 seconds is different than a lap that has wot of 62 seconds in a lap that is 125 seconds . the math to figure out the different proportions is easy . but it requires being able to input how many total second the lap is . as simple as it sounds i cant figure out a way to convert rs2 lap time to seconds
i thought one way would be to use your same formula but do it with rpm over 100 . sort of like "rpm on" . the integral of that over the lap would be the lap time in seconds . does that male sense

amso3

Ron

I would think a better way to look at this is to zoom into a lap and pick a segment like the apex of turn 1 (WG) to the first apex in the bus stop. Monitoring %WOT will be more meaningful than a full lap IMHO. There are so many variables in a full lap, it will be difficult to figure out where you have an opportunity to improve. Frankly, I just overlay the laps and look at throttle trace lap to lap, you can visually see the problem areas. You method gives you raw numbers but will be difficult to figure out what you need to do to improve.

ProCoach

Percentage full throttle (>90%) over the course of one lap is one of the best objective measures of handling/braking/traction performance improvement, and is a direct reading on driver confidence and car balance plus or minus.

Unfortunately, that's one of the major benefits of using MoTeC, for just this purpose.

Can't do it (calculate percentage of WOT over a recurring distance measure) in AIM (AFAIK). Only over time, which is a function I use as well, although much less desirable and not possible at all in R-K, VVB and many others...

cetom

thanks all
procoach , your first paragraph is what i am trying to do. sortof get a measure of how well i am driving or how aggressive i am being . for instance sometimes i feel like i am losing focus or concentration . i have a mechanism to get it back but i would like to measure it . i had all sorts of ideas of what i could measure like minimum speed following aLat Gspike . but when it was all said and done WOT% (as a percent of total single lap) would take all that into account ,.
ill keep experimenting
thanks

Matt Romanowski

I think the histogram and zooming (like Jerry said) will be your easiest way. Check out the photos to see how you could do it very quickly and get a good visual representation.

You can do what you want, but it takes some work. You can export to Excel then do the calculations to get a time based average for full throttle, but I think it's a lot of work for a little gain.

rkirshner

thank you very much

Caddell

Ah Peter... I think I can help you! Below are a couple of math channels (in AiM syntax) to create the % of WOT vs Time, and another to create the % of WOT vs Dist.

In this case (but it could be re-written to include everything) we first need to build a "Full_TPS On" channel at >90% TPS:
Full_TPS On: IF(GT(Throttle,90),1,0)

Here is the math channel to show the % of WOT vs Time per lap:
Full_TPS LapPT: (Full_TPS LapT*100)/time()

Here is the math channel to show the % of WOT vs Distance per lap:
Full_TPS LapPD: lap_integ(Full_TPS On*Speed*MPH2FTS)*100/lap_integ(Speed*MPH2FTS)

Of course as Matt mentioned, you need to replace the 'Throttle' value with your specific throttle position channel name. Do the same and replace the 'Speed' value with your specific speed channel name.

And finally, the MPH2FTS constant is 1.46667 in AiM and if that constant has been removed or changed, this value can just be input directly into the formula.

ProCoach

Bless you, Roger!

That would be too bad, because that is one of the primary measures Jorge Segers uses to evaluate driver commitment and/or car changes... and one of the reasons why there are so few "casual" data users. Either nothing or ALL IN! Hahahahaha! People don't have time to work that hard.

I can't afford those additional steps and extra time in my workflow, and I am sure you can't either at a T/A weekend!

I'll try Roger's math on my own stuff and during this coming weekend on Yonker, Pray and Evans.

ProCoach

It works!

I have an odd little anomaly at the end of the lap where there is a screwy correction, but the numbers look right...

The map is TPS percentage, real-time.

Matt Romanowski

I've noticed that the end does some weird things on a couple of channels. If you do a slowing channel, has the weird bit at the end.

Caddell

What you are seeing at the end of the lap is the very small (but exaggerated viewing with % math channels) differences between the length of the actual lap vs the computed length that is based on the track map lap used. There will always be some difference at the end of a lap due to the way the software is written to best handle differences in every lap length. Nothing to worry about, the math is correct right up to the very end.

Also, you will find that if you step up the 'sampling rate' (10Hz to maybe 50Hz) that you use during the math channel calculation, this will reduce the effect.