GT7 is compatible with motion rig ?

[tarnheld]

I got the python script working and fiddled a bit with the data, here is what i've learned:

It works in live and replay mode, so you can get data from replays as well.

The packet data meaning as decoded by @Nenkai needs some more care, here is what i found so far:

After the header/magic number, we have:

Pos	Data Type	Range	Meaning	Notes
0x04	3 float	[-inf,inf]	Position X,Y,Z	Y points up, XZ is the race track plane Origin varies by track
0x10	3 float	[-inf,inf]	Velocity X,Y,Z	in meter/second, normalized gives vehicle direction
0x1C	3 float	[-1,1]	Rotation X,Y,Z	seems to be the cosine of rotation half? angle about X,Y,Z axis, acos(Y)*360/PI seems to be rotation angle of car direction about track north direction UPDATE: Seems to be the imaginary part of a unit quaternion that gives the rotation of the car relative to the track coordinate system, will add more info
0x28	1 float	[0,1]	Rotation ?	seems to be 1 when pointing north and 0 when pointing south, don't know if there is any benefit to Rotation values UPDATE: Seems to be the real part of a unit quaternion that gives the rotation of the car relative to the track coordinate system, will add more info
0x2C	3 float	[-inf,inf]	Angular Velocity X,Y,Z	in radians/second, how fast the car turns about an axis
0x38	1 float	?	Ride Height	seems to include suspension effects, not completely sure what is measured here
0x3C	1 float	[0,inf]	RPM	Engine RPM
0x40	4 byte	-	IV	decoding data
0x44	1 float	[0,100?]	Fuel Level	amount of of fuel left, starts at Fuel Capacity at start of race, TDB for EVs
0x48	1 float	[5,100?]	Fuel Capacity	amount of fuel that fits into the tank, usually 100 for fossil fuel cars, 5 for the kart, TBD for EVs
0x4C	1 float	[0,inf]	Speed	in meter/second, positive even when going backwards
0x50	1 float	[0,inf?]	Turbo Boost	this value - 1 gives the Turbo Boost display
0x54	1 float	[1.6?,8?]	Oil Pressure	in Bar?
0x58	1 float	?	?	seems to be always at 85.0, maybe water temp. check with other cars
0x5C	1 float	?	?	seems to be always at 110.0, maybe oil temp. check with other cars
0x60	4 float	[-273.15,inf]	Tire Temperature FL,FR,RL,RR	in degree celsius
0x70	1 int	-	Ticks	increases for every sent packet even when paused, packet number
0x74	1 short	[0,65535]	Current Lap	Which lap we are in, 0 before starting first lap
0x76	1 short	[0,65535]	Total Race Laps	How many laps the race will have, 0 for TTs
0x78	1 int	-	Best Lap Time	millisecond timestamp
0x7C	1 int	-	Last Lap Time	millisecond timestamp
0x80	1 int	-	Day Time Progression	millisecond timestamp, time of day indicates race start time of day, affected by Variable Time Speed Ratio, useless for timing when time speed ratio is not 1
0x84	1 short	TBD	Race Position	position of the car in the race, seems to be always -1 after race start
0x86	1 short	TBD	Number Of Cars	total number of cars in the race, seems to be always -1 after race start
0x88	1 short	[0,65535]	RPM Flashing	in RPM, indicates RPM when rev indicator starts flashing
0x8A	1 short	[0,65535]	RPM Rev. Limiter	in RPM, indicates RPM when rev limiter is hit
0x8C	1 short	[0,65535]	Car Maximum Speed	in speed units (km/h,mph,etc) chosen by game display setting, affected by car and tuning options
0x8E	1 short	-	Flags	each of the bits indicates something is active when 1 0: in race 1: paused 2: loading/processing 3: in a gear, 0 when shifting or out of gear, standing 4: has turbo 5: rev limiter flashing 6: handbrake 7: lights 8: lowbeam 9: highbeam 10: ASM 11: TCS 12:? 13:? 14:? 15:?
0x90	1 byte	[0,15]	Gears	two nibbles/4bit integers: 0-4: current gear, 0 is reverse, -1 is neutral 4-8: suggested gear, -1 when no suggested gear
0x91	1 byte	[0,255]	Throttle	throttle input
0x92	1 byte	[0,255]	Brake	brake input
0x93	1 byte	-	Reserved	always set to 0
0x94	4 float	-	Road Plane	coefficients of plane equation of the road below? or nearest? to the car, first three floats are the normal of the plane, distance of Position to this plane matches Ride Height
0xA4	4 float	[-inf,inf]	Wheel Speed FL,FR,RL,RR	angular speed in radians/second, sign opposite to vehicle speed
0xB4	4 float	[0,inf]	Tire Radius FL,FR,RL,RR	in meter, multiply with Wheel Speed to get Tire Speed in meter/second
0xC4	4 float	?	Tire Suspension Travel FL,FR,RL,RR	in meter?
0xD4	32 bytes	?	Reserved?	always set to 0
0xF4	1 float	[0,1]	Clutch	TBD
0xF8	1 float	[0,1]	Clutch Engagement	TBD, seems to be 1 - Clutch
0xFC	1 float	[0,inf]	RPM through Clutch	TBD
0x100	1 float	[0,inf]	Trans. Top Speed	corresponds to the Top Speed setting of a customizable gear box in the car settings, given as gear ratio
0x104	8 float	[0,inf]	Gear Ratios	ratios for gears 1-8 (what about reverse?) there is space for 8 gears, if car has more gears than that 9th gear ratio will overwrite the Car Code and other gear ratios are lost
0x124	1 int		Car Code

Will update this post with more info.

 

[Levers]

I can't seem to be able to run the exe file on Windows (not recognised as an exe.).
Anything specific as to the environment it needs?

Hi,

It doesn't work for me either, I try to open it and all I see is a quick flash of something on the screen and that's it. Did you get it to work? Thanks

 

[DJShadesUK]

Any chance someone can use this data to make a tablet app that runs the HUD (and others) on a separate screen so we can run without a HUD on the main screen?

Unfortunately, unless more data is discovered, I don't think completely turning off the HUD is going to be feasible, at least not for races which require in-race car setting changes via the MFD.

To analyse lap time data, you'd need a 'current laptime' parameter logged to reference everything against

As we're talking about post-practice/race analysis we don't need a real-time current lap time for that; we have the Lap and Last Lap Time values. Even if we didn't have the Last Lap Time value its simple maths to work out since we know the data is sent at regular intervals (60 times a second) and we know what lap we're on. Obviously, either way, its only going to be accurate down to a 60th of a second but I think that would be more than enough for all but the highest tier of players. Then again, do we even know, for a fact, that the game is actually polling player input data and doing its physics calculations greater than 60 times a second anyway? Yes, the hardware may be capable of physically capable of receiving input data, and calculating physics, much faster than 60 times a second but I can't imagine PD calculating more data than can be physically represented at 60fps anyway.

but lap is 1 before crossing the line, so that's not gonna work for lap 1

Again, as above, for post-analysis thats trivial to work out: Log everything from the moment the On Track flag is set, when starting lap 2 we're given lap 1's time, dump all the data prior to lap 1's length.

XZ Origin seems to be around the first start

Except, at least, Northern Isle Speedway. The extremities of the X and Z values are each mirrored in their respective dimensions, indicating that 0,0,0 of that track is dead centre in-field (which may be because the track has an infield which, in GTS at least, was only used for mission challenges)

 

[MGR]

0x38 - Body Height (Meters)
Initial value seems to vary depending on car height.
Value decreases dependant on speed and amount of downforce generated.
Increases significantly when launching over rally jumps - although it seems to clip at some point (approx 0.61 in my tests) and the actual peak value can vary from jump to jump).

0x54 - Oil Pressure (Bar)
The behaviour seems similar to oil pressure at idle values vary depending on car type and idle RPM.
Increases in a linear style at first before tapering off at higher RPM.
Peak value doesn't seem to exceed 8.0 on any car I've tested so far.
But then again, the Telsa also outputs this figure so who knows haha

0xB4 - Tire Radius (Meters) FL FR RL RR
Seems to be static while driving. Just varies from vehicle to vehicle.
Some cars have smaller front diameter tyres. Others are similar.

0xF4 - Clutch pedal (0.0 - 1.0)
Set to 0.0 when accelerating in gear
Flicks to 1.0 during gear changes and back again once the shift is complete
I don't a clutch pedal, so the only values I could see were either 0.0 or 1.0.
Perhaps the range can varies when using a clutch pedal.

0xF8 - Clutch engagement (0.0 - 1.0)
Basically the opposite value to the clutch pedal above.
I assume used to express the amount of engine power transferred through the clutch.

0xFC - RPM transferred through clutch to gearbox
Basically same as engine rpm when in gear and the clutch pedal is not depressed.
You can test this by releasing the accelerator while coasting and touch the handbrake.
This will also disengage the clutch, and it won't re-engage until you hit the accelerator again.

 

[tarnheld]

0xB4 - Tire Radius (Meters) FL FR RL RR

Can confirm this, if you multiply the Tire "speeds" (the 4 floats before 0xB4) with the Tire Radii you will get the vehicle speed while coasting. So the Tire "speed" is revolutions wheel speed in radians per second, with the sign opposite to vehicle speed.

EDIT: corrected, i forgot that 2*PI has to enter the scene somewhere...

 

[MotionHouseSi]

Thank you very much!

 

[F1Bernardo]

This is fascinating stuff. I think I’m more excited reading this thread than when the game was actually released LOL

 

[Nenkai]

Hi,

It doesn't work for me either, I try to open it and all I see is a quick flash of something on the screen and that's it. Did you get it to work? Thanks

The program is a console program. Run it with the command prompt or windows terminal.

0x38 - Body Height (Meters)
Initial value seems to vary depending on car height.
Value decreases dependant on speed and amount of downforce generated.
Increases significantly when launching over rally jumps - although it seems to clip at some point (approx 0.61 in my tests) and the actual peak value can vary from jump to jump).

0x54 - Oil Pressure (Bar)
The behaviour seems similiar to oil pressure at idle values vary dpending on car type and idle RPM.
Increases in a linear style at first before tapering off at higher RPM.
Peak value doesn't seem to exceed 8.0 on any car I've tested so far.
But then again, the Telsa also outputs this figure so who knows haha

0xB4 - Tire Radius (Meters) FL FR RL RR
Seems to be static while driving. Just varies from vehicle to vehicle.
Some cars have smaller front diamater tyres. Others are similar.

0xF4 - Clutch pedal (0.0 - 1.0)
Set to 0.0 when accelerating in gear
Flicks to 1.0 during gear changes and back again once the shift is complete
I don't a clutch pedal, so the only values I could see were either 0.0 or 1.0.
Perhaps the range can varies when using a clutch pedal.

0xF8 - Clutch engagement (0.0 - 1.1)
Basially the opposite value to the clutch pedal above.
I assume used to express the amount of engine power transferred through the clutch.

0xFC - RPM transferred through clutch to gearbox
Basically same as engine rpm when in gear and the clutch pedal is not depressed.
You can test this by releasing the accelerator while coasting and touch the handbrake.
This will also disengage the clutch, and it won't re-engage until you hit the accelerator again.

Documented all these fields - The list of exposed data is available here.
New version accordingly. https://github.com/Nenkai/PDTools/releases/tag/1.0.4

 

[Stoobert]

I now have realtime graphs from Python. Looking in to more data now.

 

[anthonyfa18]

The one thing I don’t understand about Polyphony digital, If they took the time and effort to put all the stats in the game for example oil pressure tire temperature tire pressures why can’t we get to see it? They added the wind in an update so we could see it we do know that the checks conditions change, This is what makes me feel Why the fia Step back till Gran Turismo was officially ready.

Also Do you think we will be able to access the data on the SF1000 wheel from Thrustmaster in upd mode??

 

[TypeOne]

For those seeking to use the simulator interface into their own .NET project; i've split it into a proper, .NET 6 async library.
Library: https://github.com/Nenkai/PDTools/tree/master/PDTools.SimulatorInterface
Test Tool: https://github.com/Nenkai/PDTools/tree/master/SimulatorInterfaceTest

Still no support for GT6 and Sport right now, but that'll be coming soon.
Edit: Added GTS support.

Correct, it's truncated.

Firstly, thank you for exploring; have you considered a donate button?

Every other racing game is available to simhub (https://www.simhubdash.com/supported-games/) and separate dash display.

What are the chances of getting this to there? Tyre temp output along with other basics would be a massive start?

Amazing work!

 

[BlazingDragon]

Hi,

It doesn't work for me either, I try to open it and all I see is a quick flash of something on the screen and that's it. Did you get it to work? Thanks

I had the same issue on Windows 11 - when using command prompt or PowerShell. The output continually "flashed" and was never visible...

Downloading Windows Terminal from the Microsoft Store and using that fixed it for me...

 

[DJShadesUK]

Thank you very much!

HOLY HELL! ALREADY!!

Things are moving so quickly this could turn into a major PR disaster for PD if they get the hump and change the decryption key!!

 

[Nenkai]

I had the same issue on Windows 11 - when using command prompt or PowerShell. The output continually "flashed" and was never visible...

Downloading Windows Terminal from the Microsoft Store and using that fixed it for me...

Yeah, my program does some heavy printing and the regular console is too slow. I tried to fix it with one updated version though; don't know if that fixes it.

 

[TheAdmiester]

I got the python script working and fiddled a bit with the data, here is what i've learned:

It works in live and replay mode, so you can get data from replays as well.

The packet data meaning as decoded by @Nenkai needs some more care, here is what i found so far:

After the header/magic number, we have:
Will update this post with more info.

Good documenting, one thing that may be worth pointing out in case you didn't already see in the code - those floats for gear ratios aren't a proper array or a fixed size collection, so if you get in a car with more than 8 gears like the LC500, it'll actually overwrite the data for car code. Just in case your car code parsing breaks without an obvious explanation.

 

[NitrogenQL]

@tarnheld 0x58 is water temperature, 0x5C is oil temperature, could vary depending on the car, but that's roughly what you'd expect for a GT3-class car. You can confirm this by jumping into say Mazda RX-VISION GT3 or a Porsche 911 RSR and looking at the values on the cockpit dash. Other cars with detailed cockpit displays can be useful for figuring out these values too. Like some of the LMP1 cars.

Trying out cars with electric or hybrid drivetrains can also potentially uncover more values, like battery level, discharge / recharge rates. Super Formula - to observe boost behavior and so on.

Appreciate the effort by the way!

 

[Stoobert]

It's slow using Matplotlib windows, but it is possible to have speed and throttle/brake maps...

 

[Levers]

The program is a console program. Run it with the command prompt or windows terminal.

Thanks

 

[Levers]

I had the same issue on Windows 11 - when using command prompt or PowerShell. The output continually "flashed" and was never visible...

Downloading Windows Terminal from the Microsoft Store and using that fixed it for me...

Thanks, I'll give that a try

 

[tarnheld]

Some more insights: the values 0x48,0x58,0x5C seem to be unset/placeholders for missing sensors. I just tested a car that had 100.0 for 0x54, the Oil Pressure sensor. I know that another car gave values on the Oil Pressure channel. So there must be cars out there that will give data on these other channels.

I suspect that the four values at 0x94 which show up as something tire-related in @Nenkai's tool are actually something else. The first three values seem to be the normal of the car -- like an up-direction. The Y value is always close to 1 and the other one are close to zero. When i take the direction of the velocity vector and check the angle between it and this normal i get a value that is close to zero but not zero. So the normal might not be orthogonal to the direction of the car. Maybe this normal is the car body which might be tilted relative to the car direction.

The fourth value is also strange, it might be something rotation related. I changes when the car turns, and it seems to range from -110 to 110.

EDIT: fourth value is no rotation...

 

[Stoobert]

Some more insights: the values 0x48,0x58,0x5C seem to be unset/placeholders for missing sensors. I just tested a car that had 100.0 for 0x54, the Oil Pressure sensor. I know that another car gave values on the Oil Pressure channel. So there must be cars out there that will give data on these other channels.

I suspect that the four values at 0x94 which show up as something tire-related in @Nenkai's tool are actually something else. The first three values seem to be the normal of the car -- like an up-direction. The Y value is always close to 1 and the other one are close to zero. When i take the direction of the velocity vector and check the angle between it and this normal i get a value that is close to zero but not zero. So the normal might not be orthogonal to the direction of the car. Maybe this normal is the car body which might be tilted relative to the car direction.

The fourth value is also strange, it might be something rotation related. I changes when the car turns, and it seems to range from -110 to 110.

EDIT: fourth value is no rotation...

It's more than that

I've just done some testing on SSRX with the Tomahawk on this 4-tuple and it's definitely related to the car and some vector directions relating to the car itself. Going along the straight the 'd' value would be between -7 and +1. Hitting the first uphill section moved that in to the -70 number. Then I went to the top of the banking at the end of the straight:

U3(a=0.2204902172088623, b=0.8707897663116455, c=-0.439441978931427, d=1428.0133056640625)
U3(a=0.22017914056777954, b=0.8712045550346375, c=-0.4387754201889038, d=1425.753662109375)
U3(a=0.21984156966209412, b=0.8716661930084229, c=-0.4380270838737488, d=1423.17236328125)
U3(a=0.21964798867702484, b=0.8720839619636536, c=-0.4372921884059906, d=1420.116455078125)
U3(a=0.2200683355331421, b=0.8725338578224182, c=-0.43618202209472656, d=1412.80517578125)
U3(a=0.22061209380626678, b=0.8728883266448975, c=-0.43519696593284607, d=1405.6732177734375)
U3(a=0.22120049595832825, b=0.8733879923820496, c=-0.4338936507701874, d=1396.734130859375)
U3(a=0.2217208743095398, b=0.8737751245498657, c=-0.43284741044044495, d=1389.3779296875)
U3(a=0.22169630229473114, b=0.8741588592529297, c=-0.43208467960357666, d=1385.541259765625)

could this have something to do with pitch/roll/yaw of the car in relation to something?

 

[Skidude88]

Could be calculated from logging time of day (if that is recorded down to 1000ths) and timestamp of lap change, but lap is 1 before crossing the line, so that's not gonna work for lap 1

My previous my statement was incorrect. I've just retested & lap number is 0 prior to crossing the line

 

[Stoobert]

Rallying at Sardegna:

a was rising as the nose of the car was.

And for the finale... Values clip at "high speed" on that jump...

>>decrypted_data[0x94:0xa4]

b'\x00\x00\x00\x00\x00\x00\x80?\x00\x00\x00\x00\x00\x00\x00\x00'

Definitely 0. I wonder if these being 0 is something weird in the physics?

 

[Bornhall]

I made a few adjustments to the Python script that @Nenkai posted a link to (https://github.com/lmirel/mfc/blob/master/clients/gt7racedata.py) if anyone wants to experiment more with a Python version. My edited version is available here: https://github.com/Bornhall/gt7telemetry/blob/main/gt7racedata.py

Output here looks like this (have yet to "structure" the data on screen):

 

[Hyurt]

I made a few adjustments to the Python script that @Nenkai posted a link to (https://github.com/lmirel/mfc/blob/master/clients/gt7racedata.py) if anyone wants to experiment more with a Python version. My edited version is available here: https://github.com/Bornhall/gt7telemetry/blob/main/gt7racedata.py

Output here looks like this (have yet to "structure" the data on screen):
View attachment 1177365

Nice one, I made a other one with a loop in order to get a dictionary and be able to manipulate easily from then. That's a good base at least for investigating

 

[Bornhall]

Nice one, I made a other one with a loop in order to get a dictionary and be able to manipulate easily from then. That's a good base at least for investigating

Admittedly, Python is NOT my language of choice, but if you feel up to sharing your code; drop me a DM.

Also, wanted to just throw it out there; is there any way to get OTHER data (other cars' lap times and such) than the telemetry? I was gonna look into what those PDTools could do, but got stuck on something completely different.

For the time being, just a fun thing to play around with, but it sure opens up for other things. Oh, how I wish PD would open up with things like APIs and such...

 

[Jordan]

could this have something to do with pitch/roll/yaw of the car in relation to something?

Could these values be the ones actually used by motion rigs?

 

[Bornhall]

Could these values be the ones actually used by motion rigs?

From what I've seen, two of the three first ones are very small values, hovering around 0. The second of the three (0x98) seems to hold just below 1, at 0.99... and don't change much. The fourth value (0xA0) varies a lot, both positive and negative, and may well go towards a value (like say 50) on braking, but remains at that value after stopping...

Can't really make head or tail of these (0x94-0xA0)... Possibly if someone could graph them along with a replay, it would be possible to make something of them.

Either way it's fun to dig in to some detective work

 

[tarnheld]

Could these values be the ones actually used by motion rigs?

These could well be preprocessed values that are directly consumable by motion rigs, i.e. that don't cause the motion rig to explode when the car topples or goes up-side-down. Maybe @MotionHouseSi can share some insight which values are used to drive a motion rig?

 

[Hyurt]

Admittedly, Python is NOT my language of choice, but if you feel up to sharing your code; drop me a DM.

Also, wanted to just throw it out there; is there any way to get OTHER data (other cars' lap times and such) than the telemetry? I was gonna look into what those PDTools could do, but got stuck on something completely different.

For the time being, just a fun thing to play around with, but it sure opens up for other things. Oh, how I wish PD would open up with things like APIs and such...

Didn't mean it could be better, just another way for manipulating



I put an example with only displaying speed in kph - what you done is perfect for exploring values, woudln't done better



I wish we could have more data, but I think we will be able to provide more and more even with the little we have now!