- 30
- Russian Federation
GT7 is compatible with motion rig ?
- Thread starter poumpoum
- 687 comments
- 211,096 views
- 6
- Brazil
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.
- 2,228
- Bielefeld
- tarnheld
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:
- 142
- Sweden
- Bornhall
Figured I was going to implement that, but didn't get around to it. Now I was unable to resist doing it
I've added this as a delta value for each tire in the output of my python script, below the wheel diameter values:
Note though that the value MAY in fact "overflow" the display (i.e. values > 999 when doing doughnuts and such).
- 65
- Brazil
- F1-Bernardo-
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
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:
- 494
- Tampa, Florida
- Saargasm86
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?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.
- 65
- Brazil
- F1-Bernardo-
- 872
- United Kingdom
- oppsijustkilledu
- 6,753
- Fürstentum Lippe
- GTP_Nuschel
Don't forget Super Mario, The Legend of Zelda and Pokémon
- 131
- Oslo
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.
- 52
- Germany
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.
Edit:
I made some nice additions. Next step would be to link the position in the race track to the diagrams on the left.
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.
Edit:
I made some nice additions. Next step would be to link the position in the race track to the diagrams on the left.
Last edited:
CodeRedR51
Premium
- 55,391
- United States
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?
- 131
- Oslo
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.
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.
- 257
- China & USA
Yes, you can have several dash designs for each game it supports.
- 65
- Brazil
- F1-Bernardo-
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?
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:
- 6
- Brazil
Skimmed across mentions and this thread, that'll be the list of tools as of right now:
Tool with official support from PDI:
- [C#] PDTools.SimulationInterface (Library + Test Tool) by Nenkai
- [C#] SimulationInterfaceFormTest - by ewhoambra (fork of above tool with previewing)
- [Python] Test Tool by lmirel
- [Python] Telemetry Viewer by Bornhall (based on the above tool)
- [Python] Telemetry Viewer with Plotting by snipem (forked from above)
- [Python] GT7 Telemetry to Dictionary by Hyurt
- [C#] Telemetry Provider for SimFeedback by ashupp
- [Python] Telemetry Provider for Sim Racing Studio API by gt7coder (?)
- [Python] Toolset/Viewer by TheBrinkOfTomorrow
- [C#] GT7Analyzer by RealJean42
- [Java/Android] GT7 Race Data App by lmirel
- [Android] SIM Dashboard - https://www.stryder-it.de/simdashboard/
Tool with official support from PDI:
- [Windows] ACSIM Motion Rig Support
Last edited:
- 42
- São Paulo
- m_crisostomo
- MCrisostomo
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):
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):
- 2,228
- Bielefeld
- tarnheld
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.
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
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?
- 2,228
- Bielefeld
- tarnheld
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.
- 142
- Sweden
- Bornhall
