Telemetry + Motec Gran Turismo 7

@GeekyDeaks, HELPPPPPP ...

I'm trying to add some channels to Sim-To-Motec!

I noticed that you are not getting the fuel level, turbo & oil pressures, TCS and ASM.

I was also needing to convert speed from mph to kph.

I solved 3 itens (KPH, TCS andASM), but I just don't know how to read FuelLeft, TurboBoost and OilPressure from the packet.

I noticed that you skip some itens:

fmt = struct.Struct(
"<"
"4x" # MAGIC / i / 4x / 0x0000

"12x" # VELOCITY_ANGULAR / 3f / 12x / 0x002C / Skipped!


"4x" # IV / 4B / 4x / 0x0040 / Skipped!
"4x" # CURRENT_FUEL / f / 4x / 0x0044 / Skipped!
"4x" # FUEL_CAPACITY / f / 4x / 0x0048 / Skipped!

"4x" # TURBO_BOOST / f / 4x / 0x0050 / Skipped!
"4x" # OIL_PRESSURE / f / 4x / 0x0054 / Skipped!
"4x" # WATER_TEMP / f / 4x / 0x0058 / Skipped!
"4x" # OIL_TEMP / f / 4x / 0x005C / Skipped!

"4x" # DAYTIME_PROGRESSION / i / 4x / 0x0080 / Skipped!

"2x" # MAX_SPEED / h / 2x / 0x008C / Skipped!

"x" # UNKNOWN / B / x / 0x0093 / Skipped!
"16x" # ROAD_PLANE / 4f / 16x / 0x0094 / Skipped!

"32x" # UNKNOWN_RESRVED / 32B / 32x / 0x00D4 / Skipped!
"4x" # CLUCH / f / 4x / 0x00F4 / Skipped!
"4x" # CLUCH_ENGAGEMENT / f / 4x / 0x00F8 / Skipped!
"4x" # CLUCH_RPM / f / 4x / 0x00FC / Skipped!
"4x" # TOP_SPEED / f / 4x / 0x0100 / Skipped!
"32x" # GEAR_RATIOS / 8f / 32x / 0x0104 / Skipped!

)

How can I retrieve this values?

I'm new on Python and a I couldn't find any mappings ...

Best regards,

cybercic21
 
cybercic21
I noticed that you are not getting the fuel level, turbo & oil pressures, TCS and ASM.
Click to expand...
Funny you should ask... I'm just in the process of adding those! You need to do two things. First change the format from 'x' to whatever it should be e.g.

"4x" # TURBO_BOOST
becomes
"f" # TURBO_BOOST

Then you need to look for line where it uses the format string to unpack the bytearray and assign that element to a variable:

e.g.

self.speed,
self.turbo_boost,
ttfl, ttfr, ttrl, ttrr,
....
) = self.fmt.unpack(buf)

You can take a look at the python docs for structs for more info: https://docs.python.org/3/library/struct.html

I should be pushing the changes once I have testing everything is working ok a little later this week.

cybercic21
I was also needing to convert speed from mph to kph.
Click to expand...
Yeah, I'm thinking of adding a metric/imperial flag for this and possibly other variables. It's rather selfish of me to force everyone to use mph :)
 
Last edited:
GeekyDeaks
Funny you should ask... I'm just in the process of adding those! You need to do two things. First change the format from 'x' to whatever it should be e.g.

"4x" # TURBO_BOOST
becomes
"f" # TURBO_BOOST

Then you need to look for line where it uses the format string to unpack the bytearray and assign that element to a variable:

e.g.

self.speed,
self.turbo_boost,
ttfl, ttfr, ttrl, ttrr,
....
) = self.fmt.unpack(buf)

You can take a look at the python docs for structs for more info: https://docs.python.org/3/library/struct.html

I should be pushing the changes once I have testing everything is working ok a little later this week.


Yeah, I'm thinking of adding a metric/imperial flag for this and possibly other variables. It's rather selfish of me to force everyone to use mph :)
Click to expand...
@GeekyDeaks,

Thanks for the help! All the Xs on the list are skipped ... Now it's clear.

By the way, congrats on calculating the G-Forces!

Do you noticed that InvoGT is also representing Slip Ratio? I'm wondering how ...

Today I found a representation for Pitch, Yaw and Roll (in C#):

pitch = Math.Asin(tmpPacket.Rotation.X) * 360 / Math.PI
yaw = tmpPacket.Velocity.Z
roll = LoopAngle(Math.Asin(tmpPacket.Rotation.Z) * 360 / Math.PI, 180)

I know more about C# than Python (but, still, waaaay less than I wish)!

I deleted this part of your code:

if abs(sample_time - laptime) > (3 / freq):
laptime = sample_time

I was afraid that MoTec i2 would complain about the laptime, but it worked just fine.

I studied a lot about GT7 packets and de first one from each new lap doesn´t fit the 1/60hz.

This was creating some odd lap times in your code ...

Best regards,

cybercic21

PS: I'll try to convert GT7-to-MoTeC for C#! Keep you updated ...
 
cybercic21
yaw = tmpPacket.Velocity.Z
Click to expand...
ok, I would have expected that to be rotation.Y - do you have a link to the entire source file for that bit?

cybercic21
if abs(sample_time - laptime) > (3 / freq):
laptime = sample_time

I was afraid that MoTec i2 would complain about the laptime, but it worked just fine.

I studied a lot about GT7 packets and de first one from each new lap doesn´t fit the 1/60hz.

This was creating some odd lap times in your code ...
Click to expand...
so, just check that the lap position is correctly syncronised... the reason for that bit of code is that i2 calculates the position from the speed and time, not the gps position, I think this is because the GPS is not as accurate in real life. Ensuring the lap starts correctly helps with this, but as you rightly pointed out, can skew the laptime. I hadn't noticed this being out by more than a 1/10th though, are you noticing it drifting a lot more?
 
cybercic21
@GeekyDeaks,

Thanks for the help! All the Xs on the list are skipped ... Now it's clear.

By the way, congrats on calculating the G-Forces!

Do you noticed that InvoGT is also representing Slip Ratio? I'm wondering how ...

Today I found a representation for Pitch, Yaw and Roll (in C#):

pitch = Math.Asin(tmpPacket.Rotation.X) * 360 / Math.PI
yaw = tmpPacket.Velocity.Z
roll = LoopAngle(Math.Asin(tmpPacket.Rotation.Z) * 360 / Math.PI, 180)

I know more about C# than Python (but, still, waaaay less than I wish)!

I deleted this part of your code:

if abs(sample_time - laptime) > (3 / freq):
laptime = sample_time

I was afraid that MoTec i2 would complain about the laptime, but it worked just fine.

I studied a lot about GT7 packets and de first one from each new lap doesn´t fit the 1/60hz.

This was creating some odd lap times in your code ...

Best regards,

cybercic21

PS: I'll try to convert GT7-to-MoTeC for C#! Keep you updated ...
Click to expand...
BTW, all 5 new channels added and working!
 
GeekyDeaks
ok, I would have expected that to be rotation.Y - do you have a link to the entire source file for that bit?


so, just check that the lap position is correctly syncronised... the reason for that bit of code is that i2 calculates the position from the speed and time, not the gps position, I think this is because the GPS is not as accurate in real life. Ensuring the lap starts correctly helps with this, but as you rightly pointed out, can skew the laptime. I hadn't noticed this being out by more than a 1/10th though, are you noticing it drifting a lot more?
Click to expand...
Here, in C#: https://github.com/ashupp/GranTurismoTelemetryProvider

About when packets arrive: https://www.gtplanet.net/forum/threads/gt7-is-compatible-with-motion-rig.410728/post-13810797
 
cybercic21
About when packets arrive: https://www.gtplanet.net/forum/threads/gt7-is-compatible-with-motion-rig.410728/post-13810797
Click to expand...
interesting. I have previously read that info and originally the logic ignored that packet as suggested by the post. I reverted it a while ago though as I actually found the reverse in my environment and I could sync the laptime and sample time closer if I kept it in. You can easily test this by simply adding a 'return' in the 'if statement' where it does the self.add_lap(). When I do it, my 'sample' laptimes are about 1/60th short.

That check for the sample time and reported lap time was to avoid large sync issues in i2, which for me mess up the track position calculations. In practice, I found (and still find) that the outlap is completely off with a negative laptime reported by GT7 and always needs adjustment. The first lap is usually about 6 samples short, but after that things settle down. I did consider simply injecting the missing samples on the first lap, but ended up living with the adjustment of about 1/10th. You could increase the tolerance to allow for the first lap, but check it doesn't throw out the track position for the rest of the laps e.g.

if abs(sample_time - laptime) > (10 / freq):

I'm wondering now if the negative time reported in the outlap is actually an indication of the number of packets that need to be included in the first lap..... hmmm.... I'll check later.

For reference, I did the project to learn both Python (for work) and also MoTeC i2, so I could well be doing something wrong, but this isn't the only thing that I found to not completely agree with the rest of the community. IIRC my unpacking of the direction quaternion is not the same as everyone else. I'm decoding it w,x,y,z whereas the community documentation says it's x,y,z,w. My G forces are all messed up if I do it that way though.

cybercic21
Here, in C#: https://github.com/ashupp/GranTurismoTelemetryProvider
Click to expand...
hmmm... I have searched that code base but I'm at a loss to find the 'yaw = tmpPacket.Velocity.Z' you quoted above. Could you point me at the correct file?
 
GeekyDeaks
if abs(sample_time - laptime) > (10 / freq):

I'm wondering now if the negative time reported in the outlap is actually an indication of the number of packets that need to be included in the first lap..... hmmm.... I'll check later.
Click to expand...
well, I checked and it seems that the outlap is reported as -0.001 seconds, which doesn't match the 6 or so samples lap one is usually short as it ought to be more like -0.1.... either way, upping the threshold to 10 packets in the check seems to have no adverse affects in i2 so I'm probably going to stick with that for now
 
GeekyDeaks
interesting. I have previously read that info and originally the logic ignored that packet as suggested by the post. I reverted it a while ago though as I actually found the reverse in my environment and I could sync the laptime and sample time closer if I kept it in. You can easily test this by simply adding a 'return' in the 'if statement' where it does the self.add_lap(). When I do it, my 'sample' laptimes are about 1/60th short.

That check for the sample time and reported lap time was to avoid large sync issues in i2, which for me mess up the track position calculations. In practice, I found (and still find) that the outlap is completely off with a negative laptime reported by GT7 and always needs adjustment. The first lap is usually about 6 samples short, but after that things settle down. I did consider simply injecting the missing samples on the first lap, but ended up living with the adjustment of about 1/10th. You could increase the tolerance to allow for the first lap, but check it doesn't throw out the track position for the rest of the laps e.g.

if abs(sample_time - laptime) > (10 / freq):

I'm wondering now if the negative time reported in the outlap is actually an indication of the number of packets that need to be included in the first lap..... hmmm.... I'll check later.

For reference, I did the project to learn both Python (for work) and also MoTeC i2, so I could well be doing something wrong, but this isn't the only thing that I found to not completely agree with the rest of the community. IIRC my unpacking of the direction quaternion is not the same as everyone else. I'm decoding it w,x,y,z whereas the community documentation says it's x,y,z,w. My G forces are all messed up if I do it that way though.


hmmm... I have searched that code base but I'm at a loss to find the 'yaw = tmpPacket.Velocity.Z' you quoted above. Could you point me at the correct file?
Click to expand...
Sorry!

It was acctually here: https://github.com/Nenkai/PDTools/compare/master...ashupp:PDTools:master
 
GeekyDeaks
well, I checked and it seems that the outlap is reported as -0.001 seconds, which doesn't match the 6 or so samples lap one is usually short as it ought to be more like -0.1.... either way, upping the threshold to 10 packets in the check seems to have no adverse affects in i2 so I'm probably going to stick with that for now
Click to expand...
After your explanation I've decided to do more tests!

You are right: MoTeC presents some weird stuff without your correction ...

:-(

To make it simple for me, I'll try to analyse your code and propose an C# implementation first ... LOL
 
GeekyDeaks
hmmm... I think that may actually be sway and not yaw as sway is a linear displacement and yaw is the rotation on the axis. I'm not sure about the axis though as I'd expect it to be Y, but maybe the motion rig expects it differently?
Click to expand...
Oh, I think I see what they are are trying to do. For the motion effects, I suspect you could approximate the feeling of rotational yaw by looking at the linear displacement in a perpendicular axis
 
Last edited:
Thanks for the amazing work. I'd be very interested in trying to calculate rake angle in motec, greatly appreciated if anyone has some tips to do this :)
 
Last edited:

Latest Posts

Back