Overview of GT7 Telemetry Software

  • Thread starter snimat
  • 247 comments
  • 103,495 views
Hey there guys. My name is Mac and I'm the creator of the GT7 UDP Tool for the ESP8266 which I've seen mentioned earlier in this thread. I'm curious about these new "B" and "~" packets people are talking about that were added in update 1.42. I didn't have time to update my library as of recent as I had exams, does anybody have any more info about what was added in these new versions?

You can find the details here. Check out from Bornhall, from my analisys ~ packets are bringing the "raw" brake and acceleration input from the driver, and this data is not visible from replays, only when you are driving.
 

You can find the details here. Check out from Bornhall, from my analisys ~ packets are bringing the "raw" brake and acceleration input from the driver, and this data is not visible from replays, only when you are driving.

Interesting. Will do some investigating. Thank you!
 
Hey there guys. My name is Mac and I'm the creator of the GT7 UDP Tool for the ESP8266 which I've seen mentioned earlier in this thread. I'm curious about these new "B" and "~" packets people are talking about that were added in update 1.42. I didn't have time to update my library as of recent as I had exams, does anybody have any more info about what was added in these new versions?
There are sway, heave and surge apparently, and unfiltered (depending on how you look at it) throttle and brake traces. What I know is available here;



Edit: sorry, didn’t scroll down enough (I’m on phone atm) and missed that there was a reply already :)
 
Last edited:
I want to call out to the devs who are doing more "analysis-focused" software for the telemetry data, guys like @snimat and @BluesJiang – I've had several people ask me about the exported data from EzioDash Pro, which is basically just the "raw" output from the game, and I've had to tell them that there is no real "app" for offline analysis of the data as of yet.

So here's the chance to "fill the gap", so to speak, by making it possible to import the .gt7td binary data (decoded packets from the game) into your app for offline analysis. If there were more hours in a day, I'd have likely done it myself, but seeing as there are already very nice solutions out there, I figured it would be better to not reinvent the wheel.

If anyone is interested, drop me a DM or send me an email. If you already have an app for data analysis, it shouldn't be much work to allow it to import (or stream) the telemetry data exported from EzioDash pro.
 
I want to call out to the devs who are doing more "analysis-focused" software for the telemetry data, guys like @snimat and @BluesJiang – I've had several people ask me about the exported data from EzioDash Pro, which is basically just the "raw" output from the game, and I've had to tell them that there is no real "app" for offline analysis of the data as of yet.

So here's the chance to "fill the gap", so to speak, by making it possible to import the .gt7td binary data (decoded packets from the game) into your app for offline analysis. If there were more hours in a day, I'd have likely done it myself, but seeing as there are already very nice solutions out there, I figured it would be better to not reinvent the wheel.

If anyone is interested, drop me a DM or send me an email. If you already have an app for data analysis, it shouldn't be much work to allow it to import (or stream) the telemetry data exported from EzioDash pro.
How is the data serialised? As one big byte array, I'm doing offline analysis in the the application too, so I assume it would not be to hard for me to import the data.
 
How is the data serialised? As one big byte array, I'm doing offline analysis in the the application too, so I assume it would not be to hard for me to import the data.
Yep, just chunks of data, same size as the packets received from the game, only decoded using salsa20. The packet size is in the accompanying json file.
 
Yep, just chunks of data, same size as the packets received from the game, only decoded using salsa20. The packet size is in the accompanying json file.
I hope you are aware that GT7 could be a bit messy, for example if you are using your phone and you are sending ~ heartbeat, and the user start another app on computer and the other app is using A type of packets, you will receive A type of packet on your app, because the other app start sending A heartbeats first. And if the other app stop sending packets, after few seconds you will start receiving your requested ~ type of packets, and now the gotcha :D this switch between type packets can happen within one lap, so you can have mixed types of packets :D
 
I hope you are aware that GT7 could be a bit messy, for example if you are using your phone and you are sending ~ heartbeat, and the user start another app on computer and the other app is using A type of packets, you will receive A type of packet on your app, because the other app start sending A heartbeats first. And if the other app stop sending packets, after few seconds you will start receiving your requested ~ type of packets, and now the gotcha :D this switch between type packets can happen within one lap, so you can have mixed types of packets :D
Not really, each type of packet has a different “magic” value, and at least in my case I will discard a packet with a non matching value. But yes, that could cause a problem, in theory.
 
Back