GT7 is compatible with motion rig ?
- Thread starter poumpoum
- 686 comments
- 186,113 views
- 65
- Brazil
- F1-Bernardo-
Can the "laptime" be reasonably approximated from the "Lap" variable? As soon as it switches, a new lap has started and a packets are then retrieved every 1/60th of a second (16ms)
Not ultra mega precise, sure... but 16ms is nothing major for non-aliens. And with laptime, one could calculate a realtime delta to best/last lap (ithose would need to be recorded from previous laps in the same session)
Not ultra mega precise, sure... but 16ms is nothing major for non-aliens. And with laptime, one could calculate a realtime delta to best/last lap (ithose would need to be recorded from previous laps in the same session)
Last edited:
- 131
- Oslo
I tried doing this with the realtime F1 data which has variable packet timings but was quite unreliable.
I could see if the code is portable and with the extra data afforded to us from the packets (plane data and the such) you could make some assumptions and use linear interpolation to fill in the gaps so to speak. It's something I am interested in because I want to see deltas against best in the actual race, not just in free practice / time trial once a lap has been completed (see iRacing in every race).
Last edited:
- 65
- Brazil
- F1-Bernardo-
A simpler approach might be to compare an average or median of every "X packets" (say... 30 or so). That would give a more accurate (maybe?) delta every 500ms, which should be fine. Should also be easier to implement, without planet interpolations.
(I haven't coded in a looong time, don't want to make these sound as feature requests. Just ideas that pop up from reading the fascinating things you folks are developing here.)
- 126
- Sweden
- Bornhall
I did a quick test last night with Python's datetime object, and as you mention, it's not super precise. The resolution will be based solely on the 1/60 update, and as such won't give you the same lap time as in-game. However, it's perfectly adequate to have a "current lap" timer going until the last lap time can be gleaned from the telemetry data.
Basically, in my script I added the following (will be updated on GitHub later):
Python:
# outside loop
prevlap = -1
# inside loop
curlap = struct.unpack('h', ddata[0x74:0x74+2])[0]
if curlap > 0:
dt_now = dt.now()
if curlap != prevlap:
prevlap = curlap
dt_start = dt_now
curLapTime = dt_now - dt_start
printAt('{:>9}'.format(secondsToLaptime(curLapTime.total_seconds())), 7, 41)
else:
curLapTime = 0
printAt('{:>9}'.format(''), 7, 41)But, as mentioned, the curLapTime that is stored when the lap counter changes will most likely not match the "last lap time".
Edit: As for "running counter" of lap times, why not just store the "last lap time" every lap? Other than as a more "informational" timer, there's otherwise no other use for running your own lap timer, is there?
Last edited:
- 65
- Brazil
- F1-Bernardo-
The point about storing the packets (or an average of every 'X' packets) is to be able to calculate realtime deltas comparing against previous/best laps.
Similar to how GT itself has a delta when you are time trialing, or how back in GTS you could see at the delta between you and Lewis Hamilton's ghost in the DLC
- 1,913
- valencia
- Donnced
Thanks for the information, downloaded it, added me to beta testing version, and it works great, so all my support to the dev.
Hopefully we see soon more information and telemetry on the app than the game HUD offer and so disconnect the game HUD and use only the UDP app as I do with other racing games .
- 126
- Sweden
- Bornhall
Of course, I see the point. But, I would surmise that you would need to set up some kind of homegrown "checkpoint system" based on the positioning to be able to get anything really useful as to +/– in seconds. And it would likely not be very accurate, at least not nearly as accurate (without any hard proof to its accuracy) as the in-game time trial counterpart.
In-game I'm sure there are some kind of zoning system for the entire track width basically, for which the game can compare your best lap time to your current one. Not saying it is impossible to achieve outside the game, but surely it will come with a lot of caveats.
- 126
- Sweden
- Bornhall
I'm going to go back on my claim that the 0x88 value was the rev limiter. I had a bit of hope that they would be the endpoints for the HUD's rev band (top center on the HUD), so that 0x88 and 0x8A could represent the start and end of a dash rev display. But from further investigation (and careful pressing of the R2 button) I stand corrected; the 0x88 value is the "full bar" where the bar flashes, and the 0x8A value is in fact the rev limiter.
This means that a dashboard light bar may have to use a set percentage or some such for the start point, say 85% of what is in 0x88, spreading through to the full value of 0x88 and flashing (wildly) as it hits or closes up to 0x8A.
This means that a dashboard light bar may have to use a set percentage or some such for the start point, say 85% of what is in 0x88, spreading through to the full value of 0x88 and flashing (wildly) as it hits or closes up to 0x8A.
- 131
- Oslo
Yes. This is why I am hoping that some of the planar information can be used to try and figure this out. I just loaded up a manufacturers race I did many, many moons ago around Brands Hatch and shoved the data in. Now, time to break out the fancy tools, so Pandas it is:
So what I have done here is to take the entire race replay, drop lap 0 (pre-race rolling start) and lap 17 (cooldown waiting for others to finish) to give the actual 16 laps of the race. lap 12 I pitted. In-Laps and Out-Laps are invalid data anyway, so if we discard those there is already a few issues I can see that need to be worked on:
1. The minimum lap time logged was a 1:30.067. The tick data on lap 7 has a lap of 1:29.609 which is a full 0.4s quicker than it should be. Not sure why, but related is probably point 2:
2. OLD DATA CANNOT BE TRUSTED AT ALL FOR SAMPLING.
All the data for lap times in the data there is off by 20-30ms from the actual game screen:
The replay finished ~170ms faster than the replay that I recorded Wednesday pre-patch:
Wednesday Data time vs Friday Running
Last edited:
- 65
- Brazil
- F1-Bernardo-
I could only find Android app Sim Dash that already has GT7 support (link below)I suppose so far those apps/scripts/programmes only run on Androids?
I know of two devs in iOS working on it currently. I don’t think there’s an iOS app out already with support
If you find any, let us know please!
SIM Dashboard - Apps on Google Play
Freely configurable auxiliary display for your SIM racing and truck games
Last edited:
- 2,228
- Bielefeld
- tarnheld
Found another one: 0x100 is linked to the Top Speed setting of the Transmission controls in the car settings. But it's given as a gear ratio, like a different final drive. It's not the Final Drive ratio, but seems like another final drive ratio. I tested it with a customizable transmission on the Mini Classic, the setting is 3.2 with the stock transmission of the Mini, but with the cusomizable transmission goes from:
2.97325 minimum, corresponds to 150 Top Speed setting (i have km/h as speed display, the values may vary on your game)
1.30725 maximum, corresponds to 800 Top Speed setting
Don't know if these are universal values or if they vary between customizable transmissions on different cars.
I'm no expert in the transmission world, maybe the tuning experts have some thoughts on this? @Harmonic, @praiano63, do you know if the Top Speed setting behaves like the Final Drive setting? What is the difference in Final Drive and Top Speed setting or how do use them together?
EDIT:
And here are some more tidbits:
I realized that there are only 4 bytes of IV/decoding data used in the decryption, so there is actually a new field of glorious data in the packet at 0x44 -- and it's a float! Uhh, what could it be? The Steering Angle maybe?
No, it's just a duplicate of the value at 0x48 -- either 100. or 0.0 ...
EDIT:No, i didn't check thoroughly enough, it's actually the fuel level!
Anyways, i cleared up the packet table, fixed the position of the TCS and ASM bits and incorporated @Bornhall's findings about 0x88.
I also took out my TH-8A shifter and tested the clutch, only to realize that the clutch and clutch-engagement don't go smoothly from 0 to 1 when i press the clutch, but that partways of the clutch press the clutch values will toggle between 0 and 1. Don't know if that's a feature of the TH-8A shifter or a Thrustmaster issue, but now i understand why the clutch always felt rather strange in GT. Has anybody some more experience with other shifters/clutches?
I also checked how the road plane at 0x94 is set up -- my guess it that it is determined by getting the position of the road below the wheels and then putting a plane through these points on the road. You can check this on Streets Of Willow, there are beautiful steep inclindes, ridges and throughs next to the road. If there is a ridge under the car, the ride height/distance to the plane is always bigger than under a planar road, even though the actual ridge touches the underside of the car. Similar for troughs. This also holds when the car is jumping over it. If the car is flying toppled/ tilted 90° to the road, the plane will be updated infrequently and is kind of unstable -- indicating that the wheel points are in a line when projected on the road surface and not forming a plane. But all of this is mainly guesswork, it woul be great if PD would come forward with an explanation for these values.
2.97325 minimum, corresponds to 150 Top Speed setting (i have km/h as speed display, the values may vary on your game)
1.30725 maximum, corresponds to 800 Top Speed setting
Don't know if these are universal values or if they vary between customizable transmissions on different cars.
I'm no expert in the transmission world, maybe the tuning experts have some thoughts on this? @Harmonic, @praiano63, do you know if the Top Speed setting behaves like the Final Drive setting? What is the difference in Final Drive and Top Speed setting or how do use them together?
EDIT:
And here are some more tidbits:
I realized that there are only 4 bytes of IV/decoding data used in the decryption, so there is actually a new field of glorious data in the packet at 0x44 -- and it's a float! Uhh, what could it be? The Steering Angle maybe?
No, it's just a duplicate of the value at 0x48 -- either 100. or 0.0 ...
EDIT:No, i didn't check thoroughly enough, it's actually the fuel level!
Anyways, i cleared up the packet table, fixed the position of the TCS and ASM bits and incorporated @Bornhall's findings about 0x88.
I also took out my TH-8A shifter and tested the clutch, only to realize that the clutch and clutch-engagement don't go smoothly from 0 to 1 when i press the clutch, but that partways of the clutch press the clutch values will toggle between 0 and 1. Don't know if that's a feature of the TH-8A shifter or a Thrustmaster issue, but now i understand why the clutch always felt rather strange in GT. Has anybody some more experience with other shifters/clutches?
I also checked how the road plane at 0x94 is set up -- my guess it that it is determined by getting the position of the road below the wheels and then putting a plane through these points on the road. You can check this on Streets Of Willow, there are beautiful steep inclindes, ridges and throughs next to the road. If there is a ridge under the car, the ride height/distance to the plane is always bigger than under a planar road, even though the actual ridge touches the underside of the car. Similar for troughs. This also holds when the car is jumping over it. If the car is flying toppled/ tilted 90° to the road, the plane will be updated infrequently and is kind of unstable -- indicating that the wheel points are in a line when projected on the road surface and not forming a plane. But all of this is mainly guesswork, it woul be great if PD would come forward with an explanation for these values.
Last edited:
- 722
- montreal,quebec,canada
Any news if there is a way to get more data to sf1000 rim ???
- 69
- Yorkshire, UK
- ddm-999
different API, unfortunately
all of that data isn't in Simulator Interface (also, Sim Interface is player-car only whereas their broadcast interface - which might even require you to be a spectator in a LAN event to start - provides data on all cars, obviously)
Last edited:
- 131
- Oslo
I don't think spectator mode would be efficient as the data will still need to be sent to the server, or cal
It's probably like GT:S where they use a custom client for the live events that provides more data, to be ingested by a controller. I mean, stick 16 Playstations on the same network and we could extract a lot of data in real time, but yeah, it was just a post in jest.
It's definitely a live-only thing due to the fact absolutely none of this data was presented to the user in the online races last week, which gives one of two scenarios heading forward:
1. Online race information and races will be sub-par to in-person events but nothing changes.
2. The data available from replays, or emitted from the Playstation will be more complete, containing more info per car for the online races for Polyphony to collate. But at a cost of the data no longer being available to third-parties at all.
There is a potentially good reason a lot of this data is seemingly locked down or not present, and it boils down to marketing & exclusivity. Tonight showed how bad a lot of the production work was and if this data became easily available to third-parties, it could hurt Polyphony.
True, but let’s not forget that it could also be something linked with the way we communicate with the game. We send a packet containing ‘A’ to a specific port. Maybe sending something else like ‘B’, or to another port would trigger another behavior. Just speculating but hey why not! Who would have expected this telemetry data
Last edited:
- 126
- Sweden
- Bornhall
Finding something like that would more or less be a needle in a haystack though. Not impossible, but I'm pretty certain it would require some kind of inside info (like that software for the motion rig) to be provided before we could make any use of it. But hey, you never know, right!
I tried to examine the traffic between GT Sport and the outside way back, and found that most of the traffic seemed to be encrypted TCP (https), but I never did any UDP or other kind of deep diving at the time. What I was able to see from the traffic was that the in-lobby chat didn't seem to be encrypted (at that time at least). The messages were clear text.
Now I'm not a regular user of tools like wireshark and capturing traffic, but as a spectator in a lobby, you can see all the driver's lap times (even historically over the previous laps). So surely this info is transmitted either P2P or via a PD server so it propagates through to all players in a lobby. I don't recall really examining the UDP traffic at all at the time, but IF said traffic is sent over UDP, maybe it can be examined by a proxy, and possibly decoded? Perhaps someone with more experience with examining packets with such tools could gain more information?
What I would be interested in is a tool/proxy that could run while racing in a lobby, storing/watching every driver's lap times, position and such. If that would somehow be doable, that could lead to real-time leaderboards and such. If anyone is up for something like that, I'd be a happy camper
I don’t think I’ve ever been this excited. 😷
TCP paquets are meant to ensure that the packet is delivered. So laptime or essentials informations like this will be over tcp: imagine a player not receiving a new best lap or something like this (but slower and more time costing)Finding something like that would more or less be a needle in a haystack though. Not impossible, but I'm pretty certain it would require some kind of inside info (like that software for the motion rig) to be provided before we could make any use of it. But hey, you never know, right!
I tried to examine the traffic between GT Sport and the outside way back, and found that most of the traffic seemed to be encrypted TCP (https), but I never did any UDP or other kind of deep diving at the time. What I was able to see from the traffic was that the in-lobby chat didn't seem to be encrypted (at that time at least). The messages were clear text.
Now I'm not a regular user of tools like wireshark and capturing traffic, but as a spectator in a lobby, you can see all the driver's lap times (even historically over the previous laps). So surely this info is transmitted either P2P or via a PD server so it propagates through to all players in a lobby. I don't recall really examining the UDP traffic at all at the time, but IF said traffic is sent over UDP, maybe it can be examined by a proxy, and possibly decoded? Perhaps someone with more experience with examining packets with such tools could gain more information?
What I would be interested in is a tool/proxy that could run while racing in a lobby, storing/watching every driver's lap times, position and such. If that would somehow be doable, that could lead to real-time leaderboards and such. If anyone is up for something like that, I'd be a happy camper
UDP packets don’t provide the mechanism to ensure that the packet is properly delivered, as well that packets might arrive in random order, that’s why the tick field is important to ensure that you’re not processing a packets that was issued few second earlier and eventually to ensure that the packet being processed match to the current/local tick. Better for pushing information a lot of information like telemetry where you can afford loosing some data.
However if a tool like this could be set up, having a real time leaderboard wouldn’t be really useful unless you join it with some text-to-speech to have like a race engineer keeping you up to date with some stuff (penalty ahead, guy behind setting better lap time, driver ahead loosing many position due to crash probably, flags…) and get something like crew chef
- 126
- Sweden
- Bornhall
Yeah, I know the difference 👍🏻
Wasn't sure they used TCP though, I mean considering that the "laggy" behaviour in lobbies, it could possibly be explained with UDP packets not being received in-order (likely discarded). At least that was my reasoning, but for sure, they could use TCP for communications that are critical to arrive (although TCP can time out as well) like fastest lap and such. Mostly I was curious if anyone had looked into this. As we now can get positioning telemetry from the motion rig API (for lack of better description), it could possibly be found in captured traffic knowing it was the same "run" on-track. For that matter, one could reasonably assume that the positioning data that we can dump is the very same data sent to the other clients in the same lobby – possibly the same packets of 296 bytes are sent back to our own client from other cars? Again, just speculating here.
No, my thinking was rather having like an online web-based "current order" of an ongoing streamed league race for example. I.e. all the collected data would be captured by either a driver or a dedicated PSN account spectating a race and updated on a website in pretty much real time (likely something like once a second would be entirely sufficient).
- 6
- Brazil
You are geniuses!!! I'm curious but I lack programming knowledge.
I see that you are already able to program an Arduino to create sensations in the pilot's cockpit, am I correct?
A motor with an off-center axle can be driven according to the temperature of the brake tires.
Did you find anything regarding the sound of the engine and other parts of the car?
I see that you are already able to program an Arduino to create sensations in the pilot's cockpit, am I correct?
A motor with an off-center axle can be driven according to the temperature of the brake tires.
Did you find anything regarding the sound of the engine and other parts of the car?
- 6
- Brazil
You are geniuses!!! I'm curious but I lack programming knowledge.
I see that you are already able to program an Arduino to create sensations in the pilot's cockpit, am I correct?
A motor with an off-center axle can be driven according to the temperature of the brake tires and make the brake pedal vibrate
Did you find anything regarding the sound of the engine and other parts of the car?
I see that you are already able to program an Arduino to create sensations in the pilot's cockpit, am I correct?
A motor with an off-center axle can be driven according to the temperature of the brake tires and make the brake pedal vibrate
Did you find anything regarding the sound of the engine and other parts of the car?
Last edited:
- 2,228
- Bielefeld
- tarnheld
Agree with most of what the others have said to this so far, just some more remarks:Right then boys and girls, Let's work this out
The current packet is a mixed bag -- lot's of very detailed data like road plane, angular acceleration, etc. and on top of that a variety of static car data like gear ratios, rev limiter RPMs. But it's missing crucial data like steering angle, fuel fill level, tire wear, lap sectors, activation bits for assists like ABS,Countersteer assistance and gizmos like NOS/KERS. And some crucial info like race position and number of cars seems bugged.
So while we already got a big improvement with this simulator interface data, it's up to PD to decide if they want to go further with it and fill in some gaps. There is definitely space left in the packet structure to add some of the missing stuff while keeping compatibility. If PD really decides to improve on that, they can also think about splitting the data into several response packet types with several different request packets. Some of the data is constant per race or car like gear ratios or number of race cars. Having a separate request/response packet for this would allow to query this once per race and not send it with every packet. Look at Codemaster's packet format which also evolved into something like this from a single packet format. Let's see where PD goes with this.
We have already identified some use cases with different data needs in this thread, which also suggest having separate packets with separate data and update frequency:
| Use Case | Scenario | Data Needs | Time Resolution |
|---|---|---|---|
| Racing Dashboard | racer wants to see real time info on separate screen when racing | lap time, sector change, lap change + additional info | 1/60s at best, 1/10s OK |
| Racing/Car Setup Analysis | extract log of lap telemetry and analyse after race to improve driving approach or tune the car setup | as much as possible | as high as possible |
| Motion Rig | use realtime data to drive motion rig | car orientation + ? | as high as possible |
| Race Leaderboard | spectator wants to see leaderboard of all racers lap times and race positions + additional info | for all cars driver and car info, race position, lap time, sector change, lap change + additional info | 1/10 at best, 1s OK |
On TCP vs UDP: i think PD could keep UDP, since guaranteed and ordered packets are not necessary here. The simple request/respone scheme can be made reliable enough for a leaderboard/dashboard -- resend request when there is no respone. Logging can work with missing spurious data. Most of the data is 'current' -- get current laptime, get current fill level, etc. No need to get 'past' data.
- 62
- Australia
- gti_sdn
Trying not to take away from the main thread here, but with your proxy and SRS, how much control do we have over bass shakers??I am traveling on vacation but I could not wait to get back home!!! Here is the python script that collects data from the GT and sends to SimRacingstudio (http://www.simracingstudio.com)!!!
GitHub - gt7coder/grandturismo-srs-proxy: This app is a proxy to collect telemetry from the Grand Turismo Series (GT Sport and GT7) and send to the Sim Racing Studio API to drive Wind Simulator, Shakers, Leds, Rumble and Motion platforms from DOF Rea
This app is a proxy to collect telemetry from the Grand Turismo Series (GT Sport and GT7) and send to the Sim Racing Studio API to drive Wind Simulator, Shakers, Leds, Rumble and Motion platforms f...github.com
We can now finally use Wind Simulators, Shakers, Leds, Rumble and Motion platforms from DOFReality (http://www.dofreality.com), ProSimu, PT-Actuator, SFX-100 (With Thanos Controller) and YawVR.
All the credits go to Nenkai to that was able to figure out how to decrypt the telemetry packets from the game: https://github.com/Nenkai/PDTools/tree/master/PDTools.SimulatorInterface I encourage you to donate for him!
Please note that I am not affiliated to SimRacingStudio and I am not responsible for any damage that this could case to you or your equipment
Keep in mind that this is an undocumented API from Grand Turismo Series, the game developer might patch the game and close the door in the future.
@poumpoum can you please give it a try?
Enjoy!
Currently, is it just engine rpm and gear change effects?
Do you think we will get kerb rumble effects?
