Let's talk about broadcasting (programmer's thread)

@Brado23 so I assume you are using the c# sdk. I am interfacing directly with the broadcasting UDP interface (using go) and I see the sessiontime increasing from the moment the green flag is waved.

 

I'm having trouble calculating the gap. As it turns out the events from ACC are not synchronized so I cannot implement my algorithm without getting errors every now and then.

What I do now:

• Sort cars by Position
• If session type is Q/FP:
  • Simply take take difference between best lap of car ahead and current car
• If session type is Race:
  • Check Lap difference of car in front and current car
    • If difference == 1 : Check whether the spline distance is more or less than 1.0 to avoid 'false' +1L (like ACC shows when first car crosses finish line)
    • Then calculate gap based on spline, track length and speed (not sure this is true gap though) like the SDK example.
    • HOWEVER: every so often the spline position of the car in front is LOWER than the current car. I did a lot of logging and the messages are not synchronized, irrespective of 100, 250 or 2000ms interval this occurs frequently.

Any suggestions on a better aproach to calculate 'live' gap? First I thought I updated the gap before I received all data, but even when I only update on RealtimeUpdate (so not on the RealtimeCarUpdate) and use the data that I received before this update, the gap breaks due to wrong data order from ACC.

Also @Toon Knapen if you don't mind me asking; do you store all info in a DB for the pitwall app? I see some nice features (split/pit tracking) .

I created a VueJS app that relies on a backend that communicates with ACC via a client. It is set up such that for example the whole team (let's say 3 drivers) can start the client but only one will be streaming. If one closes the connection the backend switches to the next client. The final goal here is to switch to a client that is not driving to reduce load (based on shared memory data as well). This way the team can remotely look at the session (similar to your app). It is also intended to extend this with telemtry like brake/throttle/tire press/fuel cons. etc from shared memory.

PS. Did anyone else notice the 'Delta' from ACC is completely messed up sometimes? It randomly starts showing values way above 1 or 2 minutes, and suddenly changes back to seconds.

 

Interesting that 54 is unused - wonder if that is a placeholder for the "other" BMW in the future

Superb - that's exactly what I need
Thanks

 

Hello @expor I don't mind you asking at all, if we can help each other that would be better for the whole acc community.

For a race, I try to determine an absolute timestamp for every time the car crosses the S/F or drive's into the pit or out of the pit. Especially to provide a stint-overview (when the car pitted, how long he pitted) this absolute timestamp is necessary. And the drawback of the broadcasting interface is that this absolute timestamp is not available (while every real-live track timing system does).

The way I determined this was to watch out for the first lap being done (watching RealTimeCarUpdate.Laps) and once this is done I determine the lap-time of that first lap as 'RealTimeUpdate.SessionTime - RealTimeCarUpdate.CurrentLap.LapTime`. However recently during a race the RealTimeCarUpdate.CurrentLap.LapTime was extremely big (and a completely impossible value) so I'm now looking into cleaning that data if I detect the values are impossible and not coherent with the ranking that is provided by ACC.

Once these absolute timestamps of all end-of-sectors are determined, I just need to calculate how long ago the leader passed the same end-of-sector as the car for which I want to calculate the diff. To calculate the diff based on the spline position, you also need a good speed-profile of the track. So if 2 cars are according to the spline close but there is a hairpin inbetween is completely different from the same distance on a straight.

Hope my explanation is a bit clear.

 

@Toon Knapen Thanks for your explanation!

For the pit / stint overview I was thinking something similar indeed. I'll have a go with it .

As for the gap calculations I'm still not sure. While I understand your method (it's more like an interval than actual live gap I'd say?), I'm running on a 1 to 2 second interval and using that method would only give me second-precision which is a bit too much. Also you mention end-of-sector but currently ACC only shows sector times as part of the 'last lap' and not for the current lap.

Maybe the reason for my received Delta is related to the strange laptimes you see, as the Delta values are also way out of limits. So far I'm mostly testing offline so maybe this is just an issue when having AI in the session (I hope).

 

@expor there are big differences testing in SP or MP. In the latter case lag will come into play and messes up stuff. So I would recommend to start testing online ASAP.

As for the gap calculation, if you don't take an accurate speed-profile of the track into account, you will get a lot of osscilations which will just be confusing. And indeed, with my method the gap is only updated once per lap in ACC (due to updates only received at the end of lap).

BTW what app exactly are you developing?

 

@Toon Knapen I've done some online testing as well. With one or two second interval there are no issues, other than the fact that car updates are not in order of spline position, causing gap calculation issues. I might go for intervals instead but it would mean a time error of up to one or two seconds. I'm aware that spline calculations vary (this also happens ingame as acc uses the same method it seems) based on speed but I think it's acceptable for a live timing app.

The app development started because I drive endurance races with friends. We want to see each others telemetry when we're not driving. The players who are not driving cannot see fuel left, fuel consumption, temperatures, tire pressures etc. on the HUD.

We also wanted live timing tables so we can be like a spotter for each other. So the first step is almost done as shown in my screenshot (have to add nr of pit still). Next step is to integrate live telemetry via ACC shared memory.

When integrated with shared memory the server backend will request broadcast data only from the person who is not actively driving (reduce load where possible), and request telemetry only from the one who is driving.

Already implemented is that the backend will request data from the next client when the active connection is closed. That way the whole team can have the app running but only one is actively streaming at a time. It also has a reconnect mechanism builtin when acc is restarted for example.

Either way I had a look at your pit wall app and it gave me some ideas to extend mine .

 

Anybody an idea of how to detect the lag in the updates received through the broadcasting interface of each car?

The only thing I can think of is to monitor if the current-laptime is going forward at the same pace as wallclock time but that only gives me an indication of the _variation_ of lag, not an absolute value.

 

Extend the realtimecarupdate with a timestamp field that is filled by the client before it's send to your backend? Or is that not what you mean. I guess you still rely on the backend time being in sync but maybe it helps in some way?

 

I am after the ping that is shown on screen above each car. Since it is visualised on screen my acc client has it. But is there a way to fetch it somewhere?

 

Ah I misunderstood, I don't think that's part of the API no :<.

 

@Minolin

Next time you are doing updates to the broadcast API, can we please have a ClassPosition variable added, similar to Position and CupPosition, so we can track positions of the different classes of car in the game now?

Thanks.

 

What is correct way to detect if a laptime is eligible (and thus valid) for the ranking during a quali?
I expected `realTimeCarUpdate.LastLap.IsValidForBest` but this seems sometimes off ?

 

That should be sufficient. What kind of issue you see with that? I take it that's for ranking some pre-qualification events? During a session it's already available as Position.

 

sometimes I see differences between the 'best' time in ACC and what I considered the best valid time.

I need to be able to determine which lap is valid as in pitwall we also allow to see the history of all laps (and download in excel for instance) and there we want to indicate which lap was valid and which was not.

And BTW, in a practice the criterium seems even different to me.

 

I see. I'm only looking at valid for best flag, but mainly simply report the best session lap.

I have noticed that the delta between a car and the best FP/Q time reported by ACC is often wrong. I initially thought it were my own times being wrong but some simple manual checks showed ACC itself is showing the wrong deltas.

 

Can anyone confirm if they are seeing what I am (I need to narrow down if it is my problem, or ACC's)?

Since the 23rd, I'm frequently seeing sector times not reporting (one or more are null within certain laps) on the broadcasting interface and I suspect I'm getting so many real time car updates (I'm missing some when I do my crossed line checks). The lap times are there, just one or two of the sectors missing.

I've been back through history, and previously, I'd seen that for sector 1 of the first lap (which I thought was just a bi-product of that funky huge first lap time) or for other outlaps. It only seems to be an issue on MP races. MP Practice/Quali are fine and all SP seems ok

 

I have noticed the deltas are wrong at times too

 

I had noticed some weird things happening at times but didn't take much notice. I'll pay more attention and let you know if I see anything.

 

FYI... I found the problem with TimeOfDayInfo. Values ARE coming through from the game which I didn't realize, but they are being sent in the wrong format. I got it to work with this workaround....

Code:

            SecsSinceMidnight = update.TimeOfDay.TotalMilliseconds;
            TimeSpan time = TimeSpan.FromSeconds(SecsSinceMidnight);
            TimeOfDayInfo = time.ToString(@"hh\:mm");

Previously the code was just this (which wasn't working)...

Code:

TimeOfDayInfo = update.TimeOfDay.ToString("hh\\:mm");