GT7 is compatible with motion rig ?

[Lukejuryous]

I've been lurking this forum for a while now, and this thread made me create an account just to thank everyone's work and effort to get this up and running. I'm absolutely amazed that we went from not having telemetry to being able to set it up in 5 minutes using a laptop and docker over wifi (no physical setup required).

View attachment 1205804
(using Snipem's gt7dashboard)

Looking forward for future developments and hope to contribute somehow. Thanks again everyone!

Your dashboard is sick. I saw your github repo a while back and have been wanting to create something similar. Nice to see that you're still working on it! I'll have to try it out

also, what's the "reference" lap in your example? and "position"? https://github.com/snipem/gt7dashboard/blob/main/README.assets/screenshot.png

 

[siccstepsccs]

This is over my head thanks everyone for the hard work. I have a question would this data help with fine tuning my buttkicker Haptic feed back? Or is this just for motion rigs?

 

[Bornhall]

This is over my head thanks everyone for the hard work. I have a question would this data help with fine tuning my buttkicker Haptic feed back? Or is this just for motion rigs?

No doubt its intended use is for motion rigs, seeing as it sends the data it does. I'm not sure if you can use anything from the data straight up for a buttkicker, at least not without some kind of processing software in between. I mean, sure, you could detect gear shifts and get a haptic feedback for that. Possibly you could pull the suspension travel data and use that, but again, there's no "one and done" solution as far as I know.

 

[Bornhall]

I wanted to inform the frequent visitors to this thread that I am currently working on a simple GT7 dashboard for iOS (only GT7 and iPhone to begin with, likely iOS 14.4 upwards – no Android, so don't ask).

The app itself will in all likelihood be free to download and use, but there will be a link so those who want to can donate via ko-fi.com to support the development. Being a registered Apple Developer costs $99 yearly, so my hope is that donations will eventually cover that cost.

The main dashboard currently looks like this:

A quick explanation of the elements:

• Top left is a bar indicating "reception", which is basically a measurement of how many packets from GT7 are lost (full green bar = all packets received at ~60Hz).
• Top center is a RPM shift bar, indicating from "rpm flash" - 1500 up to "rpm flash". Turns yellow, orange and then red.
• Top right is the time of day on-track, i.e. if you have time progression on, this will follow that.
• Left side pane is current speed in kph (will try to implement mph before release), top speed (can be reset by tapping) and distance travelled (can also be reset by tapping).
• Next to that is brake and throttle bars, with current gear in between. Both goes from 0-100%. Inside the brake and throttle bars are two secondary bars; the one on the brake bar is a bar indicating how much "trail braking" is done, or rather, how much time you spend pressing both brake and throttle pedals simultaneously. The secondary bar on the throttle bar is how much time you spend "coasting", meaning 0% throttle, 0% brake, just rolling. The secondary bars will only record data above a certain speed.
• Below gear indicator is the RPM counter. Nothing much to say about that.
• Below this is the fuel bar. Nothing fancy really, although if/when the app can determine how many laps you can go (based on first and subsequent laps) the bar will color yellow, orange and red for when it's <4, <3 and <2 laps left.
• Below the fuel bar is three calculated values (see above) which shows how many percent fuel was used per lap, how many laps of fuel remains and (if there is an average lap time) how many minutes and seconds the fuel will last.
• Next pane shows the tyres, and displays only temperatures (no wear, since that's not in the data). Each tyre displays two temperatures; the top one is the average over the last 30 seconds, and the bottom one is the current tyre temperature. The top and bottom colors of each tyre will blend from a blue hue to a red hue, with green being "centered" around 85°C.
• The rightmost pane is pretty self explanatory. Current lap is straight from the telemetry data, same goes for last and best laptimes. The average laptime is meant to only count flying laps (I'm working on that), meaning it should not count laps that end in the pitlane (inlap) or start in the pitlane (outlap).

That, as they say, is it, basically. There is no telemetry recording of any kind, nor are there any fancy graphs and such. For now at least I will leave that to other tools.

I am also working on a separate command line app that could work as a "go-between" if someone would want to use the telemetry data for more than one purpose (seeing as the game itself only sends to one IP address). It works using websockets, meaning it is possible to connect to it from a web browser and build from that. It decodes the packets from the game and when asked for data (browser could for example pull data at 10Hz) it will send the latest packet in JSON format. This app is written in Rust, and should be easy to port to both Windows and macOS. More on that in the future.

Now, to stave off a lot of questions of "when is it ready?", "can i test it?" and so forth; I don't know when it will be ready. This is my first app for iOS, and I have no idea what hurdles may be in the way with regard to getting the app on the app store. If and when there is opportunity to actually TEST the app (as in beta testing), I will drop a note here.

The current status is that the app works well in testing, at least on the old iPhone 8 I can test it with (my XCode is too old to push it to my iPhone 14 Pro). There are a few caveats, mainly with regard to determining the status of the car (outlap? flying? in pitlane?) which I am still working on. Also, I have noticed that replays seems to show odd values at times (e.g. fuel level going down a few decimal points and then back up), and I need to determine if it's something I've messed up or if it's just replays being replays (we've been down that road before in this thread).

 

[DJShadesUK]

I wanted to inform the frequent visitors to this thread that I am currently working on a simple GT7 dashboard for iOS (only GT7 and iPhone to begin with, likely iOS 14.4 upwards – no Android, so don't ask).

The app itself will in all likelihood be free to download and use, but there will be a link so those who want to can donate via ko-fi.com to support the development. Being a registered Apple Developer costs $99 yearly, so my hope is that donations will eventually cover that cost.

The main dashboard currently looks like this:
View attachment 1208382

A quick explanation of the elements:

• Top left is a bar indicating "reception", which is basically a measurement of how many packets from GT7 are lost (full green bar = all packets received at ~60Hz).
• Top center is a RPM shift bar, indicating from "rpm flash" - 1500 up to "rpm flash". Turns yellow, orange and then red.
• Top right is the time of day on-track, i.e. if you have time progression on, this will follow that.
• Left side pane is current speed in kph (will try to implement mph before release), top speed (can be reset by tapping) and distance travelled (can also be reset by tapping).
• Next to that is brake and throttle bars, with current gear in between. Both goes from 0-100%. Inside the brake and throttle bars are two secondary bars; the one on the brake bar is a bar indicating how much "trail braking" is done, or rather, how much time you spend pressing both brake and throttle pedals simultaneously. The secondary bar on the throttle bar is how much time you spend "coasting", meaning 0% throttle, 0% brake, just rolling. The secondary bars will only record data above a certain speed.
• Below gear indicator is the RPM counter. Nothing much to say about that.
• Below this is the fuel bar. Nothing fancy really, although if/when the app can determine how many laps you can go (based on first and subsequent laps) the bar will color yellow, orange and red for when it's <4, <3 and <2 laps left.
• Below the fuel bar is three calculated values (see above) which shows how many percent fuel was used per lap, how many laps of fuel remains and (if there is an average lap time) how many minutes and seconds the fuel will last.
• Next pane shows the tyres, and displays only temperatures (no wear, since that's not in the data). Each tyre displays two temperatures; the top one is the average over the last 30 seconds, and the bottom one is the current tyre temperature. The top and bottom colors of each tyre will blend from a blue hue to a red hue, with green being "centered" around 85°C.
• The rightmost pane is pretty self explanatory. Current lap is straight from the telemetry data, same goes for last and best laptimes. The average laptime is meant to only count flying laps (I'm working on that), meaning it should not count laps that end in the pitlane (inlap) or start in the pitlane (outlap).

That, as they say, is it, basically. There is no telemetry recording of any kind, nor are there any fancy graphs and such. For now at least I will leave that to other tools.

I am also working on a separate command line app that could work as a "go-between" if someone would want to use the telemetry data for more than one purpose (seeing as the game itself only sends to one IP address). It works using websockets, meaning it is possible to connect to it from a web browser and build from that. It decodes the packets from the game and when asked for data (browser could for example pull data at 10Hz) it will send the latest packet in JSON format. This app is written in Rust, and should be easy to port to both Windows and macOS. More on that in the future.

Now, to stave off a lot of questions of "when is it ready?", "can i test it?" and so forth; I don't know when it will be ready. This is my first app for iOS, and I have no idea what hurdles may be in the way with regard to getting the app on the app store. If and when there is opportunity to actually TEST the app (as in beta testing), I will drop a note here.

The current status is that the app works well in testing, at least on the old iPhone 8 I can test it with (my XCode is too old to push it to my iPhone 14 Pro). There are a few caveats, mainly with regard to determining the status of the car (outlap? flying? in pitlane?) which I am still working on. Also, I have noticed that replays seems to show odd values at times (e.g. fuel level going down a few decimal points and then back up), and I need to determine if it's something I've messed up or if it's just replays being replays (we've been down that road before in this thread).

(Very) Minor point but rather than use a universally understood wi-fi style icon to represent packets received/lost I'd be inclined to head off any potential confusion by using an icon more representative of data transfer

 

[Bornhall]

(Very) Minor point but rather than use a universally understood wi-fi style icon to represent packets received/lost I'd be inclined to head off any potential confusion by using an icon more representative of data transfer

Good point actually, I will however use the same icon for the first page of the app for connecting, so I will need to have a three-state icon – I will likely design something myself in the end. But point taken 👍🏻

 

[TypeOne]

I wanted to inform the frequent visitors to this thread that I am currently working on a simple GT7 dashboard for iOS (only GT7 and iPhone to begin with, likely iOS 14.4 upwards – no Android, so don't ask).

The app itself will in all likelihood be free to download and use, but there will be a link so those who want to can donate via ko-fi.com to support the development. Being a registered Apple Developer costs $99 yearly, so my hope is that donations will eventually cover that cost.

The main dashboard currently looks like this:
View attachment 1208382

A quick explanation of the elements:

• Top left is a bar indicating "reception", which is basically a measurement of how many packets from GT7 are lost (full green bar = all packets received at ~60Hz).
• Top center is a RPM shift bar, indicating from "rpm flash" - 1500 up to "rpm flash". Turns yellow, orange and then red.
• Top right is the time of day on-track, i.e. if you have time progression on, this will follow that.
• Left side pane is current speed in kph (will try to implement mph before release), top speed (can be reset by tapping) and distance travelled (can also be reset by tapping).
• Next to that is brake and throttle bars, with current gear in between. Both goes from 0-100%. Inside the brake and throttle bars are two secondary bars; the one on the brake bar is a bar indicating how much "trail braking" is done, or rather, how much time you spend pressing both brake and throttle pedals simultaneously. The secondary bar on the throttle bar is how much time you spend "coasting", meaning 0% throttle, 0% brake, just rolling. The secondary bars will only record data above a certain speed.
• Below gear indicator is the RPM counter. Nothing much to say about that.
• Below this is the fuel bar. Nothing fancy really, although if/when the app can determine how many laps you can go (based on first and subsequent laps) the bar will color yellow, orange and red for when it's <4, <3 and <2 laps left.
• Below the fuel bar is three calculated values (see above) which shows how many percent fuel was used per lap, how many laps of fuel remains and (if there is an average lap time) how many minutes and seconds the fuel will last.
• Next pane shows the tyres, and displays only temperatures (no wear, since that's not in the data). Each tyre displays two temperatures; the top one is the average over the last 30 seconds, and the bottom one is the current tyre temperature. The top and bottom colors of each tyre will blend from a blue hue to a red hue, with green being "centered" around 85°C.
• The rightmost pane is pretty self explanatory. Current lap is straight from the telemetry data, same goes for last and best laptimes. The average laptime is meant to only count flying laps (I'm working on that), meaning it should not count laps that end in the pitlane (inlap) or start in the pitlane (outlap).

That, as they say, is it, basically. There is no telemetry recording of any kind, nor are there any fancy graphs and such. For now at least I will leave that to other tools.

I am also working on a separate command line app that could work as a "go-between" if someone would want to use the telemetry data for more than one purpose (seeing as the game itself only sends to one IP address). It works using websockets, meaning it is possible to connect to it from a web browser and build from that. It decodes the packets from the game and when asked for data (browser could for example pull data at 10Hz) it will send the latest packet in JSON format. This app is written in Rust, and should be easy to port to both Windows and macOS. More on that in the future.

Now, to stave off a lot of questions of "when is it ready?", "can i test it?" and so forth; I don't know when it will be ready. This is my first app for iOS, and I have no idea what hurdles may be in the way with regard to getting the app on the app store. If and when there is opportunity to actually TEST the app (as in beta testing), I will drop a note here.

The current status is that the app works well in testing, at least on the old iPhone 8 I can test it with (my XCode is too old to push it to my iPhone 14 Pro). There are a few caveats, mainly with regard to determining the status of the car (outlap? flying? in pitlane?) which I am still working on. Also, I have noticed that replays seems to show odd values at times (e.g. fuel level going down a few decimal points and then back up), and I need to determine if it's something I've messed up or if it's just replays being replays (we've been down that road before in this thread).

This is great, and definitely interested in a release and supporting financially. A couple of questions:
1. Is there any TCS or fuel mapping data to display?
2. Will I be able to design UI dashboards? I don’t actually want to do that as I’d be happy with real world UI’s that represent say the Porsche RSR, Huracan or AMG GT for example.

 

[Bornhall]

This is great, and definitely interested in a release and supporting financially. A couple of questions:
1. Is there any TCS or fuel mapping data to display?
2. Will I be able to design UI dashboards? I don’t actually want to do that as I’d be happy with real world UI’s that represent say the Porsche RSR, Huracan or AMG GT for example.

1. Nope, there's nothing about that in the telemetry, and therefore the app will have no knowledge of it.
2. Afraid not, at least not for any foreseeable future. The UI is built in SwiftUI, and I'm sure there are wizards that could make that happen, but at the moment I would say that's beyond my scope. Besides, anything resembling a real dashboard will have a lot of information missing, seeing that the telemetry is missing a lot of data you probably would have wanted.

My thinking was more along getting the useful information missing on the GT7 HUD, primarily the tyre temperatures, along with things like top speed, fuel per lap, time left until fuel runs out, average laptime and so on.

Take for example the 911 GT3 dash for SIM Dashboard; http://www.stryder-it.de/simdashboard/designs/view?id=25a0&page=1&tag=porsche,realdash

Although there is water temp, oil temp and oil pressure in the telemetry, as far as I know it doesn't change, and since that's the case it's basically a waste of screen space as far as I'm concerned. Your position in the field is not in the telemetry, so the app wouldn't know (why this isn't implemented in the game I have no idea) that either. RPM, gear, speed, fuel is fine, but a lap timer would have to be implemented on the app side (with any and all caveats that comes with that) since that's not in the telemetry either (apart from counting packets, which has proven not entirely reliable).

Anyway, I have full respect for those who want to replicate a real-life dash, but that's not quite on the to-do list for the iOS app at this time.

However, as I mentioned, I will in all likelihood also release a stand-alone executable (command line application) that can be run on Windows or macOS (likely easily ported to Linux or anything else that can compile Rust code as well). That can in turn be queried by a web app, basically a HTML page with javascript and CSS, meaning anyone with the know-how can create/design whatever they like, and share it or host it on any web server. For example, it could be hosted by GTPlanet, you point your browser to the dash you want, enter the local IP of the computer running the go-between app (which in turn listens, locally, to your console) and you're good to go.

 

[pudzian]

That can in turn be queried by a web app, basically a HTML page with javascript and CSS, meaning anyone with the know-how can create/design whatever they like, and share it or host it on any web server. For example, it could be hosted by GTPlanet, you point your browser to the dash you want, enter the local IP of the computer running the go-between app (which in turn listens, locally, to your console) and you're good to go.

Something like ETS2 Telemetry v4.1 COOL 😍 for Android 5.1 without GAPPS best option

 

[TypeOne]

1. Nope, there's nothing about that in the telemetry, and therefore the app will have no knowledge of it.
2. Afraid not, at least not for any foreseeable future. The UI is built in SwiftUI, and I'm sure there are wizards that could make that happen, but at the moment I would say that's beyond my scope. Besides, anything resembling a real dashboard will have a lot of information missing, seeing that the telemetry is missing a lot of data you probably would have wanted.

My thinking was more along getting the useful information missing on the GT7 HUD, primarily the tyre temperatures, along with things like top speed, fuel per lap, time left until fuel runs out, average laptime and so on.

Take for example the 911 GT3 dash for SIM Dashboard; http://www.stryder-it.de/simdashboard/designs/view?id=25a0&page=1&tag=porsche,realdash

Although there is water temp, oil temp and oil pressure in the telemetry, as far as I know it doesn't change, and since that's the case it's basically a waste of screen space as far as I'm concerned. Your position in the field is not in the telemetry, so the app wouldn't know (why this isn't implemented in the game I have no idea) that either. RPM, gear, speed, fuel is fine, but a lap timer would have to be implemented on the app side (with any and all caveats that comes with that) since that's not in the telemetry either (apart from counting packets, which has proven not entirely reliable).

Anyway, I have full respect for those who want to replicate a real-life dash, but that's not quite on the to-do list for the iOS app at this time.

However, as I mentioned, I will in all likelihood also release a stand-alone executable (command line application) that can be run on Windows or macOS (likely easily ported to Linux or anything else that can compile Rust code as well). That can in turn be queried by a web app, basically a HTML page with javascript and CSS, meaning anyone with the know-how can create/design whatever they like, and share it or host it on any web server. For example, it could be hosted by GTPlanet, you point your browser to the dash you want, enter the local IP of the computer running the go-between app (which in turn listens, locally, to your console) and you're good to go.

I appreciate the time to explain so thank you.

Whilst there is a lot of telemetry data missing, bringing through what you have especially with tyre temps, fuel and timings is really, really useful.

This part probably doesn’t make sense I’m sure but I actually don’t mind empty placeholders, simply because I’m looking at it aesthetically.

Here’s an example: https://www.gtplanet.net/forum/attachments/screenshot_20220728-023710_sim-dashboard-png.1177568/

Keep up the great work and will be following your progress.

 

[Jump_Ace]

I wanted to inform the frequent visitors to this thread that I am currently working on a simple GT7 dashboard for iOS (only GT7 and iPhone to begin with, likely iOS 14.4 upwards – no Android, so don't ask).

The app itself will in all likelihood be free to download and use, but there will be a link so those who want to can donate via ko-fi.com to support the development. Being a registered Apple Developer costs $99 yearly, so my hope is that donations will eventually cover that cost.

The main dashboard currently looks like this:
View attachment 1208382

A quick explanation of the elements:

• Top left is a bar indicating "reception", which is basically a measurement of how many packets from GT7 are lost (full green bar = all packets received at ~60Hz).
• Top center is a RPM shift bar, indicating from "rpm flash" - 1500 up to "rpm flash". Turns yellow, orange and then red.
• Top right is the time of day on-track, i.e. if you have time progression on, this will follow that.
• Left side pane is current speed in kph (will try to implement mph before release), top speed (can be reset by tapping) and distance travelled (can also be reset by tapping).
• Next to that is brake and throttle bars, with current gear in between. Both goes from 0-100%. Inside the brake and throttle bars are two secondary bars; the one on the brake bar is a bar indicating how much "trail braking" is done, or rather, how much time you spend pressing both brake and throttle pedals simultaneously. The secondary bar on the throttle bar is how much time you spend "coasting", meaning 0% throttle, 0% brake, just rolling. The secondary bars will only record data above a certain speed.
• Below gear indicator is the RPM counter. Nothing much to say about that.
• Below this is the fuel bar. Nothing fancy really, although if/when the app can determine how many laps you can go (based on first and subsequent laps) the bar will color yellow, orange and red for when it's <4, <3 and <2 laps left.
• Below the fuel bar is three calculated values (see above) which shows how many percent fuel was used per lap, how many laps of fuel remains and (if there is an average lap time) how many minutes and seconds the fuel will last.
• Next pane shows the tyres, and displays only temperatures (no wear, since that's not in the data). Each tyre displays two temperatures; the top one is the average over the last 30 seconds, and the bottom one is the current tyre temperature. The top and bottom colors of each tyre will blend from a blue hue to a red hue, with green being "centered" around 85°C.
• The rightmost pane is pretty self explanatory. Current lap is straight from the telemetry data, same goes for last and best laptimes. The average laptime is meant to only count flying laps (I'm working on that), meaning it should not count laps that end in the pitlane (inlap) or start in the pitlane (outlap).

That, as they say, is it, basically. There is no telemetry recording of any kind, nor are there any fancy graphs and such. For now at least I will leave that to other tools.

I am also working on a separate command line app that could work as a "go-between" if someone would want to use the telemetry data for more than one purpose (seeing as the game itself only sends to one IP address). It works using websockets, meaning it is possible to connect to it from a web browser and build from that. It decodes the packets from the game and when asked for data (browser could for example pull data at 10Hz) it will send the latest packet in JSON format. This app is written in Rust, and should be easy to port to both Windows and macOS. More on that in the future.

Now, to stave off a lot of questions of "when is it ready?", "can i test it?" and so forth; I don't know when it will be ready. This is my first app for iOS, and I have no idea what hurdles may be in the way with regard to getting the app on the app store. If and when there is opportunity to actually TEST the app (as in beta testing), I will drop a note here.

The current status is that the app works well in testing, at least on the old iPhone 8 I can test it with (my XCode is too old to push it to my iPhone 14 Pro). There are a few caveats, mainly with regard to determining the status of the car (outlap? flying? in pitlane?) which I am still working on. Also, I have noticed that replays seems to show odd values at times (e.g. fuel level going down a few decimal points and then back up), and I need to determine if it's something I've messed up or if it's just replays being replays (we've been down that road before in this thread).

That dashboard look pretty sick! Very well done buddy!


Jerome

 

[Bullwinkle]

I wanted to inform the frequent visitors to this thread that I am currently working on a simple GT7 dashboard for iOS (only GT7 and iPhone to begin with, likely iOS 14.4 upwards – no Android, so don't ask).

The app itself will in all likelihood be free to download and use, but there will be a link so those who want to can donate via ko-fi.com to support the development. Being a registered Apple Developer costs $99 yearly, so my hope is that donations will eventually cover that cost.

The main dashboard currently looks like this:
View attachment 1208382

A quick explanation of the elements:

• Top left is a bar indicating "reception", which is basically a measurement of how many packets from GT7 are lost (full green bar = all packets received at ~60Hz).
• Top center is a RPM shift bar, indicating from "rpm flash" - 1500 up to "rpm flash". Turns yellow, orange and then red.
• Top right is the time of day on-track, i.e. if you have time progression on, this will follow that.
• Left side pane is current speed in kph (will try to implement mph before release), top speed (can be reset by tapping) and distance travelled (can also be reset by tapping).
• Next to that is brake and throttle bars, with current gear in between. Both goes from 0-100%. Inside the brake and throttle bars are two secondary bars; the one on the brake bar is a bar indicating how much "trail braking" is done, or rather, how much time you spend pressing both brake and throttle pedals simultaneously. The secondary bar on the throttle bar is how much time you spend "coasting", meaning 0% throttle, 0% brake, just rolling. The secondary bars will only record data above a certain speed.
• Below gear indicator is the RPM counter. Nothing much to say about that.
• Below this is the fuel bar. Nothing fancy really, although if/when the app can determine how many laps you can go (based on first and subsequent laps) the bar will color yellow, orange and red for when it's <4, <3 and <2 laps left.
• Below the fuel bar is three calculated values (see above) which shows how many percent fuel was used per lap, how many laps of fuel remains and (if there is an average lap time) how many minutes and seconds the fuel will last.
• Next pane shows the tyres, and displays only temperatures (no wear, since that's not in the data). Each tyre displays two temperatures; the top one is the average over the last 30 seconds, and the bottom one is the current tyre temperature. The top and bottom colors of each tyre will blend from a blue hue to a red hue, with green being "centered" around 85°C.
• The rightmost pane is pretty self explanatory. Current lap is straight from the telemetry data, same goes for last and best laptimes. The average laptime is meant to only count flying laps (I'm working on that), meaning it should not count laps that end in the pitlane (inlap) or start in the pitlane (outlap).

That, as they say, is it, basically. There is no telemetry recording of any kind, nor are there any fancy graphs and such. For now at least I will leave that to other tools.

I am also working on a separate command line app that could work as a "go-between" if someone would want to use the telemetry data for more than one purpose (seeing as the game itself only sends to one IP address). It works using websockets, meaning it is possible to connect to it from a web browser and build from that. It decodes the packets from the game and when asked for data (browser could for example pull data at 10Hz) it will send the latest packet in JSON format. This app is written in Rust, and should be easy to port to both Windows and macOS. More on that in the future.

Now, to stave off a lot of questions of "when is it ready?", "can i test it?" and so forth; I don't know when it will be ready. This is my first app for iOS, and I have no idea what hurdles may be in the way with regard to getting the app on the app store. If and when there is opportunity to actually TEST the app (as in beta testing), I will drop a note here.

The current status is that the app works well in testing, at least on the old iPhone 8 I can test it with (my XCode is too old to push it to my iPhone 14 Pro). There are a few caveats, mainly with regard to determining the status of the car (outlap? flying? in pitlane?) which I am still working on. Also, I have noticed that replays seems to show odd values at times (e.g. fuel level going down a few decimal points and then back up), and I need to determine if it's something I've messed up or if it's just replays being replays (we've been down that road before in this thread).

I can't wait for this! I'll happily donate to your project when it's live.

One question/request: I thought I read somewhere that the torque numbers were available. Is this true, and if so can that be added with the RPMs? For me the active torque would be the holy grail for figuring out shifting points in fuel saving races, etc. This would be perhaps the most useful tool for me.

 

[SE3P_HKG]

Please add a lap analysis function would be fantastic!

 

[Bornhall]

One question/request: I thought I read somewhere that the torque numbers were available. Is this true, and if so can that be added with the RPMs? For me the active torque would be the holy grail for figuring out shifting points in fuel saving races, etc. This would be perhaps the most useful tool for me.

Sorry to say, but there is no telemetry data about torque curves in the telemetry. The game of course has this info, it's just not available from the telemetry. Preferably I would stay away from including static data such as this in the app itself, but I have been pondering if it is feasible to for a specific car id (this IS included in the telemetry) fetch the shifting points for each gear (upshift should be enough) from an external source of some kind. That way it's easy to update when the game is updated.

Please add a lap analysis function would be fantastic!

A lap analysis function would indeed be fantastic, but at least for an initial release there will be no such functionality. Several reasons, one being it is my first ever iOS app and I'm learning as I go, basically. Another reason is that the app will in all likelihood be pretty power hungry as it is (my old iPhone at least gets pretty warm), so further on-device processing may cause more energy consumption and possibly also cause lag in the telemetry (only seen this in the iOS simulator). Maybe not a huge problem, but still.

Besides, personally I find it much more informative and useful to examine the telemetry data after the fact, and the app as such does not store or log the telemetry data apart from the last minute of tyre temperatures. Again, not impossible to do, but we're talking storing data 60 times per second, and even if it is possible (raw telemetry data is something like 60+ megabyte per hour) you'd need some way of managing stored data (delete, export etc).

That's the reason for the stand-alone app (for macOS and Windows); that any other app can connect to and fetch data in JSON format, regardless if it's a "simple" web application or a full blown native GUI app. What is done with that data is up to the individual developer of course, and could very well be used for logging and analysis. The stand-alone app as such is basically finished, but I would like to clean up and test the example web client a bit as well as put together a bit of documentation for anyone wishing to use it.

But, any and all suggestions are welcome!

---

As it stands, the app is working quite well. I'm still wrestling with trying to detect what "state" you're at in-game (menus, in pitlane, outlap, flying etc) with some kind of confidence. Some tracks are notoriously annoying for passing the finish line while in the pitlane (Interlagos comes to mind), while others are even weirder (Tokyo Expressway's parking garage pitlane). This makes it damn hard to keep track of whether you're on a flying lap or not. One possibility would be to simply ignore this and count ALL laps towards the average lap time, at least for now. We'll see about that.

I've implemented a toggle to switch between kph/mph, but tyre temps are still only °C for now. There is also a demo mode. For two reasons; one being Apple wanting to be able to "test" the app before admitting it to the app store, the other to allow me to use pre-recorded data from the game to simulate the telemetry rather than me getting in the rig each time!

Been busy with some other things the past week, but I hope to be able to get back on it before the end of the week 👍🏻

 

[MRFast]

I want this so bad, but not real familiar with what you guys are doing, can anyone break it done so the average joe can get a sim rig moving. I currently have a PS4, and GT Sport. Want to build the sim rig, pretty sure I can get thru that, but need help getting the info out of the PS4, thru the network switch and into a PC. Any help would be much appreciated, and I apologize if it is here and I missed it, I know its here, I just need the "for dummies" version.

 

[Bornhall]

I want this so bad, but not real familiar with what you guys are doing, can anyone break it done so the average joe can get a sim rig moving. I currently have a PS4, and GT Sport. Want to build the sim rig, pretty sure I can get thru that, but need help getting the info out of the PS4, thru the network switch and into a PC. Any help would be much appreciated, and I apologize if it is here and I missed it, I know its here, I just need the "for dummies" version.

Well, to be fair, the easiest way must surely be to buy a complete package, and in that case I think I would go for something from https://www.simrig.se – they have support for GT Sport and GT7 in their software (as far as I know). Sure, it's not DIY, but could be considered the "for dummies" version.

 

[MRFast]

Well, to be fair, the easiest way must surely be to buy a complete package, and in that case I think I would go for something from https://www.simrig.se – they have support for GT Sport and GT7 in their software (as far as I know). Sure, it's not DIY, but could be considered the "for dummies" version.

Ok, maybe the "well I know a lil bit" version, I can build the rig, just need help getting info from the PS4 to switch to computer.

 

[jeimuki]

This has been such an awesome development. Big thanks to everyone who got this stuff working.
I picked up the TensionR belt tensioner from PT Actuators that I use with https://github.com/gt7coder/grandturismo-srs-proxy, GT7 and PS5.
I get heave effects and cornering forces but nothing on breaking. In other words no surge. Any ideas on why that wouldn't work?

 

[Bornhall]

Ok, maybe the "well I know a lil bit" version, I can build the rig, just need help getting info from the PS4 to switch to computer.

If you don't want to go with a finished product, I know @nokazito built his own rig, maybe he can be of assistance here?

 

[Evis]

If you don't want to go with a finished product, I know @nokazito built his own rig, maybe he can be of assistance here?

Hi, I've been following your project for a long time and am very much looking forward to any release.

May i ask a question, is there any way to know or judge track name from telemetry data?

I saw your answer on Github, thanks so much for your answer!

Tracing race line might be a possible way to speculate track, that could avoid difference from pit start or rolling start.
Another possible way is record and comparing car's position when crossing the finish line.

Either way requires a lot of data and effort.

 

[Bornhall]

Status report on the app for iOS that I am working on:

I think I have managed to more or less solve the problem of detecting going into the pits, I just need to verify as good as I can that it is indeed working on all tracks to at least a decent accuracy. Edge cases may always be present, but hey...

The reason for detecting going into the pits is because I want the "Average lap time" display to show ACTUAL flying laps, and ignore the in- and outlaps.

I currently have two beta testers, and the app seems reasonably stable across iOS devices (including at least an M1 Mac). I'm pretty sure that I could release it as it is, but there are a few things I still want to make sure works. I had a crash yesterday when I quit the game while the app was running. In all likelihood nothing major, but still.

I have already had a donation (some sleuthing must have gone on there, I have yet to mention a donation link) towards the project (thank you, if you read this you know who you are), which is highly appreciated and motivating. Not quite in the ballpark of buying a new Mac 😂, so currently the app is compiled in a virtual machine running macOS 12. Slow, but doable.

I am also looking into the idea @Evis proposed above, regarding identifying the track. Maybe not hugely useful as it stands at the moment, but who knows what the future may hold? Knowing the track may bring some kind of benefit.

Also working away on documentation. Currently in Google Docs, but will be served from one of my own domains eventually.

Note: Anyone in this thread who is up for beta testing a bit closer to release may send me a DM here. If I don't answer, please refrain from spamming me, or I will likely block you. If I respond it will be on my terms, if and when I decide to. As a tester you will need an iOS device with iOS 14 or higher, preferably an iPhone-like device since it's not aimed at anything else. I will require your real name and the e-mail you use for your Apple ID, so if you are unwilling to part with that, don't bother requesting to be a tester.

The name of the app will be EzioDash. Our italian greyhound Ezio decided that it would be a good name for something related to racing 🤣

 

[C_L]

Hi All - just want to also add my admiration to the posters here. Well done everyone. I'm don't want to derail the thread but if I could interject with some questions on getting Gran Turismo in motion given the fast pace of development which occurred over the past few months - I'd appreciate any/all feedback.

I have a PS5, Gran Turismo 7, wheel/pedals/shifter and buttkicker on a static rig right now. I am looking to purchase a DOF Reality H3 rig with SFU Gearbox units, Vesa mount and MagicBox. I reached out to DOF Reality and Igor assured me the aforementioned rig idea will work all together. Before I submit payment I'm looking for clarity on setup.

My understanding is I get the rig, assemble it, bring over the peripherals, do initial setup on the MagicBox, put it on the same wi-fi network as the PS5, download the gt7coder github open source package (thanks Nenkai), extract that package to the MagicBox(?) and it will then automatically have native support within SRS software where it will get the GT7 UDP data in realtime by virtue of them being on the same wi-fi network and I can adjust values on intensity of motions and make adjustments for buttkicker signal. Is that accurate and/or is it that simple - no adjustments on the PS5 side of things? I have not seen any SRS user interface pictures of GT7 in action so I'm guessing these are adjustable bits. The MagicBox looks like a Rasberry Pi 4 units with four USB channels and an ethernet port. I assume the MagicBox is hardwire connected to the the DOF Reality H3 controller box via USB cable, similarly I have an OG red unit buttkicker and may need to run a cheapo USB soundcard to connect to the MagicBox via USB but that should be recognized in the SRS software as the data line out to the buttkicker from whatever the GT7 API information is deemed appropriate for that experience (ideally rumble strips only).

On a side note and I may be entirely out of line asking but I see the Github package poster has been banned here, won't ask for details, but should I be alarmed by that regarding this pursuit of idiot-proof consumer level motion rig purchase? I see only the July 28th release is available and no other updates have come, is that still a valid package for the current GT7 1.27 version? Are any members here apart of that process that would make its way into the SRS universe for a dummy like me to use?

Lastly is this the same process to get GT Sport working with the motion rig, as well?

Once purchased, assembled and working, I'll make a video for the casual gamers to get a walk through on assembly and usage so I can pay it forward for the other luddites out there to get a dummy-proof virtual racing rig.

Thanks in advance and Happy Holidays all.
-Colin

 

[nokazito]

I’m not familiar with the SRS MagicBox but if they claim it does that, then I’d expect it to work.
Note however:
“Many factors influence latency when using a Wi-Fi connection. The Wi-Fi speed of the router and how far the Magicbox is physically from the router with have the most impact. Ensure the MagicBox is as close as possible to your Wi-Fi router and utilize a router that supports the highest possible connection type in the table above. “
I’d avoid using the WiFi, in my experience it didn’t work great having telemetry packets delivered via wifi but yours may vary.
I don’t understand why you’d need any github repo. The Magicbox should be all you need to get motion in the platform. If you want to do some other stuff with that data, then you’ll need a PC and maybe don’t need the MagicBox?

cheers and enjoy!

 

[nokazito]

Btw, in my view, that amount of money for a raspberry pi is outrageous and a rip-off. You pay for a license and that software should be free and deployable on any raspberry pi.
mine is free and it runs on a raspberry pi 3

 

[Bornhall]

Btw, in my view, that amount of money for a raspberry pi is outrageous and a rip-off. You pay for a license and that software should be free and deployable on any raspberry pi.
mine is free and it runs on a raspberry pi 3

To be fair, I assume you not only pay for the RPi, but also possibly for the R&D of the backend and support. But yeah, there are cheaper solutions for sure, if you're willing to put in the time. Other than that, I agree with your points.

 

[nokazito]

To be fair, I assume you not only pay for the RPi, but also possibly for the R&D of the backend and support. But yeah, there are cheaper solutions for sure, if you're willing to put in the time. Other than that, I agree with your points.

I thought that’s what the license cost is for, no? If the PC software is free and you need a license to run it, so should the RPi/Linux software. But here we’re talking about a product and taking the RPi3 cost aside (with power adapter, case, uSD card) it is a lot of money to pay.
The problem here, as with everything sim-racing, is the niche and opportunity to ask a lot of money for stuff that doesn’t necessarily cost that much to build, especially today.
I agree R&D is painful, especially if you do everything custom, in this particular case however, I don’t really see it.
“Change my mind!”

 

[Bornhall]

“Change my mind!”

Haha, well, as you, I have not done any "in-depth" look into the product, and I have zero experience with the software itself. But if the product is supposed to be plug-n-play as is, and judging by the instructions, it seems they have built some kind of server backend (no idea if this is the same in the PC software) that is pretty much configurable via a browser. That in itself is quite a bit of work, and if that software is specific for this implementation (I assume running on Linux), I'd say a little cost is justified. Also, I have no idea about the availability of RPi3, but there has been a scarcity of at least RPi4 that I know of, and that may have driven up the hardware prices.

 

[nokazito]

Haha, well, as you, I have not done any "in-depth" look into the product, and I have zero experience with the software itself. But if the product is supposed to be plug-n-play as is, and judging by the instructions, it seems they have built some kind of server backend (no idea if this is the same in the PC software) that is pretty much configurable via a browser. That in itself is quite a bit of work, and if that software is specific for this implementation (I assume running on Linux), I'd say a little cost is justified. Also, I have no idea about the availability of RPi3, but there has been a scarcity of at least RPi4 that I know of, and that may have driven up the hardware prices.

Without dragging this for too long as is it off-topic, I've done this already and all my software is running on a RPi3 and I have PC and Console games support with a web server (python) to allow for control over the motion software.. and I'm just one guy with not-so-much free time

 

[C_L]

Nokazito and Bornhall - thanks for responding. I had an initial concern about the wi-fi as well and inquired with Igor about it. I've got to figure out how to get everything together as the modem, router and rig are in different parts of the of house. But that's neither here nor there. And I can't speak intelligently to the rPi costs but to me to looks reasonable: $55 for the SRS license cost + ~$75 for an rPi4 with case/power + some 15% for indirects/contingency/overhead/shrinkage leaves about $50 for entrepreneurial incentive. Or maybe my estimates are completely off here and we're talking about free software and $5 in parts - truly, I don't know, just going off what Google shows me on the first page.

Nokazito - I cannot stress how much convenience is worth to a casual gamer like myself. I understand I'm stepping on the toes of the DIY enthusiasts ethos here so I apologize for my candor; please bring affordable products and service to market. I'm certainly one of many misinformed, unfortunately cheap, lazy and gullible spenders entering this marketspace. Well that's not fair to say; I remember tinkering with this same buttkicker, a Thrustmaster GT and triple head 2 go to play iRacing nearly 15 years ago when I was finishing my undergrad. Then as now, the software setup side intimidates me, with less patience now to tinker.

A thought I had with the forthcoming PSVR2 - given the cameras are pointing out of the headset, would that in theory reduce the VR motion compensation requirement?

Looks like I'll be ordering this evening. Will update as it goes. Thanks again.

 

[nokazito]

I totally get the convenience aspect. I couldn’t find anywhere the info that the license is included in the price for the MagicBox. Could you use the same license on a PC if needed?
Happy shopping!