Overview of GT7 Telemetry Software

  • Thread starter Thread starter snimat
  • 368 comments
  • 174,262 views
OTA update demo (staged rollout + worst-case hardware test)

Just a quick followup to the post above. Here is a full end-to-end demo of the OTA pipeline doing its job.



What's happening in the video
  • I upload a new software version through the hawkBit web frontend
  • I roll it out to the "dev" distribution channel only
  • The instrument cluster checks and sees the new version is available for its channel and pulls it down
  • It installs the update and reboots
  • It comes back up running the new version


Why the "dev channel" matters
This is the same staged-rollout pattern real vehicle fleets use. They don't push an update to every car at once; they rather push it to a canary group first, watch it behave and only then widen the rollout. The instrument-cluster's update channels work the same way: dev, and eventually a stable channel for everyone else, so a bad build never has to reach every device at the same time.

One detail worth pointing out
I ran this demo on a Raspberry Pi 5 with a VERY slow SD card on purpose. Wanted to see the update pipeline handle a sluggish I/O scenario rather than only showing the happy path on ideal hardware. It completed the download, install, and reboot without issue.

This is a proper update pipeline with targeted rollout groups, the same shape as what's used on actual vehicle software fleets, just running on a cheap board instead of a car's ECU cluster.
 

GT7 Track Identification from Telemetry – using Pit Box Coordinates as a Track Fingerprint​

I've been experimenting with ways to identify the current track in Gran Turismo 7 using only the UDP telemetry data, without relying on a Track ID.

I had an idea that might make this much simpler.

Every circuit has a pit lane, and when the car is in its pit box its world position can be read from telemetry as X/Y/Z coordinates.

My idea is to use the pit box position as a kind of track fingerprint.

For example, a database could contain something like:

Track A:
Pit position: X / Y / Z

Track B:
Pit position: X / Y / Z

Track C:
Pit position: X / Y / Z

When GT7 places the car in the pit box, the telemetry receiver could compare the current coordinates against this database and potentially identify the circuit immediately — without needing to drive a complete lap.

Even if different teams/cars are assigned slightly different pit boxes, I suspect that the group of possible pit positions for each circuit would still occupy a unique area in GT7's world coordinate system.

Another possibility would be to store additional information about the pit lane, such as:

  • X/Y/Z range of all pit boxes
  • orientation/heading of the car in the pit
  • pit lane direction
  • relative positions of several pit boxes
This could produce a stronger fingerprint than a single coordinate.

If two circuits happened to have similar pit coordinates, the identification could then be confirmed using telemetry collected after leaving the pits — for example the elevation profile (Y) relative to travelled distance, or a short section of the X/Z trajectory.

The goal would be to identify the track after only a few telemetry samples, ideally even before the car starts driving.

Has anyone experimented with this approach?

In particular, does anyone know whether the pit box X/Y/Z coordinates are stable between sessions and whether each circuit/layout uses its own coordinate space?

I'd be interested to hear from anyone who has collected GT7 position telemetry across multiple tracks.
 
gbech_pl

GT7 Track Identification from Telemetry – using Pit Box Coordinates as a Track Fingerprint​

I've been experimenting with ways to identify the current track in Gran Turismo 7 using only the UDP telemetry data, without relying on a Track ID.

I had an idea that might make this much simpler.

Every circuit has a pit lane, and when the car is in its pit box its world position can be read from telemetry as X/Y/Z coordinates.

My idea is to use the pit box position as a kind of track fingerprint.

For example, a database could contain something like:

Track A:
Pit position: X / Y / Z

Track B:
Pit position: X / Y / Z

Track C:
Pit position: X / Y / Z

When GT7 places the car in the pit box, the telemetry receiver could compare the current coordinates against this database and potentially identify the circuit immediately — without needing to drive a complete lap.

Even if different teams/cars are assigned slightly different pit boxes, I suspect that the group of possible pit positions for each circuit would still occupy a unique area in GT7's world coordinate system.

Another possibility would be to store additional information about the pit lane, such as:

  • X/Y/Z range of all pit boxes
  • orientation/heading of the car in the pit
  • pit lane direction
  • relative positions of several pit boxes
This could produce a stronger fingerprint than a single coordinate.

If two circuits happened to have similar pit coordinates, the identification could then be confirmed using telemetry collected after leaving the pits — for example the elevation profile (Y) relative to travelled distance, or a short section of the X/Z trajectory.

The goal would be to identify the track after only a few telemetry samples, ideally even before the car starts driving.

Has anyone experimented with this approach?

In particular, does anyone know whether the pit box X/Y/Z coordinates are stable between sessions and whether each circuit/layout uses its own coordinate space?

I'd be interested to hear from anyone who has collected GT7 position telemetry across multiple tracks.
Click to expand...
Unfortunately, the tracks do not inhabit unique global coordinates. I didn’t specifically test pit box locations, but I did compare start/finish positions across every layout. There is enough overlap that coordinates alone cannot uniquely identify the track.

The coordinates themselves are stable from session to session, so you can rely on that. The problem is uniqueness, not stability.

In practice, identification requires observing the car’s movement for a few seconds until its trajectory diverges from other candidate layouts.

Determining the exact layout can be even harder. Some layouts (for example, Spa) are identical on the racing surface and differ only in pit exit. If the car never enters the pits, telemetry alone provides no evidence to distinguish them.

Also worth noting: two GT7 layouts don’t have pit facilities at all, so a pit-based fingerprint can’t work universally.
 
Last edited:
Lord Grey
Unfortunately, the tracks do not inhabit unique global coordinates. I didn’t specifically test pit box locations, but I did compare start/finish positions across every layout. There is enough overlap that coordinates alone cannot uniquely identify the track.

The coordinates themselves are stable from session to session, so you can rely on that. The problem is uniqueness, not stability.

In practice, identification requires observing the car’s movement for a few seconds until its trajectory diverges from other candidate layouts.

Determining the exact layout can be even harder. Some layouts (for example, Spa) are identical on the racing surface and differ only in pit exit. If the car never enters the pits, telemetry alone provides no evidence to distinguish them.

Also worth noting: two GT7 layouts don’t have pit facilities at all, so a pit-based fingerprint can’t work universally.
Click to expand...
That makes sense. One thing I’m wondering about is whether adding yaw could reduce the number of collisions significantly.

Instead of comparing only X/Y/Z, the fingerprint could use:

X/Y/Z + yaw

and also limit the comparison to a smaller area around a known reference point, for example the starting grid or pit box position.

Even if two layouts have overlapping coordinates, their car orientation at that point may be different enough to separate them.

It would be interesting to test how many collisions remain after adding yaw and narrowing the coordinate tolerance/area.
 
gbech_pl
That makes sense. One thing I’m wondering about is whether adding yaw could reduce the number of collisions significantly.

Instead of comparing only X/Y/Z, the fingerprint could use:

X/Y/Z + yaw

and also limit the comparison to a smaller area around a known reference point, for example the starting grid or pit box position.

Even if two layouts have overlapping coordinates, their car orientation at that point may be different enough to separate them.

It would be interesting to test how many collisions remain after adding yaw and narrowing the coordinate tolerance/area.
Click to expand...
Yes, yaw may reduce the number of collisions substantially, especially if the goal is only to identify the circuit or venue.

The harder question is identifying the exact layout. Multiple layouts at the same venue can share the same pit area, grid, start line, direction, and much of the racing surface. In those cases, X/Y/Z plus yaw at a single reference point (well, within a small area around a point) may still be identical.

So I think this would be worth testing, but the result depends on what you need:
  • Venue identification: position plus yaw may be a strong fingerprint.
  • Exact layout identification: it may narrow the candidates, but a short trajectory or reaching a layout-specific section may still be required.
I may have assumed you meant exact layout identification. If you only need the venue, your approach is more promising.
 
Last edited:
What you are describing is basically what I use for EzioDash Pro, and it is most definitely possible to use this approach to identify tracks. But, it is a LOT of work, and it is far from 100%. And as Grey mentions, detecting the various layouts (Maggiore for example) adds yet another layer to it.
 
Bornhall
What you are describing is basically what I use for EzioDash Pro, and it is most definitely possible to use this approach to identify tracks. But, it is a LOT of work, and it is far from 100%. And as Grey mentions, detecting the various layouts (Maggiore for example) adds yet another layer to it.
Click to expand...
I agree that yaw would probably help a lot with normal vs reverse layouts, since the car orientation should be very different.

The harder case is when two layouts share the same grid, coordinates and direction, and only diverge somewhere further around the circuit. In that case I don’t think XYZ + yaw can identify the exact layout while the car is stationary.

It may still be useful to identify the circuit immediately and narrow the result down to a small group of possible layouts, then resolve the exact layout only when the car reaches a distinguishing section.

I’ll do some testing and we’ll see how it works. Thank you everyone for the suggestions! :)
 
Last edited:
gbech_pl
It may still be useful to identify the circuit immediately and narrow the result down to a small group of possible layouts, then resolve the exact layout only when the car reaches a distinguishing section.
Click to expand...
Yep, exactly how I do it. Sort by elevation first, match on gates by pit exit or finish line, then check divergence by the candidates still in the running.
 

Latest Posts

Back