GT7 is compatible with motion rig ?

[Bornhall]

It can be started/stopped

Suggestion, check bit 0 and 3 of 0x8E, I think you could use bit 0 and 3 to more or less start and stop logging (bit 0=1 and bit 3=0 seemingly means entered race, and is out on track). With some logic, you should be able to listen for bit 0 to change from 0 to 1, and first time bit 3 switches from 1 to 0 (don't take my word for this) it should mean car enters the track proper for first time after "enter track". When bit 3 switches to 1 it looks to me like it's in pit lane, so could possibly pause the logging and restart again when bit 3 switches back.

Just me thinking out "loud" here

 

[BlazingDragon]

Suggestion, check bit 0 and 3 of 0x8E, I think you could use bit 0 and 3 to more or less start and stop logging (bit 0=1 and bit 3=0 seemingly means entered race, and is out on track). With some logic, you should be able to listen for bit 0 to change from 0 to 1, and first time bit 3 switches from 1 to 0 (don't take my word for this) it should mean car enters the track proper for first time after "enter track". When bit 3 switches to 1 it looks to me like it's in pit lane, so could possibly pause the logging and restart again when bit 3 switches back.

Just me thinking out "loud" here

Thanks. I'll look into that. Checking the actual data packets and only logging / keeping / displaying the relevant ones would be very useful... both with real-time capture, and post-race reviewing and analyzing saved data packets...

My current implementation is that you simply type 's' to start, and 'h' to halt.... (and 'r' to reset the data already collected to zero) - and it just stops/starts the actual collection of the data from the UDP socket...

BTW, your screen output is way more refined than I've put together so far... I may "borrow" your display code if that's OK?... ;-)

 

[gt7coder]

I have added the compiled release and instructions how to execute:

To run the app download the latest release from: https://github.com/gt7coder/grandturismo-srs-proxy/releases
Open a console window where you downloaded the grandturismo-srs-proxy.exe and type:
.\grandturismo-srs-proxy.exe --playstation_ip 192.168.0.89

 

[kjeldsen]

I'm very old too... ;-) and I wish that the Amiga was still around...(damn incompetent Commodore management :-( )

I wrote my Masters (of Computer Science) thesis on an Amiga [A1200] in 1995... All the C code (it was a 3D graphics program with a MUI based GUI), and the thesis document itself was written and output on it too (to Postscript, so it could be bound into a book )...

Back on topic, I also have a python version working, which runs the data logging in a background task.
It can be started/stopped, the collected data reset, and now has functionality to save the (decrypted, but un-parsed) data packets to memory, write them to a binary file, and (re)load them...

The actual screen output needs cleaning up (and adding the newly discovered variables over the past few days), and then I can share if anyone's interested...

AMIGA 1000 was my first personal computer, from there it's been downhill ever since. It kinda stopped when i discovered the MISTer/FPGA project ()

Most villagers here would be happy with a primitive mockup interface that runs from a .EXE
I don't know how much work a straight telemetry tool would require and maybe it would be easier to simply save the needed data in a .CSV file that we could open in EXCEL/Google Apps.

For those who don't fear python, I may share few snippets (dirty) to have save telemetry in file and plot them

Here we have tyres temp - speed - Throttle/Brake for one lap around Monza.

EDIT: files missings

Something like this with live data would be pretty crazy :-)

 

[BlazingDragon]

Most villagers here would be happy with a primitive mockup interface that runs from a .EXE
I don't know how much work a straight telemetry tool would require and maybe it would be easier to simply save the needed data in a .CSV file that we could open in EXCEL/Google Apps.

I'll be adding a save to CSV option today for that exact purpose...

 

[Hyurt]

Something like this with live data would be pretty crazy :-)

Yes, maybe I should drop some packets for live display, like using 10packets per seconds could be an alternative

I don't know how much work a straight telemetry tool would require and maybe it would be easier to simply save the needed data in a .CSV file that we could open in EXCEL/Google Apps.

Make sure to save small portion, 60 * row per seconds can be a lot of data when dealing with long sessions haha


EDIT: divising using 1/6 packet is not that bad, could be better but a step forward

 

[Saargasm]

Ugh why didn't I learn to code when it was right in front of me when I used to frequent mIRC "Warez" servers back in the late 90's!?! I "learned" later in life how analytical my brain is and wish I would have pursued it at the time - just didn't know anyone else who coded that I could have learned with.

Loving this thread though! Amazing what everyone is coming up with and how quick it is developing - can't wait for the apps that will come out (fingers crossed PD doesn't do PD things and disable it).

Not sure this has the capability, but I've always wished GT7 provided "feedback" about your lap performance with areas to address to improve lap times - like braking early/late, throttle early/late or bad lines etc. Heck, I just want to have the ability to see previous race results with lap times, total time & ending positions so I can compete against myself.

 

[Stoobert]

Thanks. I'll look into that. Checking the actual data packets and only logging / keeping / displaying the relevant ones would be very useful... both with real-time capture, and post-race reviewing and analyzing saved data packets...

My current implementation is that you simply type 's' to start, and 'h' to halt.... (and 'r' to reset the data already collected to zero) - and it just stops/starts the actual collection of the data from the UDP socket...

BTW, your screen output is way more refined than I've put together so far... I may "borrow" your display code if that's OK?... ;-)

Flags is what I have been using to start/stop data collection:

That there is looking at the flags and for each packet only logging if the car is "On Track" and the game isn't in a paused state. It's writing the raw decrypted bytes out to a file for now because it's better than trying to pickle the object and I can't be bothered right now to do JSON / BSON conversion.

Most villagers here would be happy with a primitive mockup interface that runs from a .EXE
I don't know how much work a straight telemetry tool would require and maybe it would be easier to simply save the needed data in a .CSV file that we could open in EXCEL/Google Apps.

Something like this with live data would be pretty crazy :-)

I've been playing with this for a while in Python... Short vid of it in action... (At time of posting HD is still rendering, but it's still legible) and still very much a work in progress.

 

[Bornhall]

I may "borrow" your display code if that's OK?

Go right ahead! 👍

 

[tarnheld]

Updated my packet table and expanded the fields that had multiple unrelated contents. Also added the flag bits description.
Unfortunately i couldn't find any flag bits for ABS, Countersteer Assistance, Auto Pilot. Seems that some of the bits in the flags are never set. Has anyone tried the flags with a car that has NOS installed or some kind of KERS? Maybe some flag bits light up when these are activated...

Also missing is fuel consumption and body damage. Well, PD has some space left to put that info into packets of a later version...

 

[DJShadesUK]

I'll be adding a save to CSV option today for that exact purpose...

Any chance of adding user selectable values too? I just want to be able to import a file of X,Y,Z location coordinates into Blender 3D and make 3D point clouds of the tracks (or more specifically their actual elevations for some 3D motion graphics stuff.

I've been playing with this for a while in Python... Short vid of it in action... (At time of posting HD is still rendering, but it's still legible) and still very much a work in progress.

 

[tarnheld]

Regarding 0x94 and the 4 mystery floats: They could well be the coefficients of a plane equation. First 3 are the plane normal, fourth one is the dot product of a vector to some point on the plane with the normal. This would explain the erratic value of this coefficient.

This would describe a plane in space. Which plane could it be? The road surface below the car? The underside of the car? I think we need to visualize it to understand what's going on. Will give this some more thought.

 

[Bornhall]

Also, one thing I am "missing" is steering angle... Considering there is throttle and brake, one would think steering angle would be included, but it seems not to be. At least nothing I have been able to determine.

 

[Bornhall]

Regarding 0x94 and the 4 mystery floats

I've been mulling a lot of things, but nothing I've thought of seems to fit. I've seen 0x98 hit 1.0000 at times, so it seems to cap at that value, but hovers around 0.97-0.99 usually from what I've seen. But as you say, 0xA0 could be some kind of reference plane, question is what? I don't think it's related to anything like weather, time of day and any such things.

Slippage? Downforce? G-forces?

Has anyone checked if these packets really are floats? I just assume they are, but one wonders what they represent if they are broken out into other chunks (shorts, ints).

Also, as for the packet table, I believe that 0x88 is the value for where the rev limiter kicks in. At first I thought that the values were for low and high end of the rev bar thingy in the middle of the HUD, but as far as I can tell the 0x88 value is where the rev limiter seems to kick in, and where the AI shifts up. So what the other rpm value at 0x8A is for, I do not know. I have yet to correlate it to anything in-game. Could it possibly be related to some kind of boost or nitro, sending the engine rpm rocketing?

 

[Stoobert]

Has anyone checked if these packets really are floats? I just assume they are, but one wonders what they represent if they are broken out into other chunks (shorts, ints).

Also, as for the packet table, I believe that 0x88 is the value for where the rev limiter kicks in. At first I thought that the values were for low and high end of the rev bar thingy in the middle of the HUD, but as far as I can tell the 0x88 value is where the rev limiter seems to kick in, and where the AI shifts up. So what the other rpm value at 0x8A is for, I do not know. I have yet to correlate it to anything in-game. Could it possibly be related to some kind of boost or nitro, sending the engine rpm rocketing?

I was playing with different formats for the really weird 0x48 but haven't tried anything for this 4-tuple.
And I thought the 2 rev limiter values, I thought one was the actual limiter you bounce off, and the lower was when the bar would start flashing when you hit redline.

 

[Stoobert]

Anyway, I took an evening off coding this to play with the data in Pandas. Someone mentioned Blender earlier so I thought I would give it a go...

 

[DJShadesUK]

Anyway, I took an evening off coding this to play with the data in Pandas. Someone mentioned Blender earlier so I thought I would give it a go...

View attachment 1177911

Thats exactly what I want to do... but better!

The screengrab is a bit difficult to make out but are you instancing a cube on every coord and scaling its bottom face to 0 on the Y axis? Looks like there is a lot of Z, Y and Z fighting going on?

I have a better solution but its a bit long winded to type and I'm tired so I'll get back to you later!

 

[BlazingDragon]

Any chance of adding user selectable values too? I just want to be able to import a file of X,Y,Z location coordinates into Blender 3D and make 3D point clouds of the tracks (or more specifically their actual elevations for some 3D motion graphics stuff.

Well, you could just import the full .csv file into Excel and delete the columns you don't need... but, since you asked nicely, I've added the option to export only position values... :-)
(and the full CSV export function isn't finished yet (lots of tedious typing), and it was very quick to just export 3 values per packet.. )

Update: Code added to GitHub

Note: To obtain the .csv output, the process is a bit convoluted at the moment - you capture the data in realtime, then export it as raw data, then re-import it, and then export a .csv (with position only data...).. only takes a few seconds though..

Thats exactly what I want to do... but better!

The screengrab is a bit difficult to make out but are you instancing a cube on every coord and scaling its bottom face to 0 on the Y axis? Looks like there is a lot of Z, Y and Z fighting going on?

I have a better solution but its a bit long winded to type and I'm tired so I'll get back to you later!

There's an example "position only" .csv file of 2 laps around the High Speed Ring included in the repo, and the data traces that go with it (see below).
(I sample on every 5th captured packet).

 

[BlazingDragon]

Suggestion, check bit 0 and 3 of 0x8E, I think you could use bit 0 and 3 to more or less start and stop logging (bit 0=1 and bit 3=0 seemingly means entered race, and is out on track). With some logic, you should be able to listen for bit 0 to change from 0 to 1, and first time bit 3 switches from 1 to 0 (don't take my word for this) it should mean car enters the track proper for first time after "enter track". When bit 3 switches to 1 it looks to me like it's in pit lane, so could possibly pause the logging and restart again when bit 3 switches back.

Just me thinking out "loud" here

I've added this functionality, but using the following values:
( using tarnheld's table)

bit 0 == 1    #   1 for "On track".  This is still set to 1 after the race is finished and game is in the post-race screens...
bit 1 == 0    #   Game Paused : 1 for paused, 0 for not paused
bit 3 == 1    #   "In-gear"??  I'm using it right now, but perhaps shouldn't be....

 

[Sixerito]

Hi, I try to receive UDP from receivePort on my PC with wireShark or my custom android code, but i don't receive any packet...Only I receive with the simulatorInterface.exe.

What I am doing wrong?

 

[Hyurt]

Hi, I try to receive UDP from receivePort on my PC with wireShark or my custom android code, but i don't receive any packet...Only I receive with the simulatorInterface.exe.

What I am doing wrong?

You need first to send a packet to the console to the right port

 

[tarnheld]

I played around with the 0x94 plane equation idea, and it seems to go into the right direction. Tried projecting the 0x04 Position point onto the plane, and get the nearest distance of the Position to the plane, and guess what -- the distance matches the Ride Height in 0x38! If the car is firmly seated on track the distance is quite low, so Position might be the center of gravity of the car. When jumping it can get quite high indicating the height of the jump. It doesn't matter how the car is oriented, it can also be up-side-down. So the plane is the road surface at some point below the car. Is it directly below the car, i.e. along the Y axis? Or is it the nearest point on the road? The difference will be obvious when jumping:

The green distance to the road directly below the car will be more than the red distance to the nearest point on the road.
So i'm off to go jumping and logging at Fisherman's Ranch...

Here is some shoddy python code for projecting a point onto a plane:

Spoiler: Point Plane Projection

def proj_point_on_plane(a,b,c,d,x,y,z):
    D=-d-a*x-b*y-c*z
    l=a*a+b*b+c*c
    X=a*D/l
    Y=b*D/l
    Z=c*D/l
    xp = X+x
    yp = Y+y
    zp = Z+z
    D2 = X*X+Y*Y+Z*Z
    DD = math.sqrt(D2)
    # return point on plane closest to (x,y,z) and distance
    return (xp,yp,zp,DD)

# use like this:
# get position from packet
posx,posy,posz=struct.unpack_from('fff',ddata,0x4)
print('pos %f %f %f' %(posx,posy,posz))
# get plane equation from packet
nx,ny,nz,d = struct.unpack_from('ffff',ddata,0x94)
print('0x94 %f %f %f %f' %(nx,ny,nz,d))

# do the projection of the position
px,py,pz,pd = proj_point_on_plane(nx,ny,nz,d,posx,posy,posz)
print("pp:",px,py,pz,pd)

# pd should match the ride height
rht = struct.unpack_from('f',ddata,0x38)
print('ride height %f, diff ride height and plane dist %f' %(rht,pd-rht))

I've added this functionality, but using the following values:

I noticed that the Bit 3 will change to 0 when shifting, but for detection of the race start it should be ok if you check that all three bits "in race, not paused and in gear" are set, and after that if you want to determine when the race has ended, you can check only for "not in race and not paused". Take this with a grain of salt, i haven't figured out all intricacies of these bits.

 

[Skidude88]

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!

Anyone using this structure note there are two 'POSITION' tags (ln42 & ln62). Suggest you rename the 2nd 'LAP_POSITION'

 

[Stoobert]

Thats exactly what I want to do... but better!

The screengrab is a bit difficult to make out but are you instancing a cube on every coord and scaling its bottom face to 0 on the Y axis? Looks like there is a lot of Z, Y and Z fighting going on?

That's exactly it. I do not know the first thing about 3D modelling, meshing or any of that jazz, so I figured I would just plot every 10th point (so every 166ms) and like you say, stretch the "up" direction ( I say that because GT has that on Y but my Blender setup has that on Z and it wasa just an experiment).

You can see it better here.

I have a better solution but its a bit long winded to type and I'm tired so I'll get back to you later!

That would be interesting. See, because I know nothing about this. The cube creation code was basically just ripped from StackOverflow and ingested.

 

[Stoobert]

Playing around a bit more, I have added materials to the cubes and gave them colours based on the throttle / brkae maps, which now gives an interesting look.
Green is throttle, Red is brake. Obviously the brighter the colour the more the pedal is depressed. Yellow is both brake and throttle at the same time (usually downshifing under braking). Black is no throttle or break (coasting or gear change engaging the clutch).

 

[Hyurt]

Anyone using this structure note there are two 'POSITION' tags (ln42 & ln62). Suggest you rename the 2nd 'LAP_POSITION'

Edited, thanks

 

[Scoverio]

I have added the compiled release and instructions how to execute:

To run the app download the latest release from: https://github.com/gt7coder/grandturismo-srs-proxy/releases
Open a console window where you downloaded the grandturismo-srs-proxy.exe and type:
.\grandturismo-srs-proxy.exe --playstation_ip 192.168.0.89

View attachment 1177704

This is a great step for me, thanks so much.
Where can i find info on passing the streaming data to Sim Racing Studio, or otherwise dump it to file?
EDIT: nevermind, it's already capturing it fine! Thanks so much!

 

[gt7coder]

This is a great step for me, thanks so much.
Where can i find info on passing the streaming data to Sim Racing Studio, or otherwise dump it to file?
EDIT: nevermind, it's already capturing it fine! Thanks so much!

Please give it a try and let me know if all the directions are ok, specially directions of the g-forces.

I will be adding also the suspension travel and velocity this weekend.

 

[DJShadesUK]

Playing around a bit more, I have added materials to the cubes and gave them colours based on the throttle / brkae maps, which now gives an interesting look.
Green is throttle, Red is brake. Obviously the brighter the colour the more the pedal is depressed. Yellow is both brake and throttle at the same time (usually downshifing under braking). Black is no throttle or break (coasting or gear change engaging the clutch).

View attachment 1178051

I'm so dumb. Although CSV export is a valuable tool, for importing data into spreadsheets and whatnot, its actually trivial to directly export to an OBJ file too (which is, after all, just a text file), thus removing the necessity of using CSV import scripts in Blender and making the location data directly usable by practically every 3D app on the planet!

o object_name
v x1 y1 z1                      #1st vertex
v x2 y2 z3                      #2nd vertex                                     
l 1 2                           #edge between v1 and v2                                       
v x4 y4 z4                      #3rd vertex
l 2 3                           #edge between v2 and v3
# ...
v x500 y500 z500                #499th vertex
l 500 1                         #edge between v499 and v1

# Using some actual data from the CSV you uploaded to Github an obj would look like this... */

o GTS/7_Data_Export_DATETIME
v -45.3038 0.1534 -384.7457
v -43.4513 0.1531 -384.7441
l 1 2
v -41.5985 0.1516 -384.7418
l 2 3
#... fastforward a few lines ;)
v -55.9469 0.1659 -387.4492
l 1202 1203
v -50.8208 0.1601 -387.4175
l 1203 1204

# The "l" lines could be omitted to essentially create a point cloud.

As you've noticed though the data would require minor reformatting to accommodate the different "up" axis (a similar problem sometimes happens with normal maps from game-ripped assets having the "wrong" vertical axis, although thats easily fixed in Blender at least using material seperateXYZ and combine XYZ nodes... I wish 3D apps and 3D game engine makers would just decide on one "up" axis and stick to it! ).

 

[Scoverio]

I'm so dumb. Although CSV export is a valuable tool, for importing data into spreadsheets and whatnot, its actually trivial to directly export to an OBJ file too (which is, after all, just a text file), thus removing the necessity of using CSV import scripts in Blender and making the location data directly usable by practically every 3D app on the planet!

o object_name
v x1 y1 z1                      #1st vertex
v x2 y2 z3                      #2nd vertex                                    
l 1 2                           #edge between v1 and v2                                      
v x4 y4 z4                      #3rd vertex
l 2 3                           #edge between v2 and v3
# ...
v x500 y500 z500                #499th vertex
l 500 1                         #edge between v499 and v1

# Using some actual data from the CSV you uploaded to Github an obj would look like this... */

o GTS/7_Data_Export_DATETIME
v -45.3038 0.1534 -384.7457
v -43.4513 0.1531 -384.7441
l 1 2
v -41.5985 0.1516 -384.7418
l 2 3
#... fastforward a few lines ;)
v -55.9469 0.1659 -387.4492
l 1202 1203
v -50.8208 0.1601 -387.4175
l 1203 1204

# The "l" lines could be omitted to essentially create a point cloud.

As you've noticed though the data would require minor reformatting to accommodate the different "up" axis (a similar problem sometimes happens with normal maps from game-ripped assets having the "wrong" vertical axis, although thats easily fixed in Blender at least using material seperateXYZ and combine XYZ nodes... I wish 3D apps and 3D game engine makers would just decide on one "up" axis and stick to it! ).

Eheh, the issue with right and left-handed coordinate systems is old as CGI is, and unfortunately it doesn't look like it's going to go anywhere, ever.
On the plus side, the transformation is super simple to achieve, so hey, it's definitely an annoyance, but not a deal breaker.