Overview of GT7 Telemetry Software

  • Thread starter Thread starter snimat
  • 381 comments
  • 178,434 views
OTA update demo (staged rollout + worst-case hardware test)

Just a quick followup to the post above. Here is a full end-to-end demo of the OTA pipeline doing its job.



What's happening in the video
  • I upload a new software version through the hawkBit web frontend
  • I roll it out to the "dev" distribution channel only
  • The instrument cluster checks and sees the new version is available for its channel and pulls it down
  • It installs the update and reboots
  • It comes back up running the new version


Why the "dev channel" matters
This is the same staged-rollout pattern real vehicle fleets use. They don't push an update to every car at once; they rather push it to a canary group first, watch it behave and only then widen the rollout. The instrument-cluster's update channels work the same way: dev, and eventually a stable channel for everyone else, so a bad build never has to reach every device at the same time.

One detail worth pointing out
I ran this demo on a Raspberry Pi 5 with a VERY slow SD card on purpose. Wanted to see the update pipeline handle a sluggish I/O scenario rather than only showing the happy path on ideal hardware. It completed the download, install, and reboot without issue.

This is a proper update pipeline with targeted rollout groups, the same shape as what's used on actual vehicle software fleets, just running on a cheap board instead of a car's ECU cluster.
 

GT7 Track Identification from Telemetry – using Pit Box Coordinates as a Track Fingerprint​

I've been experimenting with ways to identify the current track in Gran Turismo 7 using only the UDP telemetry data, without relying on a Track ID.

I had an idea that might make this much simpler.

Every circuit has a pit lane, and when the car is in its pit box its world position can be read from telemetry as X/Y/Z coordinates.

My idea is to use the pit box position as a kind of track fingerprint.

For example, a database could contain something like:

Track A:
Pit position: X / Y / Z

Track B:
Pit position: X / Y / Z

Track C:
Pit position: X / Y / Z

When GT7 places the car in the pit box, the telemetry receiver could compare the current coordinates against this database and potentially identify the circuit immediately — without needing to drive a complete lap.

Even if different teams/cars are assigned slightly different pit boxes, I suspect that the group of possible pit positions for each circuit would still occupy a unique area in GT7's world coordinate system.

Another possibility would be to store additional information about the pit lane, such as:

  • X/Y/Z range of all pit boxes
  • orientation/heading of the car in the pit
  • pit lane direction
  • relative positions of several pit boxes
This could produce a stronger fingerprint than a single coordinate.

If two circuits happened to have similar pit coordinates, the identification could then be confirmed using telemetry collected after leaving the pits — for example the elevation profile (Y) relative to travelled distance, or a short section of the X/Z trajectory.

The goal would be to identify the track after only a few telemetry samples, ideally even before the car starts driving.

Has anyone experimented with this approach?

In particular, does anyone know whether the pit box X/Y/Z coordinates are stable between sessions and whether each circuit/layout uses its own coordinate space?

I'd be interested to hear from anyone who has collected GT7 position telemetry across multiple tracks.
 
gbech_pl

GT7 Track Identification from Telemetry – using Pit Box Coordinates as a Track Fingerprint​

I've been experimenting with ways to identify the current track in Gran Turismo 7 using only the UDP telemetry data, without relying on a Track ID.

I had an idea that might make this much simpler.

Every circuit has a pit lane, and when the car is in its pit box its world position can be read from telemetry as X/Y/Z coordinates.

My idea is to use the pit box position as a kind of track fingerprint.

For example, a database could contain something like:

Track A:
Pit position: X / Y / Z

Track B:
Pit position: X / Y / Z

Track C:
Pit position: X / Y / Z

When GT7 places the car in the pit box, the telemetry receiver could compare the current coordinates against this database and potentially identify the circuit immediately — without needing to drive a complete lap.

Even if different teams/cars are assigned slightly different pit boxes, I suspect that the group of possible pit positions for each circuit would still occupy a unique area in GT7's world coordinate system.

Another possibility would be to store additional information about the pit lane, such as:

  • X/Y/Z range of all pit boxes
  • orientation/heading of the car in the pit
  • pit lane direction
  • relative positions of several pit boxes
This could produce a stronger fingerprint than a single coordinate.

If two circuits happened to have similar pit coordinates, the identification could then be confirmed using telemetry collected after leaving the pits — for example the elevation profile (Y) relative to travelled distance, or a short section of the X/Z trajectory.

The goal would be to identify the track after only a few telemetry samples, ideally even before the car starts driving.

Has anyone experimented with this approach?

In particular, does anyone know whether the pit box X/Y/Z coordinates are stable between sessions and whether each circuit/layout uses its own coordinate space?

I'd be interested to hear from anyone who has collected GT7 position telemetry across multiple tracks.
Click to expand...
Unfortunately, the tracks do not inhabit unique global coordinates. I didn’t specifically test pit box locations, but I did compare start/finish positions across every layout. There is enough overlap that coordinates alone cannot uniquely identify the track.

The coordinates themselves are stable from session to session, so you can rely on that. The problem is uniqueness, not stability.

In practice, identification requires observing the car’s movement for a few seconds until its trajectory diverges from other candidate layouts.

Determining the exact layout can be even harder. Some layouts (for example, Spa) are identical on the racing surface and differ only in pit exit. If the car never enters the pits, telemetry alone provides no evidence to distinguish them.

Also worth noting: two GT7 layouts don’t have pit facilities at all, so a pit-based fingerprint can’t work universally.
 
Last edited:
Lord Grey
Unfortunately, the tracks do not inhabit unique global coordinates. I didn’t specifically test pit box locations, but I did compare start/finish positions across every layout. There is enough overlap that coordinates alone cannot uniquely identify the track.

The coordinates themselves are stable from session to session, so you can rely on that. The problem is uniqueness, not stability.

In practice, identification requires observing the car’s movement for a few seconds until its trajectory diverges from other candidate layouts.

Determining the exact layout can be even harder. Some layouts (for example, Spa) are identical on the racing surface and differ only in pit exit. If the car never enters the pits, telemetry alone provides no evidence to distinguish them.

Also worth noting: two GT7 layouts don’t have pit facilities at all, so a pit-based fingerprint can’t work universally.
Click to expand...
That makes sense. One thing I’m wondering about is whether adding yaw could reduce the number of collisions significantly.

Instead of comparing only X/Y/Z, the fingerprint could use:

X/Y/Z + yaw

and also limit the comparison to a smaller area around a known reference point, for example the starting grid or pit box position.

Even if two layouts have overlapping coordinates, their car orientation at that point may be different enough to separate them.

It would be interesting to test how many collisions remain after adding yaw and narrowing the coordinate tolerance/area.
 
gbech_pl
That makes sense. One thing I’m wondering about is whether adding yaw could reduce the number of collisions significantly.

Instead of comparing only X/Y/Z, the fingerprint could use:

X/Y/Z + yaw

and also limit the comparison to a smaller area around a known reference point, for example the starting grid or pit box position.

Even if two layouts have overlapping coordinates, their car orientation at that point may be different enough to separate them.

It would be interesting to test how many collisions remain after adding yaw and narrowing the coordinate tolerance/area.
Click to expand...
Yes, yaw may reduce the number of collisions substantially, especially if the goal is only to identify the circuit or venue.

The harder question is identifying the exact layout. Multiple layouts at the same venue can share the same pit area, grid, start line, direction, and much of the racing surface. In those cases, X/Y/Z plus yaw at a single reference point (well, within a small area around a point) may still be identical.

So I think this would be worth testing, but the result depends on what you need:
  • Venue identification: position plus yaw may be a strong fingerprint.
  • Exact layout identification: it may narrow the candidates, but a short trajectory or reaching a layout-specific section may still be required.
I may have assumed you meant exact layout identification. If you only need the venue, your approach is more promising.
 
Last edited:
What you are describing is basically what I use for EzioDash Pro, and it is most definitely possible to use this approach to identify tracks. But, it is a LOT of work, and it is far from 100%. And as Grey mentions, detecting the various layouts (Maggiore for example) adds yet another layer to it.
 
Bornhall
What you are describing is basically what I use for EzioDash Pro, and it is most definitely possible to use this approach to identify tracks. But, it is a LOT of work, and it is far from 100%. And as Grey mentions, detecting the various layouts (Maggiore for example) adds yet another layer to it.
Click to expand...
I agree that yaw would probably help a lot with normal vs reverse layouts, since the car orientation should be very different.

The harder case is when two layouts share the same grid, coordinates and direction, and only diverge somewhere further around the circuit. In that case I don’t think XYZ + yaw can identify the exact layout while the car is stationary.

It may still be useful to identify the circuit immediately and narrow the result down to a small group of possible layouts, then resolve the exact layout only when the car reaches a distinguishing section.

I’ll do some testing and we’ll see how it works. Thank you everyone for the suggestions! :)
 
Last edited:
gbech_pl
It may still be useful to identify the circuit immediately and narrow the result down to a small group of possible layouts, then resolve the exact layout only when the car reaches a distinguishing section.
Click to expand...
Yep, exactly how I do it. Sort by elevation first, match on gates by pit exit or finish line, then check divergence by the candidates still in the running.
 
Taifun1800
present I'm using EZIODASH Pro as main dash board. And I love the motivation from the box … 😇😊
additional a Android tablet with PRO Sim Dashboard on the side for more information with a little bit bigger letters for my old eyes 🤪

But I like to test @chrshdl solution also 😍
PI4 and a dashboard display 14,5" are on board … I'm curios

Thanks to all developers .. great job 👍🥰
Click to expand...
Hi Taifun1800,

things have changed since my last reply. Revokyte (the instrument cluster) is now also available as a Desktop/PC app, so your 14.5" display would work, no Pi display needed. I have also set up a website with all the infos:


If you are still curious, I'd love to hear your thoughts. And if anyone here wants to test the Windows build specifically, that would be extra helpful ... I don't own a Windows machine :)
 
Last edited:
Has anyone made progress on the remaining 12 undecoded bytes in Packet C? I’ve seen the speculation that the last 4 relate to steering or yaw — is there any measured confirmation, or is it still open?
 
In my project I have the following definition for the tilde packet:

Code: 
struct PacketTilde : public PacketB
{
    std::uint8_t throttleFiltered; // Filtered throttle output.
    std::uint8_t brakeFiltered;    // Filtered brake output.
    std::uint8_t UNKNOWNUINT81;    // Unknown byte preserved for binary layout compatibility.
    std::uint8_t UNKNOWNUINT82;    // Unknown byte preserved for binary layout compatibility.
    float torqueVectors[4];        // Per-wheel torque vectoring; positive is drive force, negative is braking/regeneration.
    float energyRecovery;          // Energy being recovered to the battery, for hybrid/EV behavior.
    float UNKNOWNFLOAT11;          // Unknown float preserved for binary layout compatibility.
};

UNKNOWNUINT82 appears to be tied to specific cars (e.g. it has a value of 1 for cars 3335, 3433, and 3607).

The three car codes I cited map to:

  • 3335 — McLaren Vision Gran Turismo (Gr.1)
  • 3433 — Ferrari FXX K ’14
  • 3607 — Porsche 963 ’24

I think this byte indicates (when it is 1) that the car has an energy recovery system, to go along with the 'energyRecovery' float within the same structure. I propose renaming 'UNKNOWNUINT82' to 'hasEnergyRecoverySystem'.

Can anyone else confirm my finding?
 
Last edited:
Lord Grey
In my project I have the following definition for the tilde packet:

Code: 
struct PacketTilde : public PacketB
{
    std::uint8_t throttleFiltered; // Filtered throttle output.
    std::uint8_t brakeFiltered;    // Filtered brake output.
    std::uint8_t UNKNOWNUINT81;    // Unknown byte preserved for binary layout compatibility.
    std::uint8_t UNKNOWNUINT82;    // Unknown byte preserved for binary layout compatibility.
    float torqueVectors[4];        // Per-wheel torque vectoring; positive is drive force, negative is braking/regeneration.
    float energyRecovery;          // Energy being recovered to the battery, for hybrid/EV behavior.
    float UNKNOWNFLOAT11;          // Unknown float preserved for binary layout compatibility.
};

UNKNOWNUINT82 appears to be tied to specific cars (e.g. it has a value of 1 for cars 3335, 3433, and 3607).

The three car codes I cited map to:

  • 3335 — McLaren Vision Gran Turismo (Gr.1)
  • 3433 — Ferrari FXX K ’14
  • 3607 — Porsche 963 ’24

I think this byte indicates (when it is 1) that the car has an energy recovery system, to go along with the 'energyRecovery' float within the same structure. I propose renaming 'UNKNOWNUINT82' to 'hasEnergyRecoverySystem'.

Can anyone else confirm my finding?
Click to expand...
I can independently confirm and add some detail to this finding from my own
vehicle-by-vehicle testing.


UNKNOWNUINT82

I have only observed values of 0 and 1.

When this byte was 1, the energyRecovery float changed and appeared to
contain meaningful data. When it was 0, energyRecovery remained inactive or
unchanged.

However, not every hybrid or EV reports 1. I tested some electrified cars
that still reported 0, and their energyRecovery value did not change.

Because of this, I think hasEnergyRecoverySystem may be slightly misleading.
The byte may indicate whether energy-recovery telemetry is available for that
particular car, rather than whether the actual car has an energy recovery
system.

A temporary name such as energyRecoveryDataValid,
energyRecoveryTelemetryAvailable or reportsEnergyRecovery might therefore
be safer.


UNKNOWNUINT81

I have observed four values so far: 0, 2, 4 and 9.

My current observations are:

  • 0: no meaningful activity was observed in torqueVectors[4].
  • 2 or 4: torqueVectors[4] changed, and energyRecovery also appeared to contain active and valid data.
  • 9: torqueVectors[4] changed, but energyRecovery appeared to remain inactive or invalid.

I still do not know what distinguishes 2 from 4.

This byte may be an enum or bitfield describing the type or configuration of
an electrified drivetrain or torque-vectoring system, rather than a simple
true/false flag.

So far, I have not found a non-electrified car that produces meaningful
torqueVectors[4] data, although I have not tested every vehicle.


UNKNOWNFLOAT11

This final float does not appear to be padding.

It changes actively while the vehicle is moving. When the vehicle is
completely stationary, it settles very close to zero and fluctuates slightly
between small negative and positive values.

It therefore appears to contain some kind of vehicle-motion or dynamics
information, although I have not yet identified the exact quantity, axis or
unit.
 
GreenRC
I can independently confirm and add some detail to this finding from my own
vehicle-by-vehicle testing.


UNKNOWNUINT82

I have only observed values of 0 and 1.

When this byte was 1, the energyRecovery float changed and appeared to
contain meaningful data. When it was 0, energyRecovery remained inactive or
unchanged.

However, not every hybrid or EV reports 1. I tested some electrified cars
that still reported 0, and their energyRecovery value did not change.

Because of this, I think hasEnergyRecoverySystem may be slightly misleading.
The byte may indicate whether energy-recovery telemetry is available for that
particular car, rather than whether the actual car has an energy recovery
system.

A temporary name such as energyRecoveryDataValid,
energyRecoveryTelemetryAvailable or reportsEnergyRecovery might therefore
be safer.


UNKNOWNUINT81

I have observed four values so far: 0, 2, 4 and 9.

My current observations are:

  • 0: no meaningful activity was observed in torqueVectors[4].
  • 2 or 4: torqueVectors[4] changed, and energyRecovery also appeared to contain active and valid data.
  • 9: torqueVectors[4] changed, but energyRecovery appeared to remain inactive or invalid.

I still do not know what distinguishes 2 from 4.

This byte may be an enum or bitfield describing the type or configuration of
an electrified drivetrain or torque-vectoring system, rather than a simple
true/false flag.

So far, I have not found a non-electrified car that produces meaningful
torqueVectors[4] data, although I have not tested every vehicle.


UNKNOWNFLOAT11

This final float does not appear to be padding.

It changes actively while the vehicle is moving. When the vehicle is
completely stationary, it settles very close to zero and fluctuates slightly
between small negative and positive values.

It therefore appears to contain some kind of vehicle-motion or dynamics
information, although I have not yet identified the exact quantity, axis or
unit.
Click to expand...
This is great information!

I agree with you about UNKNOWNUINT82. hasEnergyRecoverySystem probably claims more than the data actually tells us. If you’ve found electrified cars where the byte is 0 and energyRecovery remains inactive, then this looks more like a statement about the telemetry being reported than the physical capabilities of the car.

Of the names you suggested, I think I like energyRecoveryTelemetryAvailable. It’s a little verbose, but it’s also difficult to misinterpret.

Your UNKNOWNUINT81 results are particularly interesting. I’ve only observed 0 in my own captures, so I had basically written that byte off for the time being.

The values you’ve found – 0, 2, 4, and 9 – also make me wonder whether it could be a bitmask rather than an enum. In binary, those nonzero values are:

2 = 0010
4 = 0100
9 = 1001

That’s obviously nowhere near enough evidence to conclude that it is a bitmask, but those values are suspiciously bitmask-like. If it is, the behavior you’re seeing with torqueVectors and energyRecovery might eventually let us tease apart what the individual bits represent.

I’ve done some work on UNKNOWNFLOAT11 as well. I agree that it is definitely active telemetry rather than padding. In my captures it correlates very strongly with boost and throttle: about +0.921 with boost, +0.896 with filtered throttle, and +0.872 with raw throttle. I’ve also seen a weaker but still substantial correlation with longitudinal acceleration, roughly +0.65 to +0.72 depending on the capture. Based on that, my current working hypothesis is that it represents something related to delivered engine torque/load. I haven’t identified the exact quantity or units, though, so I’m definitely not ready to put a real name on it yet. Your observation that it settles close to zero while completely stationary seems compatible with that interpretation.
 
drfritz321
Hey everyone — figured this was the right thread to introduce something my son and I have been building for a while - Tractivvity

We're a father-and-son team from Indianapolis. We built Tractivvity because we love GT7 and the craft of racing, and we wanted tools that respect the time you put in on track. We're not trying to replace anything anyone here has made — we owe a lot to the work that came before this, and we hope Tractivvity can be a backbone the community builds on.

The short version: Tractivvity is the home base for your GT7 driving. A cloud-based telemetry platform with a persistent history of every lap you record — captured by our own agents on iOS, Android, Windows, or Mac, or by partner apps we'll announce soon. Every lap is automatically uploaded, analyzed, and saved forever. Compare any two laps side-by-side — yours, anyone else's, or a curated benchmark. And Tractivvity Insights is your personal race engineer. Overlay any lap against your personal best, a benchmark, or a faster driver from the community, and get coaching across every data channel we capture — full lap or segment-by-segment.

What makes it different:
  • Cloud-first, not local — your lap history follows you across every device, queryable forever
  • One account, every platform — iOS, Android, Windows, and Mac agents all feed the same web library
  • Server-side coaching — Tractivvity Insights surfaces where you're losing time, lap after lap, instead of leaving you to dig through charts alone
  • Community layer — public and private groups, global leaderboards by car/track/category, weekly challenges
We've had an absolute blast developing this. We're in early access right now, and we'd love honest feedback from this thread — the one that helped inspire the mission in the first place. Early access is fully automated and includes all the features, and you'll get some demo laps loaded to your account once you sign up. Things are moving fast, so we'll respond to any questions or issues as soon as we can.

Request access: tractivvity.com/signup
Apps: iOS | Android

View attachment 1538174

View attachment 1538175

View attachment 1538176

View attachment 1538178


-Dan

Tractivvity - Find your win.
Click to expand...

Very cool, I have been looking for something like this. I just signed up and will be submitting feedback if i notice any issues.
 
Hello people,

REVOKYTE v0.2.37 is out!

Download the community image and give it a try. Its amazing!

github.com

Releases · revokyte/instrument-cluster-os

Community OS image. Contribute to revokyte/instrument-cluster-os development by creating an account on GitHub.
github.com github.com


  • supports 3 dsi displays (waveshare 5" 800x480, waveshare 7" 1024x600, Pi display 2 720p)
  • runs on pi4, pi5 (1GB RAM is plenty)
  • major bugfixes: shiftlights, boot sequence, realtime fuel consumption

 
Lord Grey
This is great information!

I agree with you about UNKNOWNUINT82. hasEnergyRecoverySystem probably claims more than the data actually tells us. If you’ve found electrified cars where the byte is 0 and energyRecovery remains inactive, then this looks more like a statement about the telemetry being reported than the physical capabilities of the car.

Of the names you suggested, I think I like energyRecoveryTelemetryAvailable. It’s a little verbose, but it’s also difficult to misinterpret.

Your UNKNOWNUINT81 results are particularly interesting. I’ve only observed 0 in my own captures, so I had basically written that byte off for the time being.

The values you’ve found – 0, 2, 4, and 9 – also make me wonder whether it could be a bitmask rather than an enum. In binary, those nonzero values are:

2 = 0010
4 = 0100
9 = 1001

That’s obviously nowhere near enough evidence to conclude that it is a bitmask, but those values are suspiciously bitmask-like. If it is, the behavior you’re seeing with torqueVectors and energyRecovery might eventually let us tease apart what the individual bits represent.

I’ve done some work on UNKNOWNFLOAT11 as well. I agree that it is definitely active telemetry rather than padding. In my captures it correlates very strongly with boost and throttle: about +0.921 with boost, +0.896 with filtered throttle, and +0.872 with raw throttle. I’ve also seen a weaker but still substantial correlation with longitudinal acceleration, roughly +0.65 to +0.72 depending on the capture. Based on that, my current working hypothesis is that it represents something related to delivered engine torque/load. I haven’t identified the exact quantity or units, though, so I’m definitely not ready to put a real name on it yet. Your observation that it settles close to zero while completely stationary seems compatible with that interpretation.
Click to expand...
I have now collected samples from 33 hybrid and EV models. The sessions were not performed under identical controlled conditions, so the range comparisons below should still be considered preliminary.

Regarding UNKNOWNUINT82:

  • All 25 vehicles where UNKNOWNUINT82 was 1 produced an active energyRecovery value.
  • All 8 vehicles where it was 0 kept energyRecovery exactly at 0.
  • However, a value of 0 does not necessarily mean that the vehicle has no regenerative braking.

The most interesting examples are the three vehicles where UNKNOWNUINT81 was 9:

  • Hyundai N 2025 VGT
  • Skoda Vision Gran Turismo
  • Yangwang U9

All three use four electric motors with independent torque control for each wheel. Hyundai explicitly describes its system as four independent in-wheel motors, while the Skoda and Yangwang systems are four-motor layouts with independent wheel torque control, but are not necessarily in-wheel motors in the strict sense.

On these three vehicles, energyRecovery remains at 0, but all four torqueVectors are active. Positive torqueVectors appear during motor drive and negative values appear during regenerative braking. From observation, values close to +1 seem to represent maximum motor output, while values close to -1 represent maximum regeneration.

The values sometimes reach approximately +/-1.000676, so they appear to be normalized, with a small amount of simulation or numerical overshoot.

I have observed similar signed behavior from energyRecovery on vehicles where UNKNOWNUINT82 is 1. Despite its current name, energyRecovery may therefore represent a normalized, signed electric motor output signal covering both propulsion and regenerative braking:

  • +1.0 = maximum motor drive
  • 0.0 = no electric motor torque
  • -1.0 = maximum regenerative braking

This suggests that some vehicles report one combined value through energyRecovery, while four-motor vehicles with UNKNOWNUINT81 equal to 9 report the equivalent information separately through torqueVectors[4].

The current UNKNOWNUINT81 observations are:

  • 0: torqueVectors remain inactive
  • 2: only the front torqueVectors become active
  • 4: still unresolved; so far observed on the Jaguar Vision GT Coupe
  • 9: all four torqueVectors become active

I still cannot determine whether UNKNOWNUINT81 is an enum or a bitmask, but it appears to describe the layout or reporting mode of the electric motor torque channels.

I also gathered some additional observations about UNKNOWNFLOAT11.

It becomes positive during acceleration, usually negative during deceleration, and remains very close to zero while stationary. Its range also seems to depend strongly on the powertrain and transmission layout.

For example:

  • Porsche Taycan Turbo S: approximately -2.675 to +9.938
  • Toyota Aqua, Prius and C-HR hybrids: maximum values around +4.67 to +5.14
  • The three UNKNOWNUINT81 = 9 vehicles: only approximately -0.027 to +0.144

This appears compatible with your delivered engine torque/load hypothesis, but I think it may need to be generalized to delivered powertrain or transmission load because the same behavior is present in electric vehicles.

One possible interpretation is that energyRecovery and torqueVectors represent normalized electric motor drive or regeneration, while UNKNOWNFLOAT11 represents the resulting load through a shared powertrain or transmission path. This could explain why the Taycan and Toyota power-split hybrids produce large values, while vehicles with four independently driven wheels produce very small values.

This is still only a working hypothesis. Comparing UNKNOWNFLOAT11 during neutral and in-gear deceleration, and observing it across the Taycan's first-to-second gear shift, may help determine whether it is measured on the motor side, transmission side, or wheel side.
 
GreenRC
I have now collected samples from 33 hybrid and EV models. The sessions were not performed under identical controlled conditions, so the range comparisons below should still be considered preliminary.

Regarding UNKNOWNUINT82:

  • All 25 vehicles where UNKNOWNUINT82 was 1 produced an active energyRecovery value.
  • All 8 vehicles where it was 0 kept energyRecovery exactly at 0.
  • However, a value of 0 does not necessarily mean that the vehicle has no regenerative braking.

The most interesting examples are the three vehicles where UNKNOWNUINT81 was 9:

  • Hyundai N 2025 VGT
  • Skoda Vision Gran Turismo
  • Yangwang U9

All three use four electric motors with independent torque control for each wheel. Hyundai explicitly describes its system as four independent in-wheel motors, while the Skoda and Yangwang systems are four-motor layouts with independent wheel torque control, but are not necessarily in-wheel motors in the strict sense.

On these three vehicles, energyRecovery remains at 0, but all four torqueVectors are active. Positive torqueVectors appear during motor drive and negative values appear during regenerative braking. From observation, values close to +1 seem to represent maximum motor output, while values close to -1 represent maximum regeneration.

The values sometimes reach approximately +/-1.000676, so they appear to be normalized, with a small amount of simulation or numerical overshoot.

I have observed similar signed behavior from energyRecovery on vehicles where UNKNOWNUINT82 is 1. Despite its current name, energyRecovery may therefore represent a normalized, signed electric motor output signal covering both propulsion and regenerative braking:

  • +1.0 = maximum motor drive
  • 0.0 = no electric motor torque
  • -1.0 = maximum regenerative braking

This suggests that some vehicles report one combined value through energyRecovery, while four-motor vehicles with UNKNOWNUINT81 equal to 9 report the equivalent information separately through torqueVectors[4].

The current UNKNOWNUINT81 observations are:

  • 0: torqueVectors remain inactive
  • 2: only the front torqueVectors become active
  • 4: still unresolved; so far observed on the Jaguar Vision GT Coupe
  • 9: all four torqueVectors become active

I still cannot determine whether UNKNOWNUINT81 is an enum or a bitmask, but it appears to describe the layout or reporting mode of the electric motor torque channels.

I also gathered some additional observations about UNKNOWNFLOAT11.

It becomes positive during acceleration, usually negative during deceleration, and remains very close to zero while stationary. Its range also seems to depend strongly on the powertrain and transmission layout.

For example:

  • Porsche Taycan Turbo S: approximately -2.675 to +9.938
  • Toyota Aqua, Prius and C-HR hybrids: maximum values around +4.67 to +5.14
  • The three UNKNOWNUINT81 = 9 vehicles: only approximately -0.027 to +0.144

This appears compatible with your delivered engine torque/load hypothesis, but I think it may need to be generalized to delivered powertrain or transmission load because the same behavior is present in electric vehicles.

One possible interpretation is that energyRecovery and torqueVectors represent normalized electric motor drive or regeneration, while UNKNOWNFLOAT11 represents the resulting load through a shared powertrain or transmission path. This could explain why the Taycan and Toyota power-split hybrids produce large values, while vehicles with four independently driven wheels produce very small values.

This is still only a working hypothesis. Comparing UNKNOWNFLOAT11 during neutral and in-gear deceleration, and observing it across the Taycan's first-to-second gear shift, may help determine whether it is measured on the motor side, transmission side, or wheel side.
Click to expand...
Wow. You have done a lot of testing. Thank you for posting all of this!

I think you're right about energyRecovery. I was probably being too literal about the name, and interpreting it as a signed motor output makes more sense with what you're seeing. The four-motor cars are interesting because they show pretty clearly that UNKNOWNUINT82=0 does not mean "no regenerative braking."

UNKNOWNFLOAT11: I like the Taycan gear-shift idea. That might give us another clue about where in the powertrain that value is coming from.

None of these fields are particularly important for what I'm working on, but I admit that I really enjoy trying to figure out what they mean. You've taken this considerably farther than I ever did.

Thanks again for doing all this work and sharing the results. Please keep posting what you find!
 
I performed several additional tests on UNKNOWNFLOAT11 and found a few results that may help narrow down its meaning.

For now, I will continue referring to the field only as UNKNOWNFLOAT11 because its exact quantity, units, and measurement point are still unknown.

Nissan Qashqai e-POWER

The Nissan Qashqai Tekna e-POWER '22 produced the following ranges over 4,907 samples and approximately 81.85 seconds:
  • UNKNOWNFLOAT11: 0.000000 to +0.570467
  • energyRecovery: approximately -1.000676 to +1.000676
The important part is that energyRecovery reached its negative limit, so regenerative braking was definitely captured during the session. However, UNKNOWNFLOAT11 never became negative.

This may be related to the architecture of Nissan's e-POWER system. The combustion engine is used only to drive a generator, while the wheels are driven exclusively by an electric motor. There is no direct mechanical connection between the combustion engine and the wheels.


This result appears to argue against UNKNOWNFLOAT11 being a simple copy of longitudinal acceleration or total wheel-side drive force. The vehicle can regenerate and decelerate while UNKNOWNFLOAT11 remains non-negative.

Porsche Taycan Turbo S

I also observed UNKNOWNFLOAT11 during the Taycan's two-speed transmission operation.
  • In first gear, the value generally remained in the 0.x range, similar to many other vehicles.
  • When the transmission shifted into second gear, the value increased very sharply.
  • After the shift, the value gradually decreased as vehicle speed continued to increase.
  • The complete recorded range was approximately -2.675 to +9.938.
This behavior may be related to the change in motor speed, transmission ratio, or load during and after the shift. A torque-like value could rise when the motor speed drops during the shift into second gear and then decrease again as motor speed rises, but this is still only a possible interpretation.

Combustion-engine vehicle tests

I found that the sign of UNKNOWNFLOAT11 does not simply follow whether the vehicle is accelerating or decelerating.

  • Accelerating normally produces a positive value.
  • Releasing the accelerator and slowing down without using the brake produces a negative value.
  • Decelerating while applying the brake can still produce a positive value, even though the vehicle speed is decreasing.
  • Fully depressing the clutch or selecting neutral causes the value to become exactly 0 in live telemetry.
The clutch and neutral result seems especially important. The engine can still be running and the vehicle can still be moving, but UNKNOWNFLOAT11 becomes 0 when the mechanical connection to the transmission is removed.

The positive value during service-brake deceleration may be caused by the transmission slowing more quickly than the engine or motor. Rotational inertia, automatic downshifting, or rev matching could then create a positive reaction through the connected drivetrain. However, I have not yet separated these effects with a fixed-gear controlled test.

At minimum, these observations suggest that UNKNOWNFLOAT11 is not simply longitudinal acceleration, brake force, or ordinary internal engine load. It appears to depend on the mechanical connection and load transfer between the power unit and transmission, but the exact measurement point remains unknown.

Replay behavior

In live driving, the value becomes exactly 0 when the clutch is fully disengaged or the transmission is in neutral.

In replay telemetry, it does not always remain perfectly at 0. There are extremely small variations at approximately the sixth decimal place and beyond. These values appear more likely to be floating-point or replay interpolation noise than meaningful physical data.

For analysis purposes, values with an absolute magnitude below approximately 0.00001 could probably be treated as zero, while still preserving the original raw value.
 
Last edited:
Lord Grey
Wow. You have done a lot of testing. Thank you for posting all of this!

I think you're right about energyRecovery. I was probably being too literal about the name, and interpreting it as a signed motor output makes more sense with what you're seeing. The four-motor cars are interesting because they show pretty clearly that UNKNOWNUINT82=0 does not mean "no regenerative braking."

UNKNOWNFLOAT11: I like the Taycan gear-shift idea. That might give us another clue about where in the powertrain that value is coming from.

None of these fields are particularly important for what I'm working on, but I admit that I really enjoy trying to figure out what they mean. You've taken this considerably farther than I ever did.

Thanks again for doing all this work and sharing the results. Please keep posting what you find!
Click to expand...
Great work.

I can add data from the other side of the fleet. My corpus is conventional
ICE Gr.3/Gr.4 only, so it says nothing about the hybrid questions directly,
but it may help on two of your open points.


UNKNOWNFLOAT11 — the wheel-side test has been run, and it failed

You suggested the Taycan 1-2 shift to work out whether this value is
measured motor-side, transmission-side or wheel-side. I ran the wheel-side
version on ICE.

If the field were wheel torque, then value x gear_ratio / tyre_radius should
predict longitudinal acceleration with every gear collapsing onto one line.
It does not:

gear 1 r = 0.60
gear 6 r = -0.17
slope coefficient of variation: 0.87

No collapse. That is evidence against wheel-side from a drivetrain with a
conventional gearbox, and I think it supports your suggestion to generalise
from "engine torque" to delivered powertrain/transmission load.

Sample: 13 sessions, 122 laps, several Gr.3 cars.


UNKNOWNFLOAT11 — it goes negative, consistently

Both of you have inferred torque-like behaviour from positive correlations.
The negative half may be the more diagnostic part:

mean negative fraction under overrun: 0.994
present in 13 of 13 sessions, 122 laps
drops on clutch cut in 140 of 140 laps

Overrun windows defined as throttle 0, in gear, decelerating, brake 0.

Torque demand cannot go negative. Engine load does not go negative. Delivered
torque does, on overrun. So the negative excursion rules out two of the
candidate interpretations on its own.

For reference my range on ICE is roughly -2.7 to +3.0, which sits between
your Taycan (-2.675 to +9.938) and the four-motor cars (-0.027 to +0.144).

I also see the boost correlation you mention: on turbo cars, 0.903 against
boost versus 0.847 against raw throttle, on 45 laps. Boost beating the pedal
is consistent with the value reporting delivered output rather than driver
request.


UNKNOWNUINT81 = 0 — a large control group

For the non-electrified baseline: across 59 sessions, 23 distinct ICE cars
and roughly 2.06 million packets, the entire block from UNKNOWNUINT81 through
energyRecovery is exactly zero. Never non-zero, on any car, at any point.

So "0 = nothing reported" holds at scale on conventional cars.


On the bitmask question

Your own observations may already constrain it: 2 = front torqueVectors only,
9 = all four. In binary 0010 and 1001. The low bit is set on 9 and clear on 2,
so if it is a bitmask the low bit is not "electrified" — it is something the
four-motor cars have that the front-reporting cars do not.

That makes the Jaguar Vision GT Coupe at 4 (0100) the discriminating case. If
4 turns out to be rear-only, bitmask looks strong. If it is something else
entirely, enum looks more likely.

One caveat on all of the above: these are my own measurements against my own corpus, not verified against anyone else's decoder.
 
Back