GT7 is compatible with motion rig ?

  • Thread starter poumpoum
  • 686 comments
  • 187,376 views
Which of the available metrics should I use for spinning tires? I would like to track when I am loosing control. I have seen some prototype dashboards that mimic the red tires in GT7. But what metric are they using?

Also is there some metric that shows if I am steering? I would like to have an overview of the time when I am steering while breaking.
I think they use the temperature of the tires. The value rises sharply when you lose traction and slip.
 
I think they use the temperature of the tires. The value rises sharply when you lose traction and slip.
It looks like that's it!
The problem is that the temperature keeps rising. So to activate a vibration device on the pedals, you have to evaluate the variation of these values.
 
It looks like that's it!
The problem is that the temperature keeps rising. So to activate a vibration device on the pedals, you have to evaluate the variation of these values.
Somewhere in this thread someone wrote that you can find wheel speed and I think vehicle speed and if wheel speed is > than car, it's spinning or something like that.
 
Which of the available metrics should I use for spinning tires? I would like to track when I am loosing control. I have seen some prototype dashboards that mimic the red tires in GT7. But what metric are they using?

Also is there some metric that shows if I am steering? I would like to have an overview of the time when I am steering while breaking.
Back in the day when GT6 had MoTeC i2 log support i made a thread about analysing tires. You can dive into that if you want, and also look at the excellent Physics of Racing series by Brian Beckman for all the gory details. The gist about detecting tire slipping is that you can use the vehicle speed and the tire speed to build a ratio that will tell you when your tires are spinning out. Your driven tires will always move a bit faster than the vehicle and if your brakes are working and you are decelerating, the tires will move a bit slower than the vehicle. So if you calculate the ratio of tire speed and vehicle speed:

TireSpeed = Wheel Speed(0xA4) * Tire Radius(0xB4)
Ratio = TireSpeed / CarSpeed(0x4C)

This ratio will be 1 if the wheel feels no force acting on it, and should be between 1.2 and 0.8 if the tire is braking or accelerating normally. Values outside this range will tell you that this tire lost it's normal grip and is spinning or slipping. There is a lot more to be learned from this, but for checking if the wheel is outside it's range, this should be enough.

Unfortunately there is no steering input in the packet data, so you cannot analyze your steering at the moment.
 
Last edited:
TireSpeed = Wheel Speed(0xA4) * Tire Radius(0xB4)
Ratio = TireSpeed / CarSpeed(0x4C)

This ratio will be 1 if the wheel feels no force acting on it, and should be between 1.2 and 0.8 if the tire is braking or accelerating normally. Values outside this range will tell you that this tire lost it's normal grip and is spinning or slipping. There is a lot more to be learned from this, but for checking if the wheel is outside it's range, this should be enough.
Figured I was going to implement that, but didn't get around to it. Now I was unable to resist doing it :D

I've added this as a delta value for each tire in the output of my python script, below the wheel diameter values:

Skärmavbild 2022-08-02 kl. 20.44.58.png


Note though that the value MAY in fact "overflow" the display (i.e. values > 999 when doing doughnuts and such).
 
With very few modifications, @Bornhall ’s script runs in Pythonista on iOs devices. Even very old ones (I tested on an iPhone 5 and it was fine).
Only had to change the salsa20 library with a pure Python one… I am currently working on a UI for it. Could share it if there’s interest!

Phones have accelerometers… which could be translated to steering inputs, although I can’t think of a great use for it
 
Last edited:
No doubt this feature has been included due to the devs. knowing that eventually GT7 will be released on PC and then this telemetry can be used when pairing the game on PC to a motion rig. Good stuff. ;)
 
No doubt this feature has been included due to the devs. knowing that eventually GT7 will be released on PC and then this telemetry can be used when pairing the game on PC to a motion rig. Good stuff. ;)
Why do you have, "No doubt" that this will be ported to PC? Sony is all of a sudden going to take one of its most profitable games, exclusive to the Playstation console and make it compatible with Microsoft PC's?
 
Why do you have, "No doubt" that this will be ported to PC? Sony is all of a sudden going to take one of its most profitable games, exclusive to the Playstation console and make it compatible with Microsoft PC's?
Yes GT7 will likely go to PC. Spider-Man, uncharted, last of us, god of war, horizon are now all on PC etc
 
So based on packet timing differentials I can now get estimated lap times to within 5ms of actual. I'm going to work tonight on potentially providing real-time deltas to reference. As no packets are missing, the theoretical max difference is approximately 18ms which for most purposes would be close enough as the amount off will be less than half a car's length.
 
So I added some analysis data and visualization to my fork of gt7telemetry. After each lap a browser window opens with the latest comparison of two or more laps. Work in progress.

You can see me running dry in "Lap 0", which is actually my latest lap where "Lap 1" is the best lap in the session. Since replays are also broadcasted via telemetry this would enable us to compare performances between drivers.

I want to stay merge-able with @Bornhall s upstream, so I did some ugly coding there, using globals, not sorting imports, etc.

1659552129907.png

Edit:

I made some nice additions. Next step would be to link the position in the race track to the diagrams on the left.

1659605333893.png
 
Last edited:
I contacted the dev of SIM Dashboard a few days ago, today he replied that he has already got it working, a beta version is available!
https://www.stryder-it.de/simdashbo..._Gamers/Game_Configuration/Gran_Turismo_7.php

I haven't been able to sign up for the beta though, for some reason my google play store has been stuck on the "beta signup in progress" state for a while now.

Update:
The play store on my tablet is still stuck, but luckily I was able to push an install from the web play store and I have the beta version on my tablet. Tried it a bit after GT7 1.19 update, and it works! (This particular dash was made for ACC so some info was not available, will try to make a new one that's fully compatible with GT7.)
View attachment 1177568
I'm buying a tablet for this right now (was already considering one to use with ATS) so does anyone know if you can have different "profiles" or similar for each game?
 
So I have been playing around with gettng a live delta working. So far this is what I have that appears to be "accurate enough".

There is a lot of stepping in the graph due to small changes adding up (1 packet @ 16ms). I am looking to smooth that out.

The graph is the delta in seconds.
The text has 3 boxes. 1 is an internal cell location that's not relevant outside of my specific code, the second is the current lap time. the third is a real-time delta reading.
 
Is anybody here Java savvy? I'm thinking about doing something in Android.... more customized/specialized in GT7. I don't understand much about Java, though... managed to get the UDP stuff done (it's easy), but the byte manipulations and decryption are killing me.

How would one do this in Java?
Python:
def salsa20_dec(dat):
    KEY = b'Simulator Interface Packet GT7 ver 0.0'
    # Seed IV is always located here
    oiv = dat[0x40:0x44]
    iv1 = int.from_bytes(oiv, byteorder='little')
    # Notice DEADBEAF, not DEADBEEF
    iv2 = iv1 ^ 0xDEADBEAF
    IV = bytearray()
    IV.extend(iv2.to_bytes(4, 'little'))
    IV.extend(iv1.to_bytes(4, 'little'))
    #ddata = salsa20_xor(dat, bytes(IV), KEY[0:32])
    ddata = salsa20_xor(KEY[0:32],bytes(IV),dat)
    magic = int.from_bytes(ddata[0:4], byteorder='little')
    if magic != 0x47375330:
        return bytearray(b'')
    return ddata
 
Last edited:
This is absolutely great ! My heart almost stopped after discovering this awesome thread . I'm writing some plugins for XSim, in order to support the few games with telemetry enabled on consoles (PS4/PS5). GT7 will be my next victim then ! I was wondering if there was a consolidated file/sticky thread documenting the packet structure with all data, offset, type etc. I maintain a file with packet structure from different games here:
 
hello friends, could you help me to make this connection between the Interface.exe and the pc? I'm not following along. I have already opened ports 33739 and 33740 on the modem and on the firewall but there is no connection. can any kind soul help me with this?
 

Attachments

  • SAVE_20220802_230030.jpg
    SAVE_20220802_230030.jpg
    26.3 KB · Views: 27
Skimmed across mentions and this thread, that'll be the list of tools as of right now:


Tool with official support from PDI:
Will be updated if more are made/found.
 
Last edited:
As said, I'm currently writing a proxy for XSim. Progressing nicely, based on the great work provided by all the community.
I'm just stuck now on the acceleration x/y/z (heave/sway/surge). I can't really find figures providing surge for example. A positive value when accelerating becomong negative when braking. Any idea where this one is ?

I have finished a full inventory of the telemetry payload from GT7 here (thr GT7Detailed tab):
 
It seems Fuel and Reverse Gear is Not working in the App. Hase someone the values?
Fuel was discovered only recently, so it might arrive at a later update. I'm not involved with the app, it's only a guess from my side. Maybe you want to contact them and point them to the packet table. I didn't test if the reverse gear shows up in the Gears data, maybe it will be -1 if you are in reverse. Will test later.
I'm just stuck now on the acceleration x/y/z (heave/sway/surge). I can't really find figures providing surge for example. A positive value when accelerating becomong negative when braking. Any idea where this one is ?
The acceleration is not in the packet as a data entry, but i guess it could be calculated from the velocities of two consecutive packets A and B and the time between those packets:

  • first, determine the time passed between the two packets by subtracting the day time progression in milliseconds of packet B from the one in packet A, in milliseconds
  • then, find the velocity difference by subtracting the velocity of packet B from packet A (do this for all velocities in X,Y,Z)
  • since acceleration is velocity change over time, divide the velocity difference by the elapsed time
something like this:
dt_ms = day time progression_A - day_time_progression_B
dt_s = dt_ms / 1000.0
dV = (velocity_B - velocity_A)
acceleration = dV / dt_s

acceleration will be in m/s^2.

That said, since the velocity X,Y,Z coordinates are global coordinates IIRC, you will get the acceleration in the global coordinate system -- if the vehicle turns 90 degrees, the velocity in X will be the velocity in Z. I think you want the velocity in car coordinates, so that velocity in X is the velocity of the car going 'forward' all the time, regardless of how the vehicle is oriented globally. For this you will have to use the rotation values (also in the packet) to transform the global velocity to the local car velocity.

I haven't looked into this as of now, but plan to do so when i find some time for this. Maybe someone else has already looked into this and can share some insight or even code?
 
I checked by adding packet time differences on to my data to check this and the PS5 definitely -tries- to send one at 1/60s intervals even at 120Hz refresh rate (looks like GT7 doesn't support it). Over the course of 30,000 data points the average packet time was 16.668ms, using Python's inaccurate time.time() module. Considering this library is correct to ~200us, that seems to be right. When colelcting data though, it may not be exact as I have seen packets arriving anywhere between 14-18ms.
Another thing i was pondering is if the actual time between each packet could be exactly 1/60s. The difference of the millisecond timestamp in each packet is varying between 16 and 17ms for consecutive packets and i guess you measured the packet arrival time and it boils down to the same difference on average. But PD might actually measure the data at simulation steps that are really exactly 1/60s apart. The millisecond timestamps in the data could be rounded and thus inaccurate. Trying to measure packet arrival time might also be the wrong thing to do since it would be most accurate to have the time of measurement.

You might want to replace the packet time difference in your time delta code with the constant 1/60 and see if there is any improvement in accuracy, or if i am wrong and accuracy goes to hell. Both would be valuable insights. Will try to shed some light on this as well.
 
I didn't test if the reverse gear shows up in the Gears data, maybe it will be -1 if you are in reverse. Will test later.
As far as I can tell, there is no N (neutral) for GT7, so when the value is 0, that is R (reverse). Anything above 0 seems to correspond to the equivalent gear. Note though that I haven't checked for EVs with more than 1 gear (Taycan seems to have 2), if they display gear correctly.
 
Back