Is your feature request related to a problem? Please describe.
The current SimHub GT7 plugin only exposes a subset of the telemetry data that Gran Turismo 7 actually sends via its UDP interface. Since GT7 Update 1.42, two extended packet types ("B" and "~") are available that contain additional telemetry fields which are highly valuable for tactile feedback, motion rigs, and dashboard creators.
Most notably, surfaceType is missing — a per-tyre surface indicator (T=Tarmac, C=Curb/Kerb, D=Dirt/Grass) that would finally enable a proper "Road Rumble" / curb effect for GT7. Currently, GT7 users have to rely on fragile suspension-based heuristics to approximate curb detection, which produces inconsistent results compared to other supported games.
Other useful fields from the extended packets are also currently unavailable in SimHub, forcing users to either build workarounds or run a second tool in parallel just to access this data.
Describe the solution you'd like
Extend the SimHub GT7 plugin to:
Request the extended packet types (B and/or ~) from GT7 by changing the heartbeat character sent to the console.
Parse and expose the additional fields as SimHub properties under DataCorePlugin.GameRawData.*, so they can be used in JS/NCalc formulas, ShakeIt effects, dashboards, and LED profiles.
Key fields requested (from the ~ / Packet C):
surfaceType[4] — surface contact per tyre (FL/FR/RL/RR), values T/C/D. Could be exposed either as a 4-character string or as four individual properties (SurfaceTypeFL, SurfaceTypeFR, SurfaceTypeRL, SurfaceTypeRR).
sway, heave, surge (Packet B) — body acceleration on X/Y/Z axes. Crucial for motion platforms and a much cleaner source for body-impact tactile effects than derived suspension data.
wheelRotation — steering wheel rotation in radians.
wheelSteeringAngle[2] — actual front wheel steering angle in radians.
wheelBase — distance between front and rear axles in meters.
carCategory[4] — car class string (e.g. GR3, GRX).
throttleFiltered, brakeFiltered — filtered pedal inputs.
torqueVectors[4] — per-wheel torque vectoring (positive = drive, negative = brake/regen).
energyRecovery — kinetic recovery energy for hybrid/EV cars.
currentLap (in ms, from Packet C) — higher-precision lap timing.
An option in the GT7 game settings to choose the packet type (A / B / ~) would be ideal, with a fallback if a specific type is unavailable (e.g. ~ is not sent in replays).
Describe alternatives you've considered
Suspension-based curb heuristics in custom JS scripts: Works partially, but unreliable — distinguishing curb oscillation from regular bumps requires complex sign-change detection, and false positives on rough tarmac are hard to eliminate. A direct surfaceType signal from the game would be definitive.
Running a second tool in parallel (e.g. a custom Python/C++ parser based on Nenkai's PDTools or MacManley's library) and forwarding data back to SimHub via a custom plugin: Doubles the setup complexity and is not realistic for most users.
Forwarding GT7 UDP to another telemetry app with broader field support: Defeats the purpose of using SimHub as the central platform and cannot drive ShakeIt effects.
Additional context
The community has reverse-engineered the full packet structure of all three GT7 packet types. Comprehensive documentation including all field offsets, types, decryption details (Salsa20 key + IV XOR constants per packet version), and the heartbeat protocol is available here:
MacManley/gt7-udp (well-documented C++ reference implementation, includes all three packet types A/B/~):
https://github.com/MacManley/gt7-udp
Nenkai/PDTools (.NET reference implementation by the original GT7 telemetry researcher):
https://github.com/Nenkai/PDTools/tree/master/PDTools.SimulatorInterface
Nenkai issue #14 documenting the discovery of the "B" packet IV (0xDEADBEEF instead of 0xDEADBEAF) and the additional motion fields (sway/heave/surge):
Nenkai/PDTools#14
The "~" packet uses XOR constant 0x55FABB4F and adds the surfaceType field plus other extensions. All packets share the same Salsa20 base key (Simulator Interface Packet GT7 ver 0.0).
Adding support would significantly improve the GT7 experience in SimHub, particularly for:
Bass shaker / tactile users who currently lack a working "Road Rumble" effect
Motion rig owners who need direct sway/heave/surge instead of derived values
Dashboard creators who want to display car class, true steering angle, or hybrid energy recovery
Thanks for considering — happy to provide additional context or test builds.
Is your feature request related to a problem? Please describe.
The current SimHub GT7 plugin only exposes a subset of the telemetry data that Gran Turismo 7 actually sends via its UDP interface. Since GT7 Update 1.42, two extended packet types ("B" and "~") are available that contain additional telemetry fields which are highly valuable for tactile feedback, motion rigs, and dashboard creators.
Most notably, surfaceType is missing — a per-tyre surface indicator (T=Tarmac, C=Curb/Kerb, D=Dirt/Grass) that would finally enable a proper "Road Rumble" / curb effect for GT7. Currently, GT7 users have to rely on fragile suspension-based heuristics to approximate curb detection, which produces inconsistent results compared to other supported games.
Other useful fields from the extended packets are also currently unavailable in SimHub, forcing users to either build workarounds or run a second tool in parallel just to access this data.
Describe the solution you'd like
Extend the SimHub GT7 plugin to:
Request the extended packet types (B and/or ~) from GT7 by changing the heartbeat character sent to the console.
Parse and expose the additional fields as SimHub properties under DataCorePlugin.GameRawData.*, so they can be used in JS/NCalc formulas, ShakeIt effects, dashboards, and LED profiles.
Key fields requested (from the ~ / Packet C):
surfaceType[4] — surface contact per tyre (FL/FR/RL/RR), values T/C/D. Could be exposed either as a 4-character string or as four individual properties (SurfaceTypeFL, SurfaceTypeFR, SurfaceTypeRL, SurfaceTypeRR).
sway, heave, surge (Packet B) — body acceleration on X/Y/Z axes. Crucial for motion platforms and a much cleaner source for body-impact tactile effects than derived suspension data.
wheelRotation — steering wheel rotation in radians.
wheelSteeringAngle[2] — actual front wheel steering angle in radians.
wheelBase — distance between front and rear axles in meters.
carCategory[4] — car class string (e.g. GR3, GRX).
throttleFiltered, brakeFiltered — filtered pedal inputs.
torqueVectors[4] — per-wheel torque vectoring (positive = drive, negative = brake/regen).
energyRecovery — kinetic recovery energy for hybrid/EV cars.
currentLap (in ms, from Packet C) — higher-precision lap timing.
An option in the GT7 game settings to choose the packet type (A / B / ~) would be ideal, with a fallback if a specific type is unavailable (e.g. ~ is not sent in replays).
Describe alternatives you've considered
Suspension-based curb heuristics in custom JS scripts: Works partially, but unreliable — distinguishing curb oscillation from regular bumps requires complex sign-change detection, and false positives on rough tarmac are hard to eliminate. A direct surfaceType signal from the game would be definitive.
Running a second tool in parallel (e.g. a custom Python/C++ parser based on Nenkai's PDTools or MacManley's library) and forwarding data back to SimHub via a custom plugin: Doubles the setup complexity and is not realistic for most users.
Forwarding GT7 UDP to another telemetry app with broader field support: Defeats the purpose of using SimHub as the central platform and cannot drive ShakeIt effects.
Additional context
The community has reverse-engineered the full packet structure of all three GT7 packet types. Comprehensive documentation including all field offsets, types, decryption details (Salsa20 key + IV XOR constants per packet version), and the heartbeat protocol is available here:
MacManley/gt7-udp (well-documented C++ reference implementation, includes all three packet types A/B/~):
https://github.com/MacManley/gt7-udp
Nenkai/PDTools (.NET reference implementation by the original GT7 telemetry researcher):
https://github.com/Nenkai/PDTools/tree/master/PDTools.SimulatorInterface
Nenkai issue #14 documenting the discovery of the "B" packet IV (0xDEADBEEF instead of 0xDEADBEAF) and the additional motion fields (sway/heave/surge):
Nenkai/PDTools#14
The "~" packet uses XOR constant 0x55FABB4F and adds the surfaceType field plus other extensions. All packets share the same Salsa20 base key (Simulator Interface Packet GT7 ver 0.0).
Adding support would significantly improve the GT7 experience in SimHub, particularly for:
Bass shaker / tactile users who currently lack a working "Road Rumble" effect
Motion rig owners who need direct sway/heave/surge instead of derived values
Dashboard creators who want to display car class, true steering angle, or hybrid energy recovery
Thanks for considering — happy to provide additional context or test builds.