F1 2021 UDP Specification

[DaveyGravy]

17 minutes ago, Hoo said:

Hi @Lopensky - we already proposed this solution but it was rejected as the algorithm could be simple to reverse-engineer against known gamertags. 😞 

Just a thought… but now Codemasters own SMS, and the PCARS games send gamer tags in the telemetry, can your legal eagles not talk to their legal eagles and see what they did/why it was OK for them? 

It’s just a crying shame and a glaring omission - I hear from so many racers, especially league drivers about the lack of names, and all I can do is shrug and blame the game. 🤷‍♂️

[Hamdor]

The table in chapter "Packet Types" in incomplete in the current version of the docx. The double type is missing which is used in "FinalClassificationData" now.

[cjorgens79]

8 hours ago, Hoo said:

Hi @Lopensky - we already proposed this solution but it was rejected as the algorithm could be simple to reverse-engineer against known gamertags. 😞 

Using a salted hash as is standard for secure storage of passwords is not reversible, then b64 or hex it so its displayable. There would need to be considerations though as to the length of the resulting hash string to ensure it fits in the allocated space for driver names. 

[AndyHamp]

17 hours ago, Hamdor said:

The table in chapter "Packet Types" in incomplete in the current version of the docx. The double type is missing which is used in "FinalClassificationData" now.

What did I miss ? Was there a change to the data format ?

This is why i wanted the spec here in plain text in the post, so we can easily see what's changed by looking at the edit dates rather than having to search through a proprietary format file 😡

[LonelyRacer]

12 minutes ago, AndyHamp said:

What did I miss ? Was there a change to the data format ?

This is why i wanted the spec here in plain text in the post, so we can easily see what's changed by looking at the edit dates rather than having to search through a proprietary format file 😡

There is no change. The m_totalRaceTime was double in F1 2020's PacketFinalClassificationData packets, as it is now and both packets have same size in F1 2020 and F1 2021.

So if your code around that packet worked last year, it will work this year.

If you are new developer and don't know how many bytes is a double, you might want to do some studying/research. For the Integers the size + unsigned/signed is critical, for double there is only one size, but if you do the conversion by hand, you must take into account endianness.

@HooMaybe you need to add the double's size info to the docs too. ;-).

Cheers.

[AndyHamp]

In the 2019 game the SEND event was always the last data packet from a session.

In 2021 (Don't know about 2020, maybe it was the same there) we now see Session History and Final Classification messages AFTER the SEND event

How are people determining when there's no more data to be received ? In my existing code i use the STRT and SEND as the delimiters for the data i'm saving for analysis etc and for determining when i can clean up internal state. But if i use SEND i might be missing useful data that can come many seconds after the SEND

Is the SEND not being the last packet sent a bug @Hoo ?

 

[AndyHamp]

15 minutes ago, LonelyRacer said:

There is no change. The m_totalRaceTime was double in F1 2020's PacketFinalClassificationData packets, as it is now and both packets have same size in F1 2020 and F1 2021.

So if your code around that packet worked last year, it will work this year.

If you are new developer and don't know how many bytes is a double, you might want to do some studying/research. For the Integers the size + unsigned/signed is critical, for double there is only one size, but if you do the conversion by hand, you must take into account endianness.

@HooMaybe you need to add the double's size info to the docs too. ;-).

Cheers.

I was confused by @Hamdor's post... I couldn't see any changes from the doc i originally downloaded or in the data so wonder what he was posing about. If it was a difference to the 2020 format then i'd not have seen it as i never added 2020 support in my code

[XanderSJX]

1 hour ago, AndyHamp said:

In the 2019 game the SEND event was always the last data packet from a session.

In 2021 (Don't know about 2020, maybe it was the same there) we now see Session History and Final Classification messages AFTER the SEND event

How are people determining when there's no more data to be received ? In my existing code i use the STRT and SEND as the delimiters for the data i'm saving for analysis etc and for determining when i can clean up internal state. But if i use SEND i might be missing useful data that can come many seconds after the SEND

Is the SEND not being the last packet sent a bug @Hoo ?

 

Already in 2020 there is that behaviour, I think that is expected. So SEND marks that "racing" time of session is done and then when results screen comes on we get Final Classification packet. Best way to use that packet as delimiter.

[mfivnismo]

How do I run multiple udp ports as I have a motion rig running Sim Racing Studio and a Grid Engineering Display running simhub?

[cgfdoo]

2 minutes ago, mfivnismo said:

How do I run multiple udp ports as I have a motion rig running Sim Racing Studio and a Grid Engineering Display running simhub?

You either enable the UDP Broadcast option in the game or your app needs to act as a proxy and forward the UDP packets to your other device(s)

[DaveyGravy]

Looks like there might be a bug regarding broadcast mode not working correctly. I’ve had several reports of broadcast mode not actually broadcasting, and instead doing a standard unicast to the previously entered IP address, even though that field is disabled when broadcast mode is on. I’ve tested this on PS5 and I don’t get the issue, everything works as expected. All of the users that reported the bug so far have been on Xbox Series X which may or may not be relevant. Anyone else seen this issue, on any platform?

[EnsiFerrum]

On 7/16/2021 at 8:12 PM, SimRacingStudio said:

One of our customers found a very annoying bug, that we will need your help to be addressed with the EA/codemasters developers.

 

Check out this video, left side is the SRS showing the telemetry that is receiving from F12021 and right side is the F12021 in the menu:

https://photos.google.com/share/AF1QipMGg-fnEguBQEtcYFFFMoTqAaF1nUJcPHSm58yq0X7vQdb7IZv6h8vp5CgMGa2dHA?key=VXl0S05YNFFvUDBLZ2Y2WVhpTHp5ak8zaVJfcExR

 

Every time I change the menu, the F12021 is sending the telemetry for about 1 second.

This did not happen in any previous version of F1 games, all the way up to F12011.

 

It's major issue for Motion platform users, every time it switches the menu, it goes from the 0 position, all the way to where the car was when you pressed pause, it sends you to the roof literally.

 

 

On 7/16/2021 at 10:17 PM, EnsiFerrum said:

Can confirm, have the same problem.

@Hoo
Any news on this bug?
I disabled the the Events (I do not need them to show some telemetry data and let the leds light up) and still get telemetry send to the hardware every time I press a button on the steering wheel.
I think CM simple forgot to set a flag to disable this piece of telemetry to be sent through any kind of SDK. 

[Hoo]

49 minutes ago, EnsiFerrum said:

 

@Hoo
Any news on this bug?
I disabled the the Events (I do not need them to show some telemetry data and let the leds light up) and still get telemetry send to the hardware every time I press a button on the steering wheel.
I think CM simple forgot to set a flag to disable this piece of telemetry to be sent through any kind of SDK. 

We can't see the issue here. It looks like the telemetry data needs filtering out based on the button events.

[LonelyRacer]

2 hours ago, Hoo said:

We can't see the issue here. It looks like the telemetry data needs filtering out based on the button events.

@Hoo @EnsiFerrum

I tested this and it works as expected.

In driving, the game sends out all packages as expected.

If you pause the game, only the PacketEventData packets are sent, so no Telemetry/Lapdata etc is sent when the game enters the pause. If you move around the menus or press controller buttons, this triggers the PacketEventData BUTN, again as expected.

So @EnsiFerrum you need to a) filter out the PacketEventData BUTN packets from the feed on the receiving end or b) if you do some motion platform, only trigger "stuff"/movement, when there is new PacketMotionData packet (with new FrameId) from the game. If you always trigger stuff when any packet comes out from the game, you will get many triggers per frame, which most likely is not what you want to do anyway.

Cheers.

[LonelyRacer]

On 7/23/2021 at 12:16 AM, DaveyGravy said:

Looks like there might be a bug regarding broadcast mode not working correctly. I’ve had several reports of broadcast mode not actually broadcasting, and instead doing a standard unicast to the previously entered IP address, even though that field is disabled when broadcast mode is on. I’ve tested this on PS5 and I don’t get the issue, everything works as expected. All of the users that reported the bug so far have been on Xbox Series X which may or may not be relevant. Anyone else seen this issue, on any platform?

I have seen some of my users having issue also relating to the broadcast mode. In consoles, if they turn on the broadcast mode, the game doesn't send motion packets. I haven't been able to test this, as I don't have console. But after they turned off the broadcast mode in the game, the motion packets and other packets started arriving correctly. Could be related.

Cheers

Edited July 24, 2021 by LonelyRacer
Small typo fixes/wording changes

[CanTQuiT]

LapHistoryData data package:

Isn't uint16 a little bit too small for m_sector(X)TimeInMS data for slow drivers, when they need more than 65,535 seconds per sector?

We have then an overflow value problem.

 

Edited July 25, 2021 by CanTQuiT

[LeSansTalents]

Hello 👋🏻 

I play on PS4 with RS Dash for the telemetry.

Why can I see in multiplayer mode „player255“ only on my timelist?

in F1 2020 was this Player100 till Player120 , so I can nearly see which player is it. But when all players have the same name, it’s little bit ...

Can you insert Telemetrie Names inGame? Like MSC or other individual shortcuts, which the players can use?

My option for public Telemetry is on, but my body see only player255, too.

Shown the PSN ID or InGameName where the best option, when the Telemetry is open for public.

thanks

[cjorgens79]

5 minutes ago, LeSansTalents said:

Hello 👋🏻 

I play on PS4 with RS Dash for the telemetry.

Why can I see in multiplayer mode „player255“ only on my timelist?

in F1 2020 was this Player100 till Player120 , so I can nearly see which player is it. But when all players have the same name, it’s little bit ...

Can you insert Telemetrie Names inGame? Like MSC or other individual shortcuts, which the players can use?

My option for public Telemetry is on, but my body see only player255, too.

Shown the PSN ID or InGameName where the best option, when the Telemetry is open for public.

thanks

Hi,

Thanks for letting me know, I will check it out and get it sorted. For RS Dash specific support questions, you are best emailing support@pocketplayground.net directly.

With regards to having actual player names (or PSN ID, etc) , this is a limitation of the game itself. Codemasters legal department does not currently allow personal account identifiers to be transmitted over the telemetry feed. If you check page 2 of this forum topic there is discussion about this topic (sending gamer tags) with Codemasters staff.

Cheers

[AndyHamp]

Has anyone else ween any issues with Type3 Event messages in Time Trial ?

At the end of a TT session i see a SEND and then an unexpected SSTA

2021-07-26 12:13:09.626+3,3293516312674155847,192.168.1.10,219.97751,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:13:09.733+3,3293516312674155847,192.168.1.10,219.97751,0,2021.1.4|BUTN,00000000,0
2021-07-26 12:13:10.439+3,3293516312674155847,192.168.1.10,0,0,2021.1.4|SEND
2021-07-26 12:13:10.440+3,14788111507831082358,192.168.1.10,0,0,2021.1.4|SSTA
2021-07-26 12:14:17.907+3,0,192.168.1.10,0,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:14:17.939+3,0,192.168.1.10,0,0,2021.1.4|BUTN,00000000,0

Then going back in to do a new TT, the data just starts ... BUT the UUID has changed

2021-07-26 12:40:14.233+3,9122755524027100801,192.168.1.10,0,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:40:14.376+3,9122755524027100801,192.168.1.10,0,0,2021.1.4|BUTN,00000000,0
2021-07-26 12:40:14.455+1,9122755524027100801,192.168.1.10,0.012398557,0,2021.1.4|0,31,2

Then at the end i get another SEND and SSTA

2021-07-26 12:42:21.456+3,9122755524027100801,192.168.1.10,113.699394,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:42:21.581+3,9122755524027100801,192.168.1.10,113.699394,0,2021.1.4|BUTN,00000000,0
2021-07-26 12:42:22.242+3,9122755524027100801,192.168.1.10,0,0,2021.1.4|SEND
2021-07-26 12:42:22.244+3,8475959009886494307,192.168.1.10,0,0,2021.1.4|SSTA
2021-07-26 12:42:25.610+3,0,192.168.1.10,0,0,2021.1.4|BUTN,00000001,1

 

Format of the log is:
Date/Time+ MsgType, UID, SourceIP, SessionTime, PlayIndex, Version| DataBeingLogged

Outside TT it seems correct so far....

[AndyHamp]

21 hours ago, AndyHamp said:

Has anyone else ween any issues with Type3 Event messages in Time Trial ?

At the end of a TT session i see a SEND and then an unexpected SSTA

2021-07-26 12:13:09.626+3,3293516312674155847,192.168.1.10,219.97751,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:13:09.733+3,3293516312674155847,192.168.1.10,219.97751,0,2021.1.4|BUTN,00000000,0
2021-07-26 12:13:10.439+3,3293516312674155847,192.168.1.10,0,0,2021.1.4|SEND
2021-07-26 12:13:10.440+3,14788111507831082358,192.168.1.10,0,0,2021.1.4|SSTA
2021-07-26 12:14:17.907+3,0,192.168.1.10,0,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:14:17.939+3,0,192.168.1.10,0,0,2021.1.4|BUTN,00000000,0

Then going back in to do a new TT, the data just starts ... BUT the UUID has changed

2021-07-26 12:40:14.233+3,9122755524027100801,192.168.1.10,0,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:40:14.376+3,9122755524027100801,192.168.1.10,0,0,2021.1.4|BUTN,00000000,0
2021-07-26 12:40:14.455+1,9122755524027100801,192.168.1.10,0.012398557,0,2021.1.4|0,31,2

Then at the end i get another SEND and SSTA

2021-07-26 12:42:21.456+3,9122755524027100801,192.168.1.10,113.699394,0,2021.1.4|BUTN,00000001,1
2021-07-26 12:42:21.581+3,9122755524027100801,192.168.1.10,113.699394,0,2021.1.4|BUTN,00000000,0
2021-07-26 12:42:22.242+3,9122755524027100801,192.168.1.10,0,0,2021.1.4|SEND
2021-07-26 12:42:22.244+3,8475959009886494307,192.168.1.10,0,0,2021.1.4|SSTA
2021-07-26 12:42:25.610+3,0,192.168.1.10,0,0,2021.1.4|BUTN,00000001,1

 

Format of the log is:
Date/Time+ MsgType, UID, SourceIP, SessionTime, PlayIndex, Version| DataBeingLogged

Outside TT it seems correct so far....

@Hoo  I have opened a support report for this bug 

 

[Cheelax]

Hello guys, I am trying to find the "equal performance" informations in the messages but can't find it. Is the information sent somehow?

Thank you!

[Poulpix]

Hi everyone,

Has anybody ever found a value of "12" for a "surface type" on which wheels are running, and knows what it means?

The CM documentation states that surface types go from 0 (tarmac) to 11 (ridged), so that's 12 different values, but in Suzuka I managed to get a "12" value and thus my app crashed, because it was missing this enum case...

Documentation seems to be lacking at least one value, meanwhile I've tagged it as "yet to be defined"...

Thanks!

[LonelyRacer]

2 hours ago, Poulpix said:

Hi everyone,

Has anybody ever found a value of "12" for a "surface type" on which wheels are running, and knows what it means?

The CM documentation states that surface types go from 0 (tarmac) to 11 (ridged), so that's 12 different values, but in Suzuka I managed to get a "12" value and thus my app crashed, because it was missing this enum case...

Documentation seems to be lacking at least one value, meanwhile I've tagged it as "yet to be defined"...

Thanks!

Last year it was "Generic Surface", which you were not supposed to find anywhere. In F1 2020 I found one location, when I by accident drove super hard out from the track into the barriers on Sochi T6.

In my tool I have for all Enums a catcher for unknown Ids, which the tool then writes into a file, where I can check, if there are some odd Ids reported by the game.

Cheers

Edited July 30, 2021 by LonelyRacer
Just wrote about the Enum Unknown Id catcher.

[codylane482]

On 7/22/2021 at 4:16 PM, DaveyGravy said:

Looks like there might be a bug regarding broadcast mode not working correctly. I’ve had several reports of broadcast mode not actually broadcasting, and instead doing a standard unicast to the previously entered IP address, even though that field is disabled when broadcast mode is on. I’ve tested this on PS5 and I don’t get the issue, everything works as expected. All of the users that reported the bug so far have been on Xbox Series X which may or may not be relevant. Anyone else seen this issue, on any platform?

I am by no way an expert when it comes to networking.

 

I also originally thought the UDP broadcast mode on my XboxOne X didn't work but then I realized it was actually because my UDP client needed to support multicast which is a different socket setup than just a regular UDP socket.  Here's the article I used to create a feature toggle in my app so that I could use a IP bound UDP socket or a multicast socket. https://stackoverflow.com/questions/603852/how-do-you-udp-multicast-in-python

 

But then it again it's not always so straight forward to diagnose this type of issue. It could also be a network device(s) that don't fully support multicast as most non-enterprise or non-managed devices can have spotty support for multicast and or mutlicast forwarding. Generally if you are on the same subnet as your console then most network devices should support multicast. 

 

Another thing to possibly consider is wired network vs wireless network. I've only every used a wired network connection for my console.

 

For what it's worth I use Ubiquiti UAP-ACLR access points for my home network.  In order to use multicast with wireless devices on the same subnet I had to enable "Permit Multicast" on each ESSID on my network.

[DaveyGravy]

On 8/5/2021 at 3:07 AM, codylane482 said:

I am by no way an expert when it comes to networking.

 

I also originally thought the UDP broadcast mode on my XboxOne X didn't work but then I realized it was actually because my UDP client needed to support multicast which is a different socket setup than just a regular UDP socket.  Here's the article I used to create a feature toggle in my app so that I could use a IP bound UDP socket or a multicast socket. https://stackoverflow.com/questions/603852/how-do-you-udp-multicast-in-python

 

But then it again it's not always so straight forward to diagnose this type of issue. It could also be a network device(s) that don't fully support multicast as most non-enterprise or non-managed devices can have spotty support for multicast and or mutlicast forwarding. Generally if you are on the same subnet as your console then most network devices should support multicast. 

 

Another thing to possibly consider is wired network vs wireless network. I've only every used a wired network connection for my console.

 

For what it's worth I use Ubiquiti UAP-ACLR access points for my home network.  In order to use multicast with wireless devices on the same subnet I had to enable "Permit Multicast" on each ESSID on my network.

UDP broadcast is working in my client from Playstation so I'm fairly confident it's not my app, as a broadcast packet should be a broadcast packet, regardless of what platform sent it. 

I don't have access to an Xbox myself so can only go on what the increasing number of reports of it not working say, but they're all pretty consistent. If you enable broadcast mode on Xbox, it ignores the setting, and continues to send data out to the last previously entered IP address. Any thoughts @Hoo?

Multicast is a very different beast to broadcast, so I'd be surprised if you're able to collect the data that way. Unless this is what is different in the Xbox version?

Thanks