TinyPedal is a Free and Open Source telemetry overlay application that displays real-time telemetry info on-screen for racing simulation games.

The primary focus of TinyPedal project is on minimalist design, light-weight and efficiency, with extensive user customization, data analysis, and editing tools.

TinyPedal is free software, anyone is free to download, use, modify, or distribute it under the terms of the GNU General Public License. See License for more info.

For a list of supported games, see Requirements.

The fundamental purpose of TinyPedal project is to create a racing simulation overlay application that is freely accessible to anyone.

Since the initial release in March 2022, TinyPedal project continues to evolve with the help from various contributors and sim-racing community.

More importantly, we created TinyPedal for fun, and we are happy to share with everyone. Just have fun!

Please follow Contributing Guidelines for how to report issue, request feature, or contribute code.

Features may be missing or not implemented for various reasons, notably:

• Lack of time, developer, or interest. It may take a long time to implement certain features.

• Technical issues that prevent certain features from implementing.

• Missing game API data, which makes it impossible to add certain features. Consider to seek game developer to add missing data to their game API.

• Performance. Some features may have negative impact on efficiency and performance of this project, and unlikely to be implemented.

Most of the features were implemented as response to hundreds of user requests over the years.

Many features are designed for specific purposes, which may not be useful otherwise. Some features may also seem confusing or complex at first, feel free to check out User Guide for detailed explanation and use case.

There are usually wild speculations on third party APPs that would cause game performance issue when game is stuttering.

Fortunately, TinyPedal comes with a System Performance Widget, which helps user to monitor CPU and Memory usage from both TinyPedal and Operation System. So if there is any game stuttering or performance issue, be sure to check out System Performance Widget first to rule out any unrelated performance issue that may be caused by other things.

See System Performance section in User Guide for details.

Notes on G-Sync (or similar issues):

Since currently TinyPedal only utilizes CPU, it may not be compatible with G-Sync, especially when game is running in borderless or windowed mode. So it is possible that game may stutter if TinyPedal is running while G-Sync is enabled, as already reported by a number of users who running with G-Sync.

Unfortunately, it is not possible for TinyPedal to support G-Sync.

This can be easily done by toggling on Lock Overlay option from Overlay menu in main window (or from tray menu). When overlay is locked, widgets cannot be clicked on, nor gaining focus over game window.

It is recommended to Lock Overlay after done with widget position adjustment, to avoid clicking on widgets accidentally.

Make sure the game is not running as administrator. TinyPedal will not be able to detect keyboard state if the game is running under administrator privilege.

Alternatively, though not recommended, if you really need to run the game as administrator, you can also run TinyPedal as administrator, which allows it to access keyboard state with administrator privilege.

For big screen such as 2K or 4K resolution, the recommended way is to enable High DPI Scaling mode by toggling Scale button on main window status bar, which allows auto-scaling all widgets size and position according to system scaling setting.

For individual widget, size can be adjusted from widget Config dialog. The size of most widgets is determined by font size option, while some others such as Radar or Track map widgets use specific display size or scale options for size adjustment.

To quickly increase or decrease size of most widgets, adjusting Font Size Addend option in Global Font Override dialog from main Config menu. For example, set Font Size Addend value to +10 will make most widgets nearly doubled size.

This is not possible, as overlay widgets are not web-based.

Generally it is not recommended to disable any data modules from Module tab.

Each data module provides important data, and shares among different modules and widgets. Disabling one module could result other modules or widgets not working correctly.

For example, Fuel Module requires lap time pace data that generated by Delta Module to correctly calculate refuel estimate. Vehicles Module requires classes and standings data that generated by Relative Module to process additional vehicle data that used in many widgets. Disabling any of those modules will cause other modules not function correctly.

Finally, all data modules are highly optimized, there will not be noticeable performance difference by disabling them.

Just extract all contents that are inside TinyPedal folder from a newer released ZIP file into a previous version of TinyPedal folder and override same files; the same thing can also be done to downgrade a newer version to older ones.

Note, a newer released version will auto-update old user setting and add new setting after first-time loading. It may still be a good idea to manually backup old setting before updating.

All build files currently available from Releases page were remotely built from source code using automated github actions, which the entire build > upload > release process is fully automated and there is no intervention. Additional SHA256 hash sum for each build file was also generated during the build process and included in release notes. Workflow configuration code is in .github/workflows directory in repository, and build log can be viewed from Workflows in Actions page. As long as the build files are downloaded from Releases page with matching SHA256 hash sum, those files are clean and safe to use.

Alternatively, for those still hold doubts and worried about false positive reports, see Run from source or Build executable for windows for instructions on how to run or build the app from source code.

No, TinyPedal cannot crash game or cause game to malfunction. TinyPedal only accesses (reads) shared memory data that output by shared memory plugin. TinyPedal does not directly interact with game.

It works as following:

[Game API] <---> [Shared memory plugin] ---> [Shared memory] <--- [TinyPedal]

1. By enabling Shared memory plugin in game, game API sends data to Shared memory plugin.
2. Shared memory plugin gets data from game API, then outputs API data into Shared memory blocks.
3. TinyPedal reads data from Shared memory blocks, then displays data on screen.

No, TinyPedal cannot do that. Same with shared memory API, TinyPedal only reads API data from Rest API, TinyPedal does not change or modify game API data.

There is a common misunderstanding that accessing LMU's Rest API can cause game setting to be changed, but this is not entirely true.

Rest API uses specific HTTP methods, notably the GET, POST, PUT, DELETE methods, where only POST, PUT, DELETE methods can modify game API data, while GET method can only retrieve and read data. That means any third party software that uses one of the POST, PUT, DELETE methods can modify API data, while GET method cannot.

However, in TinyPedal, Rest API accessing is solely based on HTTP GET method (feel free to check out source code if in doubt), which only retrieves data from game API, and this HTTP GET method cannot change or modify game API data, as mentioned above.

If you see game API/data changed, check out other third party software or plugins that may have been accessing game's Rest API using POST, PUT, or DELETE methods which may cause unwanted issues.

For those still hold doubts, you can always disable Rest API accessing by turning off Enable RestAPI Access option in Telemetry API dialog.

Some reference links to HTTP methods, explanations, and specifications:

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods
• https://httpwg.org/specs/rfc9110.html#GET

For windows platform, currently it is only possible to capture overlay by using Display Capture to capture entire screen in OBS.

For Linux platform, may need to turn off Enable Bypass Window Manager option from main menu -> Compatibility dialog.

Game does not provide track map data. Map data has to be recorded from player's driving route, which requires at least one complete & valid lap (not counting pit-out lap) to be done first in order to generate map. And map recording function is handled by Mapping Module, make sure it is enabled.

Note, Track map Widget will show a circular map if track map data has not been recorded yet.

It is important to note that TinyPedal is not made or designed for VR gaming purpose.

Although various contributors have done various efforts to add supports to VR as much as possible in TinyPedal, there are limitations to what can be done.

VR functionality can only be achieved via other third-party software, where we have no control of how things will work in other third-party software. That means any VR related-issue (or VR feature request) you may encounter, should be reported to those third-party software instead.

Finally, currently there are very few developers here who are actually owning a VR device, which means it is impossible to help with testing or answering VR related questions. For this reason, it is recommended to seek help from other users who may be experienced with VR instead.

TinyPedal does not natively support displaying overlay in VR.

However there are some VR programs capable of projecting application windows into VR. Some known third party programs include CrewChief, OpenKneeboard, etc.

VR Compatibility option does not by itself support to show overlay in VR; this option only enables the ability for other programs to discover and project overlay windows into VR.

You will still need a third party program (such as OpenKneeboard) to project overlay windows (widgets) into VR.

A common issue for using Windowed or Borderless mode is that frame rate would become unstable or stuttering. Here are a few tips that could help improve smoothness:

• Turn on and set maximum frame rate in graphics card control panel. Limiting maximum frame rate is usually the most effective way to stabilize FPS. All you need is to set maximum frame rate value slightly higher than your current monitor refresh rate. For example, if your monitor refresh rate is 60hz, then set maximum frame rate to 70 would be enough.
• Turn off Fullscreen Optimizations from game's executable file under windows 10 or 11.
• Reduce Post Effects setting in game.

1. Make sure required plugins are installed and enabled in game. See Requirements section for details.
2. Make sure Spectate mode is disabled in TinyPedal main config window Spectate tab.

1. Make sure Enable RestAPI Access and related data options are enabled in Telemetry API dialog.
2. Make sure URL Port setting in Telemetry API dialog matches WebUI port value from game setting file.
   For LMU, setting file is found in UserData\player\Settings.JSON.
   For RF2, setting file is found in UserData\player\player.JSON.
   See User Guide Telemetry API section for details.
3. Make sure no firewall or antivirus program that would block TinyPedal from accessing network as required to connect to game's Rest API.

Make sure TinyPedal can connect to game's Rest API. Since brand logo depends on vehicle name data from Rest API, you will need to make sure TinyPedal has access to network and game's Rest API. See above FAQ about Rest API for how to check and setup Rest API connection correctly.

Next, use Vehicle Brand Editor to import vehicle brand data from game's Rest API.

Prepare brand logo file as described in User Guide Brand Logo section.

The tyre temperature values, as displayed on LMU MFD, is not carcass temperature, hence the readings are different (this is not bug).

Currently it is unknown which source of tyre temperature it represents in game's MFD, but its value appears to be somewhere in between tyre surface and inner layer temperature.

Currently RF2 API does not provide separate compound info for tyres on the same axle, so it is not possible to show left and right compounds separately. Due to this limitation, when set left tyre compound differently than right tyre, the API will only output and show compound info from left tyre.

Some vehicles (such as DLC) have certain telemetry data disabled from game API outputs for various reasons, which is not available for displaying.

There are some hybrid and electric vehicles in RF2 that are not based on the new electric motor and battery charge system, thus no battery usage info available from them.

Due to limitation from game's API, some multi-player session data, such as weather forecast and track clock time scale, currently cannot be synchronized with game server, which is why they cannot be displayed correctly.

RF2 API only provides a generic detached-parts detection boolean value, which returns True if any parts were detached. It cannot tell which parts were lost. So in order to avoid confusion, detached parts display is not provided.

This is normal behavior, the damage values reported by RF2 API are not 100% same as in-game HUD, which they sometimes report slightly different readings.

Relative refueling is the primary refueling mechanism as seen from RF2 and other sim titles, while absolute refueling is an alternative mechanism currently used in LMU.

Differences between relative and absolute refueling:

• Relative refueling value shows total amount additional fuel required to finish the remaining race length, which matches relative refueling mechanism in RF2: amount additional fuel to add on top of remaining fuel in tank.

• Absolute refueling value shows absolute total amount fuel required to finish the remaining race length, which matches absolute refueling mechanism in LMU: amount total fuel to fill tank up to.

Absolute refueling display is currently supported in Fuel Widget, Relative finish order Widget, and Virtual energy Widget. To enable absolute refueling display, simply toggle on show_absolute_refueling or show_absolute_refilling options in those widgets.

Unlike relative refueling, absolute refueling shows the total amount fuel required to finish the remaining race length. When more lap distance is traveled (as more race length completed), there is less remaining race length to be done, so is less absolute total amount fuel value displayed. And absolute refueling value will never go below zero, unlike relative refueling value that excludes the fuel in tank and can be negative.

The simplified formulas for absolute and relative refueling are:

absolute refueling = total remaining laps x fuel consumption per lap

relative refueling = total remaining laps x fuel consumption per lap - remaining fuel in tank

The only difference here is that relative refueling excludes remaining fuel in tank.

Adjusting refueling level according to absolute refueling value displayed on Fuel or Virtual energy Widget at beginning of current lap before going into pit. When approaching pit entry or pit spot, make one final adjustment to refueling level according to current absolute refueling value, which would be only a few clicks away. And it's fine without doing that final adjustment, as it will be only an extra lap of fuel to carry at most.

Important note: refueling values displayed on Fuel Widget and Virtual energy Widget only concern local player's lap time pace and progression, while race leader's lap time pace and progression may affect whether there will be an extra final lap after race timer stops. For this reason, a specially designed widget called Relative finish order Widget is provided, which can be used to predict final lap progression and extra lap chances between local player and race leader, with multi-class and pit stop duration taken into consideration. See Relative finish order section in User Guide for detailed explanation.

The easiest way is by checking pits column in Fuel or Virtual energy Widget, which indicates amount pit stops required if making a pit stop at the end of current stint; or early column, which indicates amount pit stops required if making a pit stop at the end of current lap. See Fuel section in User Guide for detailed explanation.

Another way is by comparing remaining fuel value with absolute refueling value. If absolute refueling value is higher than remaining fuel value, then additional pit stops and refueling is required.

Because every track has pit lane entry position located at different track sections, some pit lane entries are close to finish line, while others may be far away from finish line. The entry position differences could result huge amount margin of errors, and not accurate for absolute refueling.

For example, Sebring circuit (WEC configuration) has pit entry located at roughly 28% (4200m) of the track length (5800m) from finish line, which means each pit stop refueling requires an additional of 28% lap of fuel in order to reach finish line. If one refuels according to the end of lap estimates, he will lose that 28% lap of fuel that is vital for finishing the race.

As such, showing absolute refueling value at the end of current lap is inaccurate. While it is possible to add additional options for manually configure and add the missing 28% fuel into absolute refueling display for this particular track, it will not work for other tracks that has different pit entry positions. Those additional options or displays may only bring unnecessary confusion and distractions, and not suitable under complicated situations as based on some testing results, which is why they are not provided.

It is often to get into a situation where race leader would initiate an extra final lap just a few seconds before race timer reaches zero, especially in multi-class racing, which would require an extra lap of fuel or virtual energy in order to finish race.

Below example visualizes the relative finish position when race timer ends, and how it affects extra final lap chances:

In example 1, estimated leader's relative finish position is 0.10 (10% into lap), and estimated your (player) relative finish position is 0.90 (90% into lap). Since 0.90 > 0.10, it indicates that you are relatively ahead of leader when timer reaches zero, which requires an extra lap of fuel to finish the race.

In example 2, estimated leader's relative finish position is 0.20 (20% into lap), and estimated your (player) relative finish position is 0.25 (25% into lap). Since 0.25 > 0.20, it indicates that you are relatively ahead of leader when timer reaches zero, with a lap time difference of 5% (0.25 - 0.20 = 0.05). However, if we assume the average lap time difference is 10% per lap between leader (Hypercar) and you (LMGT3), then 10% > 5% would indicate that leader can overtake player on this lap, and there will be no extra final lap for player.

In example 3, estimated leader's relative finish position is approximately between 0.98 and 0.01 (98% to 1% into lap), and estimated your (player) relative finish position is 0.90 (90% into lap). Since leader is very close to finish line when timer reaches zero, there is a chance that leader may drive fast enough to catch up that 2% lap time distance before finish line, and initiate an extra final lap before timer reaches zero. So it could result either 0.98 (leader) > 0.90 (you) which there is no extra final lap; or, 0.90 (you) > 0.01 (leader) which there is an extra final lap.

Finally, Relative Finish Order widget provides estimates to relative finish position and lap time difference, which helps to determine the chance of extra lap and refueling as mentioned above. See Relative Finish Order section in User Guide for details.