GT7 is compatible with motion rig ?

  • Thread starter poumpoum
  • 686 comments
  • 186,231 views
As far as I can tell, there is no N (neutral) for GT7, so when the value is 0, that is R (reverse). Anything above 0 seems to correspond to the equivalent gear. Note though that I haven't checked for EVs with more than 1 gear (Taycan seems to have 2), if they display gear correctly.
I also tried for neutral with the old Maserati, and you can get it into neutral with the clutch, and neutral shows up in Gears as -1 or 15, all 4 bits are on.
 
From what I've seen, two of the three first ones are very small values, hovering around 0. The second of the three (0x98) seems to hold just below 1, at 0.99... and don't change much. The fourth value (0xA0) varies a lot, both positive and negative, and may well go towards a value (like say 50) on braking, but remains at that value after stopping...

Can't really make head or tail of these (0x94-0xA0)... Possibly if someone could graph them along with a replay, it would be possible to make something of them.

Either way it's fun to dig in to some detective work :D
I plotted a kart lap on a round course with the data of unknown semantics 0x94, 0x98, 0x9c, 0xA0:
See circle_kart.txt for the actual data. It is a HTML file, so please rename to circle_kart.html.

Here is the Youtube video with the lap as a replay. The plot starts when the timer is clocking the lap.

I made some odd moves at the end. It shows at 0x98 and 0x9c. I made the same plot in Spa, where I had a peak for 0x94 and 0x98 in Eau Rouge. Maybe it is related to downforce?

You can hover over the data points to get an index. The index is also used in the lap diagram on the top right. So you can make out the position.

Hope you can make something out of it. I could not.
1659728477239.png
 
Last edited:
Hope you can make something out of it. I could not.
This is a description of the plane of the road below the car tires, in a fancy mathematical dressing. See this post for further info. The distance of the car position to this plane is the ride height. I guess it might come in handy to calculate some other stuff, maybe in relation to the suspension or for a motion rig, but for now it's rather uninteresting for racing dashboard usage. You could calculate the current road inclination or banking from this plane, or you could determine if the car is flipped or doing a ski stunt.
 
As far as I can tell, there is no N (neutral) for GT7, so when the value is 0, that is R (reverse). Anything above 0 seems to correspond to the equivalent gear. Note though that I haven't checked for EVs with more than 1 gear (Taycan seems to have 2), if they display gear correctly.
There is a neutral - in GT Sport and in GT7, if you have a G29 and a H shifter you can get to the neutral. I will have a look tonight if nobody can before
 
Another thing i was pondering is if the actual time between each packet could be exactly 1/60s. The difference of the millisecond timestamp in each packet is varying between 16 and 17ms for consecutive packets and i guess you measured the packet arrival time and it boils down to the same difference on average. But PD might actually measure the data at simulation steps that are really exactly 1/60s apart. The millisecond timestamps in the data could be rounded and thus inaccurate. Trying to measure packet arrival time might also be the wrong thing to do since it would be most accurate to have the time of measurement.

You might want to replace the packet time difference in your time delta code with the constant 1/60 and see if there is any improvement in accuracy, or if i am wrong and accuracy goes to hell. Both would be valuable insights. Will try to shed some light on this as well.
So I checked the constant packet time of 1/60 and that's why I moved to packet arrival time as some of the laps were half a second off. I also couldn't really make it any more precise by just replacing the logic with the time progression, but, well two insights have come from this:

1. When pausing the game and using the +1 lap / -1 lap sliders on the replay to position the car at the beginning of the lap. The car's positional x/y/z ALWAYS matches the first packet I logged for the new lap, i.e. the first packet of a new lap is ALWAYS when the car crosses the timing line, regardless of how long it has been since the last packet.
2. Time progression is not always linear. This is likely expected at the beginning of a lap from (1), but I am investigating more.
 
Last edited:
A followup. 3 columns:
Col 1: Lap time in the packet data
Col 2: Lap time calculated from time progression
Col 3: Lap time calculated from packet arrival times.
1659780337734.png


(lap 1 is off due to the timer starting way before the car reaches the s/f line to go from lap 0 -> lap 1).

I can see that the lap times are not too dissimilar so I think I will use them in place of capturing packet timings to avoid that extra source of computation and storage for no real discernable benefit.

Actual time progression fluctuations (I worked out a 5x time multiplier, hence the division):
1659786232030.png

Over the course of the race, each lap packet time means are very accurate to 10us. I wonder if we can use that as a constant going forward for each packet timing...

Nope. Not any more accurate. I am so confused as to where all the time goes on some laps:
1659787922345.png

Every method is nearly 20ms short which is nearly always more than 1 packet. I can only think of 2 possibilities:

1. the last packet describing the end of the circuit is discarded when you cross the start/finish line to start the next lap so the last packet timing needs calculating
2. I pointed out earlier that lap times displayed in replay (at least from earlier patches) do not match lap times in the log. It's been a while since I raced on GT7 so I am wondering if part of these differences can be chalked up to (undocumented or known) physics changes between patches and the game playing "catchup" in the replay when things go awry (hence why older patches don't display laptimes in the replay) and the data isn't correct.

I'll do a race and see what happens.

EDIT: Just did a 5 lap "race" around Tsukuba with bots on the controller:
1659789917081.png

Those are looking much more stable packet times.
 
Last edited:
Lap time from difference in time progression: 2:00.239
Lap time from differences in packets arriving at my PC : 2:00.236
Lap time from deriving time from distance between two points using pythagoras and packet meters-per-second values: 2:00.237
Lap time from taking packets at a constant 1/60th of a second: 2:00.133

Lap time from wattching replay: 2:00.266
Lap time from packet data: 2:00.255

So I am stumped as to what is going on.
 
So I am stumped as to what is going on.
PD is going on :lol:

I'm a little jealous of that Android app, I hope someone gets something out for iOS as well soon, I have an old-ass iPad laying around that could serve a new purpose.
 
Ok, so I decided to move on from trying to get approximate lap times from the packets and just assume that the data is at least consistent inside the packet data, so I decided to knock up a nice Dash dashboard to analyse the data. I'm not good at styling so ignore that for now, but the data is at least usable.
  • Laps can be selected via dropdown or boxed on the lap time chart.
  • hovering over the speed graph will highlight the point on the lap chart where the hover is.
  • You can box or lasso parts of the lap map zoom in and focus on that area.
  • Files can just be dropped in to a folder to be loaded.

1659885622708.png
 
So I am stumped as to what is going on.
This bugged me as well and i could reproduce your problems as well. Spent a considerable amount of time on this, and long-story-short: the PD packet timing madness is cracked! I can reproduce the current lap time for every packet as it is displayed in GT7 without relying on the day time progression, i just need the packet counter, the lap number and a very crucial ingredient: the last lap time. So bear with me as i try to unravel the wondrous puzzle PD has presented to us...

So first off, the assumption that the packets are measured every 1/60 seconds is correct for almost all packets, but not for one very special packet -- the packet you will get that has a new lap number in it. This packet also contains the last lap time. This packet is measured at a different time on the timeline and you will get this point through a calculation that is pretty involved. So let me set the scene of the packet train and it's timing, below you see each packet with it's packet number, the time delta it represents, and the total elapsed time we can calculate from the packet deltas. You also see that only the packets where the lap increases have a different time delta:

packet number1234567891011...
packet lap01111222233...
packet time delta1/60A1/601/601/60B1/601/601/60C1/60...
elapsed time1/601/60
+A
2/60
+A
3/60
+A
4/60
+A
4/60
+A+B
5/60
+A+B
6/60
+A+B
7/60
+A+B
7/60
+A+B+C
8/60
+A+B+C
...
lap time
on arrival of packet
001/60-A2/60-A3/60-A3/60-A+B1/60-A-B2/60-A-B3/60-A-B3/60-A-B+C1/60-A-B-C

You see that we have to accumulate all the special packet time deltas to get an accurate elapsed time. One more specialty to be aware of: the packets arrive also when the game/replay is paused. You can determine if a packet is paused from the flags. A paused packet has effectively a zero time delta.

So how do we get to the special packet time deltas? It is also right there in the packet table: each lap time is the sum of all normal packets plus the time of one extra packet, and we get the lap time of the last lap in every packet. So get can get the time delta by summing up all normal packet time deltas and subtracting from that the last lap time. As a generous gitft, PD made the time delta of the first special packet zero.

With these ingredients we can build a lap time counter that will show the exact same time that PD shows in the game. Here is a very rough demo, you should start it before starting a race or TT as it needs to receive all packets or all laps, but it will print out the same current lap time as in the game:

Python:
import socket
import sys
import struct
import math
import datetime
# pip3 install salsa20
from salsa20 import Salsa20_xor

#https://github.com/Nenkai/PDTools/blob/master/SimulatorInterface/SimulatorInterface.cs
SendDelaySeconds = 10

ReceivePort = 33740
SendPort = 33739

port = ReceivePort

if len(sys.argv) == 2:
    # Get "IP address of Server" and also the "port number" from
    ip = sys.argv[1]
else:
    print("Run like : python3 pd-lapcounter-demo.py <playstation-ip>")
    exit(1)

# Create a UDP socket
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
# Bind the socket to the port
server_address = ('0.0.0.0', port)
s.bind(server_address)
s.settimeout(10)

#https://github.com/Nenkai/PDTools/blob/master/PDTools.Crypto/SimulationInterface/SimulatorInterfaceCryptorGT7.cs
def salsa20_dec(dat):
  KEY = b'Simulator Interface Packet GT7 ver 0.0'
  oiv = dat[0x40:0x44]
  iv1 = int.from_bytes(oiv, byteorder='little') # Seed IV is always located there
  iv2 = iv1 ^ 0xDEADBEAF #// Notice DEADBEAF, not DEADBEEF
  IV = bytearray()
  IV.extend(iv2.to_bytes(4, 'little'))
  IV.extend(iv1.to_bytes(4, 'little'))
  ddata = Salsa20_xor(dat, bytes(IV), KEY[0:32])
  #check magic number
  magic = int.from_bytes(ddata[0:4], byteorder='little')
  if magic != 0x47375330:
    return bytearray(b'')
  return ddata

def send_hb(s):
  #send HB
  send_data = 'A'
  s.sendto(send_data.encode('utf-8'), (ip, SendPort))
  print('send heartbeat')

class LapCounter:
    def __init__(self):
        self.lap = -1
        self.paused = -1
        self.tick = 0
        self.pstart_tick = 0
        self.lstart_tick = 0
        self.lstart_ms = 0
        self.paused_ticks = 0
        self.last_lap_ms = 0
        self.special_packet_time = 0
    def update(self,lap,paused,tick,last_lap_ms):
        if lap == 0: # we have not started a lap or have reset
            self.special_packet_time = 0
        if lap != self.lap: # we have entered a new lap
            if self.lap != 0:
                normal_laptime = self.lapticks()*1000.0/60.0
                self.special_packet_time += last_lap_ms - self.lapticks()*1000.0/60.0
            self.lstart_tick = self.tick
            self.paused_ticks = 0
        if paused != self.paused: # paused has changed
            if paused: # we have switched to paused
                self.pstart_tick = self.tick
            else: # we have switched to not paused
                self.paused_ticks += tick - self.pstart_tick
        self.paused = paused
        self.lap = lap
        self.tick = tick
        self.last_lap_ms = last_lap_ms
    def pausedticks(self):
        if not self.paused:
            return self.paused_ticks
        else:
            return self.paused_ticks + (self.tick - self.pstart_tick)
    def lapticks(self):
        if self.lap == 0:
            return 0
        else:
            return self.tick - self.lstart_tick - self.pausedticks()
    def laptime(self):
        laptime = (self.lapticks() * 1./60.) - (self.special_packet_time/1000.)
        return round(laptime,3)


send_hb(s)

print("Ctrl+C to exit the program")
pknt = 0
lapcounter = LapCounter()
while True:
  try:
    data, address = s.recvfrom(4096)
    pknt = pknt + 1
    print("received: %d bytes" % len(data))
    ddata = salsa20_dec(data)
    if len(ddata) > 0:
      tick = struct.unpack_from('i',ddata,0x70)
      current_lap,laps_remaining = struct.unpack_from('hh',ddata,0x74)
     
      best_lap_ms,last_lap_ms = struct.unpack_from('ii',ddata,0x78)
     
      rpm_min,rpm_max,v_max,flags = struct.unpack_from('hhhh',ddata,0x88)
      paused = flags&2 # second bit in flags is paused

      lapcounter.update(current_lap,paused,tick[0],last_lap_ms)
      print ("lapcounter.laptime:",lapcounter.laptime())
     
    if pknt > 900:
      send_hb(s)
      pknt = 0
  except Exception as e:
    print(e)
    send_hb(s)
    pknt = 0
    pass
 
Last edited:
Ok, so I decided to move on from trying to get approximate lap times from the packets and just assume that the data is at least consistent inside the packet data, so I decided to knock up a nice Dash dashboard to analyse the data. I'm not good at styling so ignore that for now, but the data is at least usable.
  • Laps can be selected via dropdown or boxed on the lap time chart.
  • hovering over the speed graph will highlight the point on the lap chart where the hover is.
  • You can box or lasso parts of the lap map zoom in and focus on that area.
  • Files can just be dropped in to a folder to be loaded.

View attachment 1181492
This look great! Where to get this one?
 
So first off, the assumption that the packets are measured every 1/60 seconds is correct for almost all packets, but not for one very special packet -- the packet you will get that has a new lap number in it.
I KNEW IT. I should have guessed this from the fact that I could observe that the start of each new lap was ALWAYS on the start/finish line exactly, which made no sense from the perspective that EVERY packet was logged at equal intervals, and the distances made sense so the time should have. An accumulating delta for each lap was the only thing I didn't think of. I was playing with lap packet offsets and all sorts of nonsense, but as of now I can hopefully put this last one to bed, which then means...

This look great! Where to get this one?
I can add this, tidy up the code and then I'll put it on GitHub. Note as this is a Dash app, it will require Python and a bunch of libraries installed to get working. I'll see if there's an easy way (py2exe?) to make an executable out of it, but it will be large.
 
Last edited:
One snag. This code works well for when lap 1 starts at the start/finish line. If you do, for example online dailies, or FIA races with rolling starts then cars at the rear, when the start counts down to 0 has the lap 1 timer start on lap 0 which throws off the calculation because lap 1 will not have a lap time of 0 at the start of the lap, but some arbitrary time, t that needs adding on to the lap time. I am trying to see if there are ways of identifying the first packet in lap 0 where the player takes control, and thus the clock starts.

1659967749756.png


You can see lap 1 has a 4.7s difference for Brands Hatch which nearly matches the replay:
1659968284348.png
 
More interesting nonsense between live and replay...

That's quite a discrepancy in speed.

1660072589905.png


kph/self is myself recording a live 2-lap race. kph/other is me doing the replay of said race. Both the live and replay were the same length packet wise so I compared data.
 
Hi guys, thinking about a wind simulator. Whats the best way to connect rpm/speed to Fan rpm? Seems simhub has no action in GT7 direction.
check out this post:

They have created a proxy between GT7 and SimRacingStudio, it might get you going with Wind simulation.
 
More interesting nonsense between live and replay...

That's quite a discrepancy in speed.

<snip>

kph/self is myself recording a live 2-lap race. kph/other is me doing the replay of said race. Both the live and replay were the same length packet wise so I compared data.
That's quite a discrepancy indeed... Makes you wonder how feasible it is to use on replays. I assume that the live telemetry surely must be the "holy grail" so to speak, with the most accurate data. One would think they may be doing some kind of data culling and/or compression for the replay though, so you might lose some accuracy (sort of like artifacts in JPEG compression) – BUT, as you say, that's quite a noticeable difference, so... Weird.

How does lap times compare from live versus replay? I notice rpm and such also differs, so one wonders what values remain the same from live to replay.

Edit: Curious, if you overlay graphs of the speeds over time, do they line up linearly?
 
Last edited:
That's quite a discrepancy indeed... Makes you wonder how feasible it is to use on replays. I assume that the live telemetry surely must be the "holy grail" so to speak, with the most accurate data. One would think they may be doing some kind of data culling and/or compression for the replay though, so you might lose some accuracy (sort of like artifacts in JPEG compression) – BUT, as you say, that's quite a noticeable difference, so... Weird.

How does lap times compare from live versus replay? I notice rpm and such also differs, so one wonders what values remain the same from live to replay.

Edit: Curious, if you overlay graphs of the speeds over time, do they line up linearly?
Yeah, with all the hassle I was having with getting proper lap times and stuff, I kind of went down the route of "Is the replay just approximating values to make it look correct?"

I ran it through my graphs (ignore that it says lap 1 and lap 2, those are just labels I had to uniquely identify the data). That speed discrepancy definitely shows up though:
1660127244885.png


I decided to look at the data before that point:

1660127386158.png


It's pretty much identical, but after that weird differential, it starts to drift... You can definitely see it on the throttle chart in the first pic.

1660127590247.png


Both data sources for this single lap are the same length:
1660127642230.png


So yeah.
 
Last edited:
Hello !

I thought I had made some progress , but looks like I'm in a dead-end now. I focus on motion rig with roll/pitch/yaw/heave/sway/surge like @ashupp and used code from @Bornhall and @gt7coder for the packet structure, and of course based on @Nenkai work. I generated CSV from the decoded packet and tried to make some graphs to understand and figure values I needed. But I'm lost now.
What puzzles me is that for exemple I see positive and negative values for all velocity axes whereas I have always moved forward so I expected at least one of the three values to be always positive.
I was also unable to recreate the track aspect as some of you do, by plotting X,Y on a graph. This makes me think I have an issue with my code.... but values seem to move nicely without jumps.
Do you guys have the same behavior with the raw data ? Any idea of what I have missed ?

Packet format I used is this one, and seems accurate as values are moving smoothly withtou errors.
class GTDataPacket: def __init__(self, data): ## Format string that allows unpack to process the data bytestream: gt_format = '<ifffffffffffffffccccfffffffffffihhiiihhhhhhBBBcffffffffffffffffffffffffffffffffffffi' (self.magic, #int32 self.position_x, #single self.position_y, #single self.position_z, #single self.velocity_x, #single self.velocity_y, #single self.velocity_z, #single self.rotation_x, #single self.rotation_y, #single self.rotation_z, #single self.northorientation, #single self.angularvelocity_x, #single self.angularvelocity_y, #single self.angularvelocity_z, #single self.body_height, #single self.rpm, #single self.iv1, #char self.iv2, #char self.iv3, #char self.iv4, #char self.fuel_level, #single self.fuel_capacity, #single self.speed, #single self.boost, #single self.oil_pressure_bar, #single self.water_temperature, #single self.oil_temperature, #single self.tire_temp_FL, #single self.tire_temp_FR, #single self.tire_temp_RL, #single self.tire_temp_RR, #single self.pkt_id, #int32 self.current_lap, #int16 self.total_laps, #int16 self.best_lap_time, #int32 self.last_lap_time, #int32 self.day_progression_ms, #int32 self.pre_race_start_position, #int16 self.pre_race_num_cars, #int16 self.min_alert_rpm, #int16 self.max_alert_rpm, #int16 self.calculated_max_speed, #int16 self.flags, #int16 self.suggestedgear_gear, #byte self.throttle, #byte self.brake, #byte self.padding_byte1, #byte self.road_plane_x, #single self.road_plane_y, #single self.road_plane_z, #single self.road_plane_dist, #single self.tire_rps_FL, #single self.tire_rps_FR, #single self.tire_rps_RL, #single self.tire_rps_RR, #single self.tire_radius_FL, #single self.tire_radius_FR, #single self.tire_radius_RL, #single self.tire_radius_RR, #single self.susp_height_FL, #single self.susp_height_FR, #single self.susp_height_RL, #single self.susp_height_RR, #single self.unknown_single1, #byte self.unknown_single2, #byte self.unknown_single3, #byte self.unknown_single4, #byte self.unknown_single5, #byte self.unknown_single6, #byte self.unknown_single7, #byte self.unknown_single8, #byte self.clutch_pedal, #single self.clutch_engagement, #single self.rpm_clutch_gearbox, #single self.transmission_top_speed, #single self.gear_ratio1, #single self.gear_ratio2, #single self.gear_ratio3, #single self.gear_ratio4, #single self.gear_ratio5, #single self.gear_ratio6, #single self.gear_ratio7, #single self.gear_ratio8, #single self.car_code, #int32 ) = unpack(gt_format, data)

The full code is here just in case: https://github.com/vthinsel/GT7Proxy



2022-08-10 15_10_39-GT7data.csv - Excel.png

EDIT: I think I found the issue for the map: the Z axis is not what I used to play with other games such as PCars, but once axis are swapped, the map gets displayed fine. But I'm still puzzled about velocity axes behavior. Orientation looks almost fine (Y axis being used for yaw)
 

Attachments

  • 2022-08-10 17_58_37-GT7data.csv - Excel.png
    2022-08-10 17_58_37-GT7data.csv - Excel.png
    132 KB · Views: 43
Last edited:
Saw some funny stuff near the end of the lap...
1660138234626.png

1660138633993.png

That red line (replay) definitely doesn't look to be err... On the money. I would hazard a guess the replay file has either a lower resolution or the replay has some other kind of averaging going on where it doesn't care what data is being output as long as it's approximate over the course of a lap and plays to the screen how it should.

It explains why I didn't think about it before. Earlier replays I saw the max throttle bouncing between 254 and 255 and just dismissed it as I had to clean the throttle pedal on my CSL Elite due to the potentiomenter being a bit bouncy at low values so just assumed this was the beginning of it.

I have also thought that could this be some weird artifact where the live data is actually being smoothed, and the replay has raw data and this sawtooth effect is the vibration from the trigger controls, but I don't see under braking and I don't see it on all corners, so I dunno.

I think for purposes going forward I am just going to ignore replay files when it comes to any kind of analysis or development because it's just... weird.
 
Last edited:
Saw some funny stuff near the end of the lap...
View attachment 1182375
View attachment 1182376
That red line (replay) definitely doesn't look to be err... On the money. I would hazard a guess the replay file has either a lower resolution or the replay has some other kind of averaging going on where it doesn't care what data is being output as long as it's approximate over the course of a lap and plays to the screen how it should.

It explains why I didn't think about it before. Earlier replays I saw the max throttle bouncing between 254 and 255 and just dismissed it as I had to clean the throttle pedal on my CSL Elite due to the potentiomenter being a bit bouncy at low values so just assumed this was the beginning of it.

I have also thought that could this be some weird artifact where the live data is actually being smoothed, and the replay has raw files and this sawtooth effect is the vibration from the trigger controls, but I don't see under braking and I don't see it on all corners, so I dunno.

I think for purposes going forward I am just going to ignore replay files when it comes to any kind of analysis or development because it's just... weird.
Maybe it's because of some frame fluctuations.

I've seen some time glitches in replays from lobby races that some time the timing just jumps some milliseconds to even full seconds because of lag or FPS drops.

Maybe that's the cause, maybe not.
 
Maybe it's because of some frame fluctuations.

I've seen some time glitches in replays from lobby races that some time the timing just jumps some milliseconds to even full seconds because of lag or FPS drops.

Maybe that's the cause, maybe not.
There is a field in the data affectionately known as "tick" which increments with each packet. Usually these are stamps that equate to things like "number of frames rendered" or "amount of seconds past since the PS was last rebooted" or something along those lines.

I checked the data and there are no missing numbers in the ticks, meaning that all the data that was sent, I have, so in this case it's probably not FPS drops, and it's not lag because it's being sent from my PS to my PC which is on the same switch, and I am measuring packet times.
 
I have also thought that could this be some weird artifact where the live data is actually being smoothed, and the replay has raw data and this sawtooth effect is the vibration from the trigger controls, but I don't see under braking and I don't see it on all corners, so I dunno.
Another thing though, is the data points always the same (error-wise) if you run the same replay twice (or more)?

I'm thinking if there is some kind of read buffering that for some reason lowers the priority of the thread that spurts out the telemetry, and it somehow knows to "catch up" to itself... Could possibly be while the replay is stored as well, and if so, the values from the replay should be reproducible every time.

I've also been pondering if it would be a good idea to average out like the last 10 ticks of data for some values like speed, rpm and such. Or maybe even weighting "old" values lower than the latest tick values, giving maybe a more up to date current value. Reason for me thinking about this is because I'm not sure it's really necessary to (post-race) evaluate telemetry in such high resolution as 1/60th. Mostly this is why I haven't implemented any kind of logging myself.
 
Another thing though, is the data points always the same (error-wise) if you run the same replay twice (or more)?

I'm thinking if there is some kind of read buffering that for some reason lowers the priority of the thread that spurts out the telemetry, and it somehow knows to "catch up" to itself... Could possibly be while the replay is stored as well, and if so, the values from the replay should be reproducible every time.

I've also been pondering if it would be a good idea to average out like the last 10 ticks of data for some values like speed, rpm and such. Or maybe even weighting "old" values lower than the latest tick values, giving maybe a more up to date current value. Reason for me thinking about this is because I'm not sure it's really necessary to (post-race) evaluate telemetry in such high resolution as 1/60th. Mostly this is why I haven't implemented any kind of logging myself.
Good question. I shall do some experimentation tomorrow.
 
Good question. I shall do some experimentation tomorrow.
Is it the same for the demonstration laps on circuit masteries? I found them to be precise and worked on my lap times with the data. But given their nature we cannot compare them to other instances of the exact same lap.
 
Ok, so after some experimentation, this is what I have found:

i did a quick 5 lap Sunday Cup race around Northern Isle Speedway and recorded 5 sets of data:
  1. Data being recorded live as I was driving
  2. Data being recorded from the replay that is shown after the race and credits, but before you go back to the screen to save the replay.
  3. A replay ran from the main post-race screen where you can save the replay, or exit, or race again.
  4. A replay of the race loaded from "Showcase" after saving the replay.
  5. Another run of the same replay after exiting and reloading.
This is what I found.

  • The live data doesn't match ANY of the replays, it is different in the few instances I showed earlier in that the speeds are off by a few kph, so the rest of the data is. Ironically enough, tick 0 on a lap is identical, it just drifts from there.
  • Replays in points 2-5 are all identical data.

I had to do a lot of double-checking as the data in replay 2 didn't match replay 3 for some reason as it was off-by-one packet.
 
Ok, so after some experimentation, this is what I have found:

i did a quick 5 lap Sunday Cup race around Northern Isle Speedway and recorded 5 sets of data:
  1. Data being recorded live as I was driving
  2. Data being recorded from the replay that is shown after the race and credits, but before you go back to the screen to save the replay.
  3. A replay ran from the main post-race screen where you can save the replay, or exit, or race again.
  4. A replay of the race loaded from "Showcase" after saving the replay.
  5. Another run of the same replay after exiting and reloading.
This is what I found.

  • The live data doesn't match ANY of the replays, it is different in the few instances I showed earlier in that the speeds are off by a few kph, so the rest of the data is. Ironically enough, tick 0 on a lap is identical, it just drifts from there.
  • Replays in points 2-5 are all identical data.

I had to do a lot of double-checking as the data in replay 2 didn't match replay 3 for some reason as it was off-by-one packet.
I absolutely love following this thread! Is this being discussed more frequently somewhere? It seems to have slowed down from some of the early posters
 
Back