[REL] TinyPedal - open source overlay for rF2 (Pacenotes,Radar,FFB,Deltabest,Relative,Fuel Calculator)
2.30.0 (2025-06-04)
which allows to quickly transfer selected settings and options from currently loaded preset to another preset.
This new addition can make life much easier for users with a lot presets and options to manage and keep them updated with latest changes.
See "Preset Transfer" section in User Guide for usage and example.
Note, when number of digits is less than expected, extra leading zero or decimal place will be added to fill the gap.
Release v2.30.0 · s-victor/TinyPedal · GitHub
- Major change
which allows to quickly transfer selected settings and options from currently loaded preset to another preset.
This new addition can make life much easier for users with a lot presets and options to manage and keep them updated with latest changes.
See "Preset Transfer" section in User Guide for usage and example.
- Wheels Module
- Weather Widget
Note, when number of digits is less than expected, extra leading zero or decimal place will be added to fill the gap.
Release v2.30.0 · s-victor/TinyPedal · GitHub
Last edited:
svictor
Registered
Just a heads up, with today's LMU, there are some major changes in LMU's Rest API, and several API data addresses are no longer available (or may be changed), so some data will no longer be able to display in current v2.30.0 TinyPedal version.
Note, some API data (virtual energy, damage, etc) can still be displayed by using old v2.28.1, as RepairAndRefuel address is still available in today's game update, so if you currently really need those data it, use v2.28.1 instead ( https://github.com/s-victor/TinyPedal/releases/tag/v2.28.1 ).
I'll investigate and see what can be done (this may take time, please be patient), until then.
Cheers
Note, some API data (virtual energy, damage, etc) can still be displayed by using old v2.28.1, as RepairAndRefuel address is still available in today's game update, so if you currently really need those data it, use v2.28.1 instead ( https://github.com/s-victor/TinyPedal/releases/tag/v2.28.1 ).
I'll investigate and see what can be done (this may take time, please be patient), until then.
Cheers
Last edited:
svictor
Registered
2.30.1 (2025-06-12)
https://github.com/s-victor/TinyPedal/releases/tag/v2.30.1
This update updated all Rest API related data accessing to work with LMU's June update. See change log for details.
https://github.com/s-victor/TinyPedal/releases/tag/v2.30.1
This update updated all Rest API related data accessing to work with LMU's June update. See change log for details.
- Major change to API accessing
- Updated URL addresses for accessing data from LMU's Rest API (due to changes from June update), including new penalty time data that used for accurate pit time estimate.
- Virtual energy, brake wear, vehicle damage, pit stop related data are now read from "RepairAndRefuel" URL address (same as in v2.28.1).
Important note:
"RepairAndRefuel" URL address previously was known to have chance to cause MFD pitstop menu flickering issue if accessed at high frequency. This flickering issue has been acknowledged by game developer, but not yet fixed by game.
"RepairAndRefuel" is the only address for accessing those important data from LMU Rest API (as of LMU June update), currently there is no other alternatives.
This "flickering issue" should not be a concern for user using only TinyPedal, as the default "update interval" in RestAPI Module is set on 100ms.
For user concerned or experienced with this issue, you can either increase the value of "update interval" in RestAPI Module (such as "500" or "1000"); or, disable "RestAPI Module" entirely (which then those crucial data will not be available).
Also note:
There are currently other third-party APPs or Plugins that also have access to this "RepairAndRefuel" URL address, and running them at the same may have higher chance to trigger MFD "flickering issue". - Removed "enable_pit_strategy_access" option from RestAPI Module, this option no longer works due to game API changes.
- Various improvements and optimization to game API accessing.
Woodee
Registered
Hi svictor,
I don't know if this is beyond the scope of Tinypedal or even possible with rf2.
When in specate mode is it possible an app (or Tinypedal in this case) can capture user selected events like yellow flags, changes of position, car contact, recent DNF, car pitting etc... and display them in a visible event log?
The reason I ask this is to help for broadcast purposes. We already use part of the hud and track map to keep track of the action.
As far as the track map goes, are the colours for the dots not able to display the cars on the lead lap differently from lapped cars when in spectate mode?
I don't know if this is beyond the scope of Tinypedal or even possible with rf2.
When in specate mode is it possible an app (or Tinypedal in this case) can capture user selected events like yellow flags, changes of position, car contact, recent DNF, car pitting etc... and display them in a visible event log?
The reason I ask this is to help for broadcast purposes. We already use part of the hud and track map to keep track of the action.
As far as the track map goes, are the colours for the dots not able to display the cars on the lead lap differently from lapped cars when in spectate mode?
svictor
Registered
Thanks for suggestion.
An incident report widget (or logging dialog) should be possible. I'll add to wish list and see what can be done.
---
As for track map, lapped color indicators (which shows purple & blue color for lap ahead/behind cars) is only available when "Enable Multi Class Styling" option is disabled.
The reason for this is that multi class has their own base color for each class, adding additional lapped color on top of multi class color can make the track map a chaos to watch (all kinds color mixed together, overlapping each other). But if we ignore visual problem, it is possible to show lapped color via outline, so it be like:
Draw green base color (background) for GT3, then draw purple outline for cars that 1 or more laps ahead of you, and draw blue outline for cars that 1 or more laps behind. Same thing goes for Hypercar, etc.
There is however a major drawback. If the vehicle class color is blue (such as LMP2) or purple, then you cannot really distinguish the outline color from the base color unless you change the class or indicator color.
For example, below pic shows how it may look like if we add lapped color to multi class track map, there are several color combination from P2 & Hypercar class that are difficult to distinguish from lapped colors. And this can get worse when a lot cars are moving on map.
A solution to the same color problem could be to add a little bit gap between base circle background and outline. However, doing that requires to draw two circles for one car, since it is not possible to add gap for a single circle drawing operation, which is bad for performance. Ideally we want as little drawing operation as possible to get things done for best performance, and gap may also make the map more chaotic when looking at, so this is not an optimal solution in my opinion.
But despite the visual drawback, I could probably add it as an option for the outline indicator.
An incident report widget (or logging dialog) should be possible. I'll add to wish list and see what can be done.
---
As for track map, lapped color indicators (which shows purple & blue color for lap ahead/behind cars) is only available when "Enable Multi Class Styling" option is disabled.
The reason for this is that multi class has their own base color for each class, adding additional lapped color on top of multi class color can make the track map a chaos to watch (all kinds color mixed together, overlapping each other). But if we ignore visual problem, it is possible to show lapped color via outline, so it be like:
Draw green base color (background) for GT3, then draw purple outline for cars that 1 or more laps ahead of you, and draw blue outline for cars that 1 or more laps behind. Same thing goes for Hypercar, etc.
There is however a major drawback. If the vehicle class color is blue (such as LMP2) or purple, then you cannot really distinguish the outline color from the base color unless you change the class or indicator color.
For example, below pic shows how it may look like if we add lapped color to multi class track map, there are several color combination from P2 & Hypercar class that are difficult to distinguish from lapped colors. And this can get worse when a lot cars are moving on map.
A solution to the same color problem could be to add a little bit gap between base circle background and outline. However, doing that requires to draw two circles for one car, since it is not possible to add gap for a single circle drawing operation, which is bad for performance. Ideally we want as little drawing operation as possible to get things done for best performance, and gap may also make the map more chaotic when looking at, so this is not an optimal solution in my opinion.
But despite the visual drawback, I could probably add it as an option for the outline indicator.
Corti
Registered
Btw guys....the last update it's ready for download 
https://github.com/s-victor/TinyPedal/releases/tag/v2.32.1
https://github.com/s-victor/TinyPedal/releases/tag/v2.32.1
Javier G R
Registered
Hi svictor.
Thx a lor for your fantastic app. I cannot play LMU without it.
This morning training for the multidriver event I have seen a mismatch in tyre temps between TinyPedal and the game MFD.
It is not a constant amount. The difference increases with the temp. The higher, the most difference. Affect the four tyres. Seems any calculated value multiplier.
For instance: game overlay 85 degrees; Tiny: 70 degrees
I was running GT3 cars.
Could you check / fix it in a future release, pls?
Thx and regards.
Thx a lor for your fantastic app. I cannot play LMU without it.
This morning training for the multidriver event I have seen a mismatch in tyre temps between TinyPedal and the game MFD.
It is not a constant amount. The difference increases with the temp. The higher, the most difference. Affect the four tyres. Seems any calculated value multiplier.
For instance: game overlay 85 degrees; Tiny: 70 degrees
I was running GT3 cars.
Could you check / fix it in a future release, pls?
Thx and regards.
Try Tyre inner layer widget
svictor
Registered
Hi @Javier G R , thanks for your support.
To answer your question about tyre temperature mismatch:
Just like @sepi said, what you should look for is the inner layer average temperature of each tyre in TinyPedal.
However, since LMU 1.0 update, this problem is more complex than that, which I will explain below.
First thing first:
There is no such thing as "temperature calculation error or bug" in TinyPedal. The tyre temperature telemetry data is directly pulled from RF2 Sharedmemory API.
What temperature you see on widget is the values that read directly through RF2 Sharedmemory API (with only units conversion from Kelvin). And you never have to doubt or worry about seeing wrong values. And you can always check out the source code to see if there is any calculation error.
Note, there are three different types of tyre temperature readings available from RF2 Sharedmemory API, they are:
1. Tyre surface rubber temperature
2. Tyre inner layer rubber temperature
3. Tyre carcass temperature
---
Now about mismatch issue with LMU MFD:
The common misunderstanding is that many think that LMU MFD temperature is the carcass temperature, but that is never the case: values from LMU MFD are not carcass temperature.
So, you may wonder what this temperature is represented in LMU's MFD.
This is actually a little more complex, which comes in two parts:
Firstly, before LMU v1.0, the MFD tyre temperature is the average inner layer rubber temperature, which means if you disable "Show Inner Center Outer" option from "Tyre inner layer Widget", you will get exact same reading as seen from LMU MFD. And at the time I wrote this post (as after LMU v1.0 update), this still stands TRUE for LMGT3 cars.
However, there is a major twist comes after LMU v1.0, for HYPERCAR class, the MFD tyre temperature readings no longer match the "Tyre inner layer rubber temperature" from RF2 Sharedmemory API.
So, is it a bug in RF2 Sharedmemory API? No, I don't think so, because the values still match the inner layer readings from LMGT3 class. The mismatch only happens to HYPERCAR class.
So, what MFD tyre temperature readings are representing? Unfortunately, it is currently unknown. However, from pure observation, LMU's MFD tyre temperature (from HYPERCAR class) is somewhere between surface temperature and inner layer temperature. It is not exactly the average of the two surface and inner temperature, but it is quite close to that. It is also unknown whether this MFD temperature is actually a game display bug or not, since the readings are correct for LMGT3.
To conclude, after LMU v1.0 update:
1. LMU's MFD tyre temperature readings for LMGT3 class, is the average inner layer rubber temperature (of each tyre) that matches the same inner layer data from RF2 Sharedmemory API.
2. LMU's MFD tyre temperature readings for HYPERCAR class, does not match any tyre temperature data from RF2 Sharedmemory API. And currently it is unknown what this MFD temperature represent exactly, but it is like somewhere between surface and inner rubber temperature (or game display bug?).
In any case, you should not have to worry about this mismatch. Feel free to share this post to others who might also have similar questions about LMU MFD temperature mismatch.
I also updated a short explanation in FAQ page:
https://github.com/s-victor/TinyPed...ch-value-from-lmus-multi-function-display-mfd
Cheers
To answer your question about tyre temperature mismatch:
Just like @sepi said, what you should look for is the inner layer average temperature of each tyre in TinyPedal.
However, since LMU 1.0 update, this problem is more complex than that, which I will explain below.
First thing first:
There is no such thing as "temperature calculation error or bug" in TinyPedal. The tyre temperature telemetry data is directly pulled from RF2 Sharedmemory API.
What temperature you see on widget is the values that read directly through RF2 Sharedmemory API (with only units conversion from Kelvin). And you never have to doubt or worry about seeing wrong values. And you can always check out the source code to see if there is any calculation error.
Note, there are three different types of tyre temperature readings available from RF2 Sharedmemory API, they are:
1. Tyre surface rubber temperature
2. Tyre inner layer rubber temperature
3. Tyre carcass temperature
---
Now about mismatch issue with LMU MFD:
The common misunderstanding is that many think that LMU MFD temperature is the carcass temperature, but that is never the case: values from LMU MFD are not carcass temperature.
So, you may wonder what this temperature is represented in LMU's MFD.
This is actually a little more complex, which comes in two parts:
Firstly, before LMU v1.0, the MFD tyre temperature is the average inner layer rubber temperature, which means if you disable "Show Inner Center Outer" option from "Tyre inner layer Widget", you will get exact same reading as seen from LMU MFD. And at the time I wrote this post (as after LMU v1.0 update), this still stands TRUE for LMGT3 cars.
However, there is a major twist comes after LMU v1.0, for HYPERCAR class, the MFD tyre temperature readings no longer match the "Tyre inner layer rubber temperature" from RF2 Sharedmemory API.
So, is it a bug in RF2 Sharedmemory API? No, I don't think so, because the values still match the inner layer readings from LMGT3 class. The mismatch only happens to HYPERCAR class.
So, what MFD tyre temperature readings are representing? Unfortunately, it is currently unknown. However, from pure observation, LMU's MFD tyre temperature (from HYPERCAR class) is somewhere between surface temperature and inner layer temperature. It is not exactly the average of the two surface and inner temperature, but it is quite close to that. It is also unknown whether this MFD temperature is actually a game display bug or not, since the readings are correct for LMGT3.
To conclude, after LMU v1.0 update:
1. LMU's MFD tyre temperature readings for LMGT3 class, is the average inner layer rubber temperature (of each tyre) that matches the same inner layer data from RF2 Sharedmemory API.
2. LMU's MFD tyre temperature readings for HYPERCAR class, does not match any tyre temperature data from RF2 Sharedmemory API. And currently it is unknown what this MFD temperature represent exactly, but it is like somewhere between surface and inner rubber temperature (or game display bug?).
In any case, you should not have to worry about this mismatch. Feel free to share this post to others who might also have similar questions about LMU MFD temperature mismatch.
I also updated a short explanation in FAQ page:
https://github.com/s-victor/TinyPed...ch-value-from-lmus-multi-function-display-mfd
Cheers
Javier G R
Registered
Once more, your explanations are an open book, svictor.
Always learning from them. Thanks again for all the time you put in the app and in the answers to all of us. They are priceless.
Always learning from them. Thanks again for all the time you put in the app and in the answers to all of us. They are priceless.
svictor
Registered
Tip to Replace Brakes flickering issue
As many know, the MFD "Replace Brakes" flickering issue has been a hot topic since LMU 1.0 update.
Many have been worrying about whether the MFD "Replace Brakes" "YES/NO" option is actually indicating YES or NO while flickering, which could potentially ruin race.
Here is a simple tip that may help you to determine whether "Replace Brakes" option is actually on YES or NO (regardless whether MFD is flickering):
1. Start TinyPedal, make sure "RestAPI" Module is enabled.
2. Enable "Pit Stop Estimate" widget.
3. Open in-game MFD Pitstop menu, scroll to last line which says "Replace Brakes". You should see that this option is flickering YES/NO non-stop.
4. Now press MFD increment (or decrement) key once, which will change "Replace Brakes" option state.
5. Once done, you will immediately see that "Replace Brakes" option is on YES, and flickering is stopped.
6. At the same time, check out the "stop" column value on "Pit Stop Estimate" widget, which will show an additional 120 seconds added on top of previous value. And this +120 value is the indication of "Replace Brakes" option being actually turned ON!
(Note, currently vehicles in LMU takes 120 seconds to replace brakes.)
7. Now press MFD increment (or decrement) key again, and you will immediately see "Replace Brakes" option starts flickering again between YES and NO. However at the same, the +120 value will be removed from the "stop" column value on "Pit Stop Estimate" widget, which indicating that "Replace Brakes" option is actually turned OFF!
Below recording shows 11.2 seconds normal pit stop time while "Replace Brakes" is flickering (NO), and 131.2 (11.2+120) seconds while "Replace Brakes" is not flickering (YES):
TLDR:
If you see there is +120 seconds added to "stop" column value on "Pit Stop Estimate" widget right after changed "Replace Brakes" option in MFD menu, it means "Replace Brakes" option is turned ON (YES), otherwise it is OFF (NO).
Disclaimer:
Be aware that above tip may not work if game API gets updated in future (this has happened once in LMU June Update), always test before trying it in race!
Good luck.
As many know, the MFD "Replace Brakes" flickering issue has been a hot topic since LMU 1.0 update.
Many have been worrying about whether the MFD "Replace Brakes" "YES/NO" option is actually indicating YES or NO while flickering, which could potentially ruin race.
Here is a simple tip that may help you to determine whether "Replace Brakes" option is actually on YES or NO (regardless whether MFD is flickering):
1. Start TinyPedal, make sure "RestAPI" Module is enabled.
2. Enable "Pit Stop Estimate" widget.
3. Open in-game MFD Pitstop menu, scroll to last line which says "Replace Brakes". You should see that this option is flickering YES/NO non-stop.
4. Now press MFD increment (or decrement) key once, which will change "Replace Brakes" option state.
5. Once done, you will immediately see that "Replace Brakes" option is on YES, and flickering is stopped.
6. At the same time, check out the "stop" column value on "Pit Stop Estimate" widget, which will show an additional 120 seconds added on top of previous value. And this +120 value is the indication of "Replace Brakes" option being actually turned ON!
(Note, currently vehicles in LMU takes 120 seconds to replace brakes.)
7. Now press MFD increment (or decrement) key again, and you will immediately see "Replace Brakes" option starts flickering again between YES and NO. However at the same, the +120 value will be removed from the "stop" column value on "Pit Stop Estimate" widget, which indicating that "Replace Brakes" option is actually turned OFF!
Below recording shows 11.2 seconds normal pit stop time while "Replace Brakes" is flickering (NO), and 131.2 (11.2+120) seconds while "Replace Brakes" is not flickering (YES):
TLDR:
If you see there is +120 seconds added to "stop" column value on "Pit Stop Estimate" widget right after changed "Replace Brakes" option in MFD menu, it means "Replace Brakes" option is turned ON (YES), otherwise it is OFF (NO).
Disclaimer:
Be aware that above tip may not work if game API gets updated in future (this has happened once in LMU June Update), always test before trying it in race!
Good luck.
I did the driver swap event with the replace brakes problem, I took the risk and it didn't change the brakes in any stop.
svictor
Registered
There is a "Spectate" mode in this app, which allows you to select and watch other AI drivers or online players, which most data can be seen this way. However, fuel & tyre data from other AI or players usually are not available, depends on server or game setting.
If you play LMU, remaining virtual energy data is currently available for all players driving hypercar and GT3, and can be seen from Standings/Rivals/Relative Widget of this app.
Thanks for sharing your experience.
My friends also did 3 driver swap races in the first 6hr Qatar events, and none of them encountered any issue while using this app (they never touched that "Replace Brakes" option in MFD in race).
Currently, there is generally no reason to touch "Replace Brakes" option for race that shorter than 12 hours, since those brakes have very long lifespan and extremely durable. There is very few reports about brake failure in LMU so far, I recalled recently there is one person reported a failure after over 20 hours of driving in a 24 hours singleplayer race. (though, anything can change with future game updates.)
Last edited:
Ah, this works flawlessly, cheers!
(2025-08-10) Release v2.33.0 · s-victor/TinyPedal · GitHub
Fuel Calculator
Fuel Calculator
- [New]Add "pit stop preview" bar on the left side of calculator panel, which visualizes pit stops as blue marks and stint laps as grey marks.Each pit stop mark shows a reference lap completion number. Total estimated number of race laps is displayed at bottom of the bar.Note, when "Energy consumption" value is higher than zero, pit stops and stint laps from preview bar will be calculated based on energy usage. Stint lap mark may not be displayed if there is not enough space to draw.
- "Starting Fuel" and "Starting Energy" values now affect "total pit stops" outcome, as well as visualized on "pit stop preview" bar.
- Add togglable options for each accessible data from Rest API.
- Add "enable_garage_setup_info" option, which enables access to "garage setup" data (RF2 & LMU). This is required for accessing various vehicle setup data.
- Add "enable_session_info" option, which enables access to "session" data (RF2 & LMU). This is required for accessing various session data, such as time-scale.
- Add "enable_weather_info" option, which enables access to "weather" data (RF2 & LMU). This is required for showing weather forecast.
- Add "enable_vehicle_info" option, which enables access to "vehicle" data (LMU only). This is essential for accessing "virtual energy", "brake wear", "vehicle damage", "pit stop timing" data.
- Add "high_battery_threshold, low_battery_threshold" options (requested by user "H4dro"), which set percentage threshold for displaying low or high battery charge warning indicator.Default high threshold is "95" percent (default color purple), low threshold is "10" percent (default color red).
- Changed default background color to blue (old color was black) for normal battery charge level for Battery Widget. Existing setting won't be affected.
- [New]Add "show_lap_difference_outline" option (requested by user "Woodee"), which shows outline color based on lap difference (ahead or behind) between player and opponents. This option is disabled by default.
- Note, both outline color and width can be customized.
- Fixed a rare issue where module data would not update after restarted module.
- Fixed an issue where virtual energy usage from "Lap time history Widget" sometimes fails to load due to desync.
- Various optimization.
Attachments
2.33.1 (2025-08-22)
- [New]Check for Updates
- Add "Check For Updates On Startup" global option (requested by user "coasting-nc"), which enables automatically checking for updates on startup, and displays notification message in main window.
This option is enabled by default, and can be disabled in "Application" dialog from "Config" menu in main window.
Note, this option is checked only once per startup, and notification message will only be displayed if new updates is available.
This option only checks for new updates info, it does not provide updates downloading or installing feature. - Add "Check for Updates" option to "Help" menu in main window, which allows to manually check for updates. This option always displays notification message in main window.
- Add notification message for "Check for Updates" in main window. Click on the notification message will bring up a menu, where user can click "View Updates On GitHub" to open "Latest Releases" page in web browser, or "Dismiss" the message.
- Add "Check for Updates" message to console output.
- Add "Check For Updates On Startup" global option (requested by user "coasting-nc"), which enables automatically checking for updates on startup, and displays notification message in main window.
- Spectate mode
- Now lists player names in alphabetical order, making it easier for finding specific player.
- Relative finish order, Track map Widget
- Fixed a typo with option name "predication" (reported by user "PeterVRC"). Existing setting won't be affected.
- Misc
- Small optimization.
Last edited: