Working the brake curve with the trailing ...

[DanRZ]

Hello, nowadays i'm working on my brake curve (Initial brake and trail braking). I added some mod to my pedals, to have a more smooth braking and trail better. With TinyPedal i'm trying to check on my brake curve to see if it is okay. I would love to have some more permanent display of all the brake curve. I tried to use a larger display, but it is still moving too fast.

In my idea, i would love a sort of "Freeze" from the initial brake to the full release like in this image i made :

The grey dotted line frozen on the left side represents the last braking curve.

Then on straights i can check more calmly the curve, and analyse what can be improved on the feeling i had while braking. It wil probably add too many data on the actual trailing widget, maybe another specific one would be better. Just an idea ...

And maybe add some "timestamp" or percentage of race to check the position of the start of brake on previous lap and see if it's late or not or compared to a "best lap value". I have this idea from long time ago, and tried some overaly to save "best braking" curve displayed "real time" on the actual curve to check diiference, but it was on iRacing, in C++ and poorly effective.

Maybe, you will have some other ideas on that point. Sorry for long post ...

[s-victor]

Hi, as usual, thanks for the suggestion. There are several issues and concerns.

1. There is already motec plugin that handles all pedal input recording from all laps driven by player, and can be easily analyzed, synced and compared in motec software, which is superior to any overlay function that may provide. The only downside is that player has to go back to garage to access it.
2. Adding "braking plot history" would require a lot more data to be recorded. Sooner or later someone will propose to also see throttle or clutch plot history, which will increase it further more, and consider that motec plugin already does the same thing and does it better. The dataset can grow quite big when comes to big tracks such as targa florio or isle of man. For reference, deltabest data is recorded at 200ms interval, and on targa florio, it results average of 300 to 400kb data. Now to record pedal history, the recording interval will be as low as 20ms, which means 10 times higher amount data size, and if we factor in all 3 pedal inputs + position reference, this will double the data size again, results 20 times size increase(which would be 6mb to 8mb raw data for targa florio). And the recording module has to keep recording data if there is a better lap done, which further doubles the data size loaded in memory. This may have negative impact on app performance and resource usage. One possible way to workaround this problem is to only record inputs that is being pressed.
3. In order to sync pedal history with current lap data, reference has to be "track distance into lap" instead of "time into lap", since player can brake at the same spot but at different timestamp. However, raw "track distance" value is from scoring data which updates at 200ms, so additional distance compensation has to be made. This can be done by calculate gps position value (as already used by delta module). But a small issue is that there is no guarantee that the car is traveling at the correct direction(on track) within the 200ms gap, and current car position is also affected by this inaccuracy issue, so there will be some(or a lot) margin of error with plot sync. And most importantly, real-time pedal plot is displayed as time passes (as "timestamp" reference), so when comparing to history plot that is synced by "track distance" reference, this will result big inaccuracy problem, which would make it not really useful.
4. There are already 4 plot lines, adding 1 or more history lines is likely to make the graphic more clutter and distracting unless player deactivates some of the lines.
5. A new pedal recording module is required, and it has to be always enabled like delta module for plot history function to work, but it will have very limited usage across different widgets, and potentially performance and resource usage problem.

My view is that this kind function may be best left to motec or other similar app which they are already doing a better job, and keep the widget simple and let driver focus on driving itself.

[DanRZ]

Thanks for the response. I was already thinking of Motec when creating this request.

Maybe i will have to consider using Motec, but it's asynchronous and i would love to have live feedback via a widget. Motec can do that live ?

I will try to duplicate the trailing widget and make my own brake dedicated widget, with only the last braking curve "frozen" and offseted left for a few seconds and no other data which could cause performance issues for sure.

It would need the same functionality for Throttle, but this part is more easy to evaluate purely on feel without any visual aid for me. I don't feel the same need for Throttle input.

[s-victor]

The main issues are:

1. no reliable way to sync brake plot because too many variables from driver & environment (distance, duration, road grip, even widget/module update interval, etc).
2. very limited usage and potentially high impact on performance or resources.

Motec has a lot functions which allows to offset, alignment, stretch, and other ways to compare data.

[DanRZ]

I will try to use Motec. I already tried, but it looks too "pro", like a real engineer. I want something simple, tiny 😉 and live.

I was talking of only "freezing" the brake trail for a few seconds while brake is still at zero, or just add a shadow effect.

it is probably easy to do, and would achieve what i want. And maybe plot the brake curve dotted when this mode is active.

Easy to implement i think, and i get what i want, more time to appreciate the curve.

I will try on my own branch of code and see what i can achieve.

It won't be a trailing anymore, but a freeze of last turn sequence, brake and throttle going in corner. Maybe add a going out corner switch option to freeze the Throttle curve going out apex. It won't display any other data except very last data.

[DanRZ]

Here is a video of what i achieved on iRacing. https://www.youtube.com/watch?v=kiYDakWiyko

I don't want that particular function, but it shows what can be done.

The pure line is the "last best lap" line and the filled area is the actual throttle/brake curve.

With that i was able to compare my "best lap" with my current lap in live action.

On the first brake of the video, my "best" brake was on dry, but the actual lap is wet. I brake almost the same way but i oversteered because of the wet surface. On the second turn, i released too quickly the brakes and lost the front wheels ...

I can analyze i have the ability to brake the same way, and repeat my braking point ( live ) but in that case it was inappropriate.

All that can be done with Motec, but not in that simple way and live.

Other brakes are totally screwed, lol. Forgot it was a test wet session.

[s-victor]

Understand.

There is however limitation in this system (assume history plot can be accurately synchronized with live data):

Live braking plot is compared with history plot that recorded from best lap.

If you have improved braking in one of the corners of current lap, but fails to score a new best lap (as some braking mistakes from other corners), then on the next lap you cannot see the improved plot of that specific corner, but only the old plot from best lap.

And if it is raining, then you probably never have the opportunity to beat your best lap in order to refresh best lap braking plot.

Those issues would defeat the whole purpose of finding best braking curve in live action.

An alternative solution would be record last lap plot instead of best lap. But then you may never know which is the best braking curve. Or, doing multi-lap plots comparison, but there will be significant performance impact, at this point, motec is superior for this task.

[s-victor]

Just added a new Brake performance Widget https://github.com/s-victor/TinyPedal/commit/1d60461da5017e28f05de09d293338c5184a53fd

This widget tracks max braking rate (max deceleration in g under braking) for a set period of time (set in Force module) that auto resets according to car & track condition, and calculates delta braking rate with option to show percentage braking rate gain or loss.

It also tracks total amount seconds that front or rear wheel exceeds certain amount slip ratio that counts as wheel lock (default 30%). This and combines with max braking rate can help both finding the limits of braking (in relation to track grip changes) and brake balance (bias) more easily, and achieve the similar goal that you suggested. (for details see change log.)

[DanRZ]

Nice idea. Very clever way to analyze braking performances and the way we brake "on the fly". Mixed with the widget that shows max speed on Apex, it can help on analyzing the efficiency of braking. Less visual than my idea with curve but surely more appropriate. Well done.

[s-victor]

Thanks. Here is another new option https://github.com/s-victor/TinyPedal/commit/8d0bb965d12f8b5facfe5f100412b1fafbe40b6e for Trailing Widget to show wheel lock (slip ratio) plot under braking when slip ratio has exceeded wheel_lock_threshold value. This is more visually straight forward to see your braking performance and easier to find braking limits, which also more closer to your goal.

Here is how it looks like:

The yellow dots are the slip ratio(in percentage, same as pedal input) plot that exceeded wheel_lock_threshold. A good usage would be to set wheel_lock_threshold value to optimal efficient braking slip ratio, then each time you reach this threshold you can see it direct on plot and also how much you have exceeded optimal slip ratio along with braking plot.

[DanRZ]

I just tested those two updates. Very useful. Already love it for what i needed.

I can see the max amount of brake i am able to achieve in G's without locking on start brake phase. And then see how much i can achieve of that every other corner. When i release brake too late, or wrongly, yellow dots appear in trailing and show wheel lock. With Front and Rear lock duration i can adjust my Brake Bias accordingly and help doing less locking wheels. Everything is very readable without efforts "on the fly". Great job.

Anything you can do in the "Accelerating phase" for showing slip percentage while applying too much throttle ? Same as wheel lock, but with traction loss ... It would be awesome and complementary.

Thanks for that update, which i really already appreciate. The last updates are really very useful. Nice work.

[s-victor]

Thanks for feedback, glad to hear it's working well for you. I'll test your suggestion about acceleration slip ratio plot later.

In the meantime, I just added a new Fuel calculator tool in latest commits, which you can give it a try. You can find detailed usage info in change log and user guide.

[DanRZ]

Just tested the fuel calculator, did a few lap and Reload data. Very useful to calculate stints while practicing ...

Just one remark : It would be better to have the same format on Times on the two parts. On the history, it would be more confortable with a compact format like 1'30"652 or 1:30.652 like in the widgets.

And maybe also show units in Used and Remain on the history.

[s-victor]

Thanks for feedback. I have just added your suggested units to history table and x:xx.xxx lap time format, and also added new "Starting fuel" & "Average refueling" options in latest commits.

[s-victor]

Just added wheel slip plot for Trailing Widget as you suggested in latest commit.

edit: Made more changes to layout https://github.com/s-victor/TinyPedal/commit/76abd21a855dbeead83d8a4ef09300ff2cd75f44 , added read-only color to calculation results. And Starting fuel is now grouped with Average refueling for better readability.

[DanRZ]

Tested it and everything works fine. The slip plot is an awesome addition. It helps working on gaz on turn exit. I love it. Thanks again.