Feature: "C" telemetry format discovered

[MacManley]

I’ve discovered a new 368 byte telemetry packet that can now be accessed by sending the "C" heartbeat.

The XOR constant is the same as Packet B (0xDEADBEEF).

•	[0:4] SurfaceType (char): Indicates the surface in contact with each tyre.
•	T = tarmac
•	D = dirt
•	[4:8] Current Lap (uint32): Current lap time (milliseconds).
•	[20:24] Car Category (null-terminated string I think): Examples include GR3, GRB, GRX, etc.

The bytes in between are highly sporadic, I'm still looking into what exactly they are.

I’ll continue to reverse-engineer the packet and update this issue as more fields are identified.

[Chi-Ho]

Can confirm the findings. SurfaceType (though I'd prefer GroundSurface) also has C for curbs. CarCategory reports either GR1, GR2, GR3, GR4, GRB, GRN, or GRX.

Additional info for the missing bytes [9:20]:
[0x160..0x163] float: Front wheel steering angle FL in radians (righthand rule around car vertical axis, i.e. turn left = positive)
[0x164..0x167] float: Front wheel steering angle FR in radians
[0x168..0x16B] float: Unresolved but definitely related to steering. Value differs by car, ranging mostly between 2-3.4, except for karts at 1.06. Only reacts to toe setting and steering (except for karts again, it stays constant regardless of steering input). Decreases when left-steering and increases when right-steering (sign inversed from steering angle). Note: it is asymmetric that the induced change from left-steering is larger than right-steering.

[MacManley]

Can confirm the findings. SurfaceType (though I'd prefer GroundSurface) also has C for curbs. CarCategory reports either GR1, GR2, GR3, GR4, GRB, GRN, or GRX.

Additional info for the missing bytes [9:20]: [0x160..0x163] float: Front wheel steering angle FL in radians (righthand rule around car vertical axis, i.e. turn left = positive) [0x164..0x167] float: Front wheel steering angle FR in radians [0x168..0x16B] float: Unresolved but definitely related to steering. Value differs by car, ranging mostly between 2-3.4, except for karts at 1.06. Only reacts to toe setting and steering (except for karts again, it stays constant regardless of steering input). Decreases when left-steering and increases when right-steering (sign inversed from steering angle). Note: it is asymmetric that the induced change from left-steering is larger than right-steering.

This is some good work. That last one looks fairly tricky, I'm surprised it is extremely different for karts. Given the context of the previous front wheel steering angle floats, could it be some sort of Ackerman steering value of sorts? I'll have to investigate further this week.

[vwhitteron]

Great work figuring all this out so far. I've been taking a look at the 0x168 float and found that with the steering wheel at zero degrees the value matches the wheelbase of the vehicle in meters. I don't understand why the value decreases on left turn and increases on right turn but perhaps the variable component after subtracting the wheelbase is informative in some way.

[Edit] Actually, since the steering angle of each wheel is asymmetric from left to right then this value could well be the dynamic wheelbase for the left hand side of the vehicle.

On a separate note I have the packet data structure defined as a Kaitai Struct which might be helpful to anyone wanting to quickly get a working library in various languages.

[Chi-Ho]

Great work figuring all this out so far. I've been taking a look at the 0x168 float and found that with the steering wheel at zero degrees the value matches the wheelbase of the vehicle in meters. I don't understand why the value decreases on left turn and increases on right turn but perhaps the variable component after subtracting the wheelbase is informative in some way.

[Edit] Actually, since the steering angle of each wheel is asymmetric from left to right then this value could well be the dynamic wheelbase for the left hand side of the vehicle.

On a separate note I have the packet data structure defined as a Kaitai Struct which might be helpful to anyone wanting to quickly get a working library in various languages.

You maybe onto something. I gave up the idea of it being wheelbase when I saw how much swing the kart's front wheels had when steering, but animation could be deceiving and the underlaying physics may still treat it as constant.

Do we have GT7 car wheelbase data to verify?

[vwhitteron]

I have manually added wheelbase info for a number of vehicles in the DB embedded in the gt-telemetry project. These values are based on real world specs and the few I have checked are either spot-on or very close and those may just be due to the toe value being non-zero.

[Chi-Ho]

I have manually added wheelbase info for a number of vehicles in the DB embedded in the gt-telemetry project. These values are based on real world specs and the few I have checked are either spot-on or very close and those may just be due to the toe value being non-zero.

Wow. That's really cool.
After comparing a few dozen car's 0x168 to your DB, I think it is indeed the left wheelbase in meters. Thanks for your work!

[Beregoz]

    'T' => SurfaceType.Tarmac,
    'D' => SurfaceType.Dirt,
    'C' => SurfaceType.Curb,
    'G' => SurfaceType.Grass,
    's' => SurfaceType.Snow,
    'S' => SurfaceType.Sand,

[Nenkai]

I can confirm that there are no other packet "modes" as of 1.68.

Group list is already accurate, and there are 23 surface types in total that all map to the above letters (some duplicates or intentionally left vague), there are no other letters.