Telemetry + Motec Gran Turismo 7

[cybercic21]

@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

 

[GeekyDeaks]

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

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.

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

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

 

[cybercic21]

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

@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 ...

 

[GeekyDeaks]

yaw = tmpPacket.Velocity.Z

ok, I would have expected that to be rotation.Y - do you have a link to the entire source file for that bit?

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 ...

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 ...

BTW, all 5 new channels added and working!

 

[cybercic21]

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?

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

 

[GeekyDeaks]

About when packets arrive: https://www.gtplanet.net/forum/threads/gt7-is-compatible-with-motion-rig.410728/post-13810797

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.

Here, in C#: https://github.com/ashupp/GranTurismoTelemetryProvider

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.

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

 

[cybercic21]

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?

Sorry!

It was acctually here: https://github.com/Nenkai/PDTools/compare/master...ashupp:PDTools:master

 

[cybercic21]

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

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]

Sorry!

It was acctually here: https://github.com/Nenkai/PDTools/compare/master...ashupp:PDTools:master

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?

 

[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?

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

 

[STS_frequency]

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