F1 2021 UDP Specification

[codylane482]

On 8/7/2021 at 12:38 AM, DaveyGravy said:

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

 

I could be wrong but I'm fairly certain that when the F1 game means "broadcast" they truly mean "mulitcast" because once I created a multicast listening socket I was able to receive all expected packets from my console on my home network to my app regardless of WIFI or wired connection. It's true I do experience some issues but I blame that on my network and my app. I could also blame Microsoft for not truly following normal RFC guidelines when it comes to networking. MS has had a tendency in the past to do their own things when it comes to networking not following the normal RFC protocols which can cause issues that are hard to troubleshoot and diagnose. Also, that said, each WIFI router can have it's own interpretation of what "broadcast" or "multicast" means which complicates the issue further.

 

If I could make one recommendation to sort this out then I would recommend providing some network packet captures using something like tcpdump or wireshark to capture packets on the local xbox network and upload those captures here. I am a linux/unix guy so I generally stick to the command line and use tcpdump to capture packets with a rule something like this and then use wireshark to analyze the packets.

sudo tcpdump -i eth0 -vv -s0 udp port 20777 -w debug.cap

 

I wonder if some of your clients could capture some packets for us so we could analyze them? Again, I hate to use the words "it works for me" but once I add the feature toggle to either accept multicast packets or regular targeted UDP packets my app started working like a charm for both cases on my xbox one x. I have no packet loss and it works flawlessly as long as I have my mulitcast settings configured properly on "ALL" of my network gear.

 

I will continue to investigate and report my findings as this is something I really want to help diagnose.

Edited August 8, 2021 by codylane482
clarification

[codylane482]

On 8/7/2021 at 12:38 AM, DaveyGravy said:

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

Another thought I had and I'm not sure if you are open to this idea or not but if you can grant/provide me a copy of race dash for f1 2021, I'd be happy to continue to troubleshoot this for you and see if I am able to diagnose the issue and or find a reproduce the errors that your clients are seeing? I've not used Race Dash before but I've heard great things about it.

 

FWIW, I am an open source developer and enjoy helping the community when I have spare time.

[DaveyGravy]

On 8/8/2021 at 7:18 AM, codylane482 said:

 

I could be wrong but I'm fairly certain that when the F1 game means "broadcast" they truly mean "mulitcast" because once I created a multicast listening socket I was able to receive all expected packets from my console on my home network to my app regardless of WIFI or wired connection. It's true I do experience some issues but I blame that on my network and my app. I could also blame Microsoft for not truly following normal RFC guidelines when it comes to networking. MS has had a tendency in the past to do their own things when it comes to networking not following the normal RFC protocols which can cause issues that are hard to troubleshoot and diagnose. Also, that said, each WIFI router can have it's own interpretation of what "broadcast" or "multicast" means which complicates the issue further.

Multicast is very specialist and uses a reserved IP range (224.x.x.x), so I'd be very surprised if this is what the game is using. All previous versions of the game used broadcast packets in broadcast mode as well. A couple of users say that the game still sends direct only to the previously entered IP, even when they've enabled broadcast mode so this part is definitely a bug at least (Xbox only). Quite why/how you're able to collect the broadcast data using multicast is a bit of a mystery to me but if it's working...

One user did use a different app as well and confirmed that one didn't work with broadcast mode from the Xbox either.

Feel free to try my app - it's a free download and there's a very basic dash that'll work out the box to test functionality.

Cheers

 

[ericgvmaia]

Hello!

How can I determine do % of ERS available?

The values sent by the game are not very clear...

What is the maximum capacity of the batteries?

Is ersStoreEnergy representing the current energy available?

 

Thanks!

[ThibaudPHP]

1 minute ago, ericgvmaia said:

Hello!

How can I determine do % of ERS available?

The values sent by the game are not very clear...

What is the maximum capacity of the batteries?

Is ersStoreEnergy representing the current energy available?

 

Thanks!

I read it on other udp topic, but i will give you my formula :

$nPourcentErs = $nErsRemaining * 100 / 4000000;

 

Enjoy

[GambaDoCerrado]

1 hour ago, ThibaudPHP said:

I read it on other udp topic, but i will give you my formula :

$nPourcentErs = $nErsRemaining * 100 / 4000000;

 

Enjoy

Or simple $nPourcentErs = $nErsRemaining  / 40000;

[RoNiNs8]

On 8/7/2021 at 2:38 AM, DaveyGravy said:

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

Skilled telemetry app user for xbox here and can confirm BROADCAST Mode for Xbox Series X is completely broken.  Switching to broadcast mode only enables the telemetry for the device IP that is input for non-broadcast mode so I know it isn't the devices themselves... has codemasters made any acknowedgement of this issue?  Is there going to be a fix??  I can't imagine it is an issue with RS Dash itself.

[cjorgens79]

4 minutes ago, RoNiNs8 said:

Skilled telemetry app user for xbox here and can confirm BROADCAST Mode for Xbox Series X is completely broken.  Switching to broadcast mode only enables the telemetry for the device IP that is input for non-broadcast mode so I know it isn't the devices themselves... has codemasters made any acknowedgement of this issue?  Is there going to be a fix??  I can't imagine it is an issue with RS Dash itself.

FYI try manually using the broadcast address instead and see if that works, I wonder if the series x has some networking restrictions that are causing issues. I would suggest trying a subnet broadcast first. To do this, make sure the broadcast option in the game is turned off, and in the IP address put the IP of one of your devices but change the last number to 255. So if your device was 192.168.100.40, then you would set the IP to 192.168.100.255

The alternative is a global broadcast, for this you would use 255.255.255.255 as the IP address, however this tends to be less compatible with some hardware than a subnet broadcast, so i would suggest trying the subnet broadcast first.

[ericgvmaia]

5 hours ago, GambaDoCerrado said:

Or simple $nPourcentErs = $nErsRemaining  / 40000;

Thanks a lot my friend.

[DaveyGravy]

6 hours ago, RoNiNs8 said:

Skilled telemetry app user for xbox here and can confirm BROADCAST Mode for Xbox Series X is completely broken.  Switching to broadcast mode only enables the telemetry for the device IP that is input for non-broadcast mode so I know it isn't the devices themselves... has codemasters made any acknowedgement of this issue?  Is there going to be a fix??  I can't imagine it is an issue with RS Dash itself.

Thanks for confirming. No, I doubt it's RS Dash at fault as my app Race Dash has the same problem. Both are apps that have worked fine for years with broadcast mode (And still do on platforms other than XB).  I've not seen any acknowledgement so it's probably worth one of us logging it through the correct channels. As the first piece of data they want is the report code, as an XBox owner I'm afraid that job might fall to you... sorry 😌

[DaveyGravy]

6 hours ago, cjorgens79 said:

FYI try manually using the broadcast address instead and see if that works, I wonder if the series x has some networking restrictions that are causing issues. I would suggest trying a subnet broadcast first. To do this, make sure the broadcast option in the game is turned off, and in the IP address put the IP of one of your devices but change the last number to 255. So if your device was 192.168.100.40, then you would set the IP to 192.168.100.255

The alternative is a global broadcast, for this you would use 255.255.255.255 as the IP address, however this tends to be less compatible with some hardware than a subnet broadcast, so i would suggest trying the subnet broadcast first.

I did try using 192.168.x.255 as the unicast address at the time on my Playstation and it didn't work, which is a shame as it would have been a nice work around for XB users. I didn't try the global broadcast address as it seemed a long shot, but you never know.

[cjorgens79]

2 hours ago, DaveyGravy said:

I did try using 192.168.x.255 as the unicast address at the time on my Playstation and it didn't work, which is a shame as it would have been a nice work around for XB users. I didn't try the global broadcast address as it seemed a long shot, but you never know.

255.255.255.255 is what the Project CARS games all use for their UDP telemetry. It's also possible that the game itself may do some sort of validation on the IP address entered and disable telemetry if it doesn't like the look of it.

[dwin20]

@Hoo What is the equation - given the current dataset to figure out whether your car is bottoming out or not - thanks

[Hoo]

11 hours ago, dwin20 said:

@Hoo What is the equation - given the current dataset to figure out whether your car is bottoming out or not - thanks

There is whole bunch of physics that works this all out, so not really something that we can provide through the data in the UDP system. We have a simplified version for remotely-controlled players in a network session, but this is still something that we can't really give a simple answer to.

[GambaDoCerrado]

Hi guys. I very happy with new telemetry structure... its more logical... I need some help.
@Hoo can you confirm this: "

• "UDP: LapHistoryDate will now be correctly sent for an active car after another has retired."
  
  Thanks.

Edited August 14, 2021 by GambaDoCerrado

[ericgvmaia]

On the CarStatusData, why is m_tyresAgeLaps so inconsistent?

For example, on a 3 lap race:

End of lap 1 = m_tyresAgeLaps=0.
End of lap 2 = m_tyresAgeLaps=1.
End of lap 3 = m_tyresAgeLaps=3.

Shouldn't it be 1 to 3? or at least 0 to 2...

Also, when a driver pits, first and second lap after the pit is always m_tyresAgeLaps=0.

It does not increment...

Am I doing something wrong?

[GambaDoCerrado]

10 hours ago, ericgvmaia said:

On the CarStatusData, why is m_tyresAgeLaps so inconsistent?

For example, on a 3 lap race:

End of lap 1 = m_tyresAgeLaps=0.
End of lap 2 = m_tyresAgeLaps=1.
End of lap 3 = m_tyresAgeLaps=3.

Shouldn't it be 1 to 3? or at least 0 to 2...

Also, when a driver pits, first and second lap after the pit is always m_tyresAgeLaps=0.

It does not increment...

Am I doing something wrong?

You miss something in decode.... post your unpack for us... this values its possible vehicleFiaFlags

[ThibaudPHP]

I have a very weird problem and i would like some make the same test as me to know if i am crazy or not. If one of you want to loose 5 minutes...

i am on PS5 // patch 1.06

I am going on solo mode. I choose  grand prix mode. track barhain. no qualif / no practice / only race 5 laps.

I choose lewis hamilton.

My objective was to track bug on warning and penalties on packet 2, because i have the feeling something don't work, but i found another thing...

the race start, my telemetry told me via the header part that PlayerCarIndex = 19

i check on packet 4 who is index 19 : IndexJoueur: 19 | AiControlled: 0 | DriverId: 7 | NetworkId: 255 | TeamId: 0 (Mercedes) | MyTeam: 0 | RaceNumber: 44 | Nationality: 10 (Britannique) | Nom: HAMILTON | YourTelemetry: 1

we are good.

now, i wrote a little code where on packet 2, this fields (m_currentLapNum, m_penalties, m_warnings) have an update, it's wrote something on my terminal to show me the update

I start the race, i let everyone overtook me and i stay at 15 seconds behind schumarer's son.

and at a moment, i am still on lap 1 at 15s, my code display :
 

Player 19 | LastLapTime : 109195 | CurrentLapTime : 50 | Sector1TimeInMS : 0 | Sector2TimeInMS : 0 | LapDistance : 4.2529296875 | TotalDistance : 5413.138671875 | SafetyCarDelta : -0 | CarPosition : 12 | CurrentLapNum : 2 | PitStatus : 0 | NumPitStop : 0 | Sector : 0 | CurrentLapInvalid : 0 | Penalties : 0 | Warnings : 0 | UnservedDriveThroughPen : 0 | UnservedStopGoPens : 0 | GridPosition
 

Obviously, the index 19 on packet 2, is not me. I am in position 20, the packet 2 - index 19 told me I am 12...

Can someone can test to see if he had the same behavior please ???
 

Edited August 12, 2021 by ThibaudPHP

[ThibaudPHP]

1 hour ago, ThibaudPHP said:

I have a very weird problem and i would like some make the same test as me to know if i am crazy or not. If one of you want to loose 5 minutes...

i am on PS5 // patch 1.06

I am going on solo mode. I choose  grand prix mode. track barhain. no qualif / no practice / only race 5 laps.

I choose lewis hamilton.

My objective was to track bug on warning and penalties on packet 2, because i have the feeling something don't work, but i found another thing...

the race start, my telemetry told me via the header part that PlayerCarIndex = 19

i check on packet 4 who is index 19 : IndexJoueur: 19 | AiControlled: 0 | DriverId: 7 | NetworkId: 255 | TeamId: 0 (Mercedes) | MyTeam: 0 | RaceNumber: 44 | Nationality: 10 (Britannique) | Nom: HAMILTON | YourTelemetry: 1

we are good.

now, i wrote a little code where on packet 2, this fields (m_currentLapNum, m_penalties, m_warnings) have an update, it's wrote something on my terminal to show me the update

I start the race, i let everyone overtook me and i stay at 15 seconds behind schumarer's son.

and at a moment, i am still on lap 1 at 15s, my code display :
 

Player 19 | LastLapTime : 109195 | CurrentLapTime : 50 | Sector1TimeInMS : 0 | Sector2TimeInMS : 0 | LapDistance : 4.2529296875 | TotalDistance : 5413.138671875 | SafetyCarDelta : -0 | CarPosition : 12 | CurrentLapNum : 2 | PitStatus : 0 | NumPitStop : 0 | Sector : 0 | CurrentLapInvalid : 0 | Penalties : 0 | Warnings : 0 | UnservedDriveThroughPen : 0 | UnservedStopGoPens : 0 | GridPosition
 

Obviously, the index 19 on packet 2, is not me. I am in position 20, the packet 2 - index 19 told me I am 12...

Can someone can test to see if he had the same behavior please ???
 

Okay guys, i am stupid. I found my mistake

I let my other post here to remember to me, to better check before to post. £

Shame : 1 - Thibaud : 0

 

[GambaDoCerrado]

1 minute ago, ThibaudPHP said:

Okay guys, i am stupid. I found my mistake

I let my other post here to remember to me, to better check before to post. £

Shame : 1 - Thibaud : 0

 

hahahah 

[dwin20]

On 8/11/2021 at 6:12 AM, Hoo said:

There is whole bunch of physics that works this all out, so not really something that we can provide through the data in the UDP system. We have a simplified version for remotely-controlled players in a network session, but this is still something that we can't really give a simple answer to.

@Hoo Created a thread on this in setups- but should have come back to you on this - sorry. Here is what I posted:

In trying to come up with a way to know whether a car bottomed out in the telemetry programs - the variables would seem to be ride height (reference plane) -10 (thickness of plank) and the four wheel suspension positions. The wheel positions in the UDP data seem to be set very close to 0 when the car is not moving - so 0 would seem to be when that wheel is at ride height (for front or back). So couldn't you figure what the real-time plane of the plank is - given the four different wheel suspension position, -10 for the actual thickness of the plank... and then whether there is part of the plank (or all) touching the ground. 

The problem seems to be that while there is useful data for the movement of the four wheel suspension positions - that is not true for front and rear ride height which is abstracted and not realistically measurable. So if Codemasters would assign a real height value we could figure bottoming out - but without it...  

Or are my calculations just way off base?

Thanks

[ericgvmaia]

17 hours ago, GambaDoCerrado said:

You miss something in decode.... post your unpack for us... this values its possible vehicleFiaFlags

I don't think I am missing anything, all the other values are correct, including ERS and the vehicleFiaFlags.

I think there is something wrong with the last lap data...

Here's how I get the CarStatusData:

carStatus.setTractionControl(buffer.getNextUInt8AsInt());
        carStatus.setAntiLockBrakes(buffer.getNextUInt8AsBoolean());
        carStatus.setFuelMix(buffer.getNextUInt8AsInt());
        carStatus.setFrontBrakeBias(buffer.getNextUInt8AsInt());
        carStatus.setPitLimiterOn(buffer.getNextUInt8AsBoolean());
        
        carStatus.setFuelInTank(buffer.getNextFloat());
        carStatus.setFuelCapacity(buffer.getNextFloat());
        carStatus.setFuelRemainingLaps(buffer.getNextFloat());
        
        carStatus.setMaxRpm(buffer.getNextUInt16AsInt());
        carStatus.setIdleRpm(buffer.getNextUInt16AsInt());
        
        carStatus.setMaxGears(buffer.getNextUInt8AsInt());
        carStatus.setDrsAllowed(buffer.getNextUInt8AsInt());        
        carStatus.setDrsActivationDistance(buffer.getNextUInt16AsInt());
        
        carStatus.setActualTyreCompound(buffer.getNextUInt8AsInt());
        carStatus.setVisualTyreCompound(buffer.getNextUInt8AsInt());
        carStatus.setTyreAgeLaps(buffer.getNextUInt8AsInt());
            
        carStatus.setVehicleFiaFlags(buffer.getNextInt8AsInt());
        
        carStatus.setErsStoreEnergy(buffer.getNextFloat());
        carStatus.setErsDeployMode(buffer.getNextUInt8AsInt());
        
        carStatus.setErsHarvestedThisLapMGUK(buffer.getNextFloat());
        carStatus.setErsHarvestedThisLapMGUH(buffer.getNextFloat());
        carStatus.setErsDeployedThisLap(buffer.getNextFloat());
        
        carStatus.setNetworkPaused(buffer.getNextUInt8AsBoolean());

[GambaDoCerrado]

On 8/11/2021 at 10:15 AM, GambaDoCerrado said:

Hi guys. I very happy with new telemetry structure... its more logical... I need some help.
@Hoo can you confirm this: "

• "UDP: LapHistoryDate will now be correctly sent for an active car after another has retired."
  
  Thanks.

@Hoocan you confirm please? I received missing packets yet...

[codylane482]

On 8/9/2021 at 6:38 AM, DaveyGravy said:

Multicast is very specialist and uses a reserved IP range (224.x.x.x), so I'd be very surprised if this is what the game is using. All previous versions of the game used broadcast packets in broadcast mode as well. A couple of users say that the game still sends direct only to the previously entered IP, even when they've enabled broadcast mode so this part is definitely a bug at least (Xbox only). Quite why/how you're able to collect the broadcast data using multicast is a bit of a mystery to me but if it's working...

One user did use a different app as well and confirmed that one didn't work with broadcast mode from the Xbox either.

Feel free to try my app - it's a free download and there's a very basic dash that'll work out the box to test functionality.

Cheers

 

After spending the last week troubleshooting, I too experience this now and it requires some fiddling with the IP address even when broadcast mode is turned on. But yeah, I think it's important to admit when you are wrong, and so far I've been totally wrong. As others have mentioned and I would agree it's most likely the Xbox networking implementation.

For now, it's far easier to run  my app with IPv4 address: 0.0.0.0:20777 and then in my Xbox F1 game settings set the IP address to the IP of my app.

I'm starting to wonder now if it's a subnet issue. For example, I use DHCP for my network and it's a wired connection. My DHCP server is running Linux and I know it's configured correctly to provide the correct subnet for all of it's DHCP clients. The one weird thing I've always noticed is that when my Xbox gets it's DHCP address it never gets the right netmask. It's always set to 255.0.0.0 but it should be 255.255.255.0 so I have to manually go in and set the IP and netmask.

 

I will continue to run some more tests and see if I can nail this down. 

[TMIllo]

Hi,

Wondering if you can help. I'm trying to pull the driver name, specifically the Steam ID. In the telemetry sheet, it says either m_networkId or m_name[48] should be what I use to get this (I think?)

When I use networkID I get a number, which isn't helpful and when I use m_name I can only do it by Position [GameRawData.PlayerParticipantData.m_name01] and that only returns the letter P, despite no-one in our session starting with that letter.

Ideally, and I'd assume this is possible, like to pull the SteamID of the user and also be able to pull the steamID of everyone in the session. Can you help with what I'm doing wrong?