F1 2018 UDP Specification

**Hoo** · August 23, 2018

OVERVIEW

The F1 series of games support the outputting of key game data via a UDP data stream. This data can be interpreted by external apps or connected peripherals for a range of different uses, including providing additional telemetry information, customised HUD displays, motion platform hardware support or providing force feedback data for custom steering wheels. The following information is a summary of the data that is outputted so that developers of supporting hardware or software are able to configure these to work with the F1 game correctly. If the information you require is not contained here, or if you have any issues with the UDP data itself, then please let us know and a member of the dev team will respond to your query as soon as possible.

**Hoo** · August 23, 2018

PACKET TYPES

The main change for 2018 is the introduction of multiple packet types: each packet can now carry different types of data rather than having one packet which contains everything. A header has been added to each packet as well so that versioning can be tracked and it will be easier for applications to check they are interpreting the incoming data in the correct way.

Each packet has the following header:

struct PacketHeader
{
    uint16    m_packetFormat;         // 2018
    uint8     m_packetVersion;        // Version of this packet type, all start from 1
    uint8     m_packetId;             // Identifier for the packet type, see below
    uint64    m_sessionUID;           // Unique identifier for the session
    float     m_sessionTime;          // Session timestamp
    uint      m_frameIdentifier;      // Identifier for the frame the data was retrieved on
    uint8     m_playerCarIndex;       // Index of player's car in the array
};

Image: /old_uploads/editor/i2/fj958zeqdhf8.png

**Hoo** · August 23, 2018

MOTION PACKET

The motion packet gives physics data for all the cars being driven. There is additional data for the car being driven with the goal of being able to drive a motion platform setup.

N.B. For the normalised vectors below, to convert to float values divide by 32767.0f. 16-bit signed values are used to pack the data and on the assumption that direction values are always between -1.0f and 1.0f.

Frequency: Rate as specified in menus

Size: 1341 bytes

struct CarMotionData
{
    float         m_worldPositionX;           // World space X position
    float         m_worldPositionY;           // World space Y position
    float         m_worldPositionZ;           // World space Z position
    float         m_worldVelocityX;           // Velocity in world space X
    float         m_worldVelocityY;           // Velocity in world space Y
    float         m_worldVelocityZ;           // Velocity in world space Z
    int16         m_worldForwardDirX;         // World space forward X direction (normalised)
    int16         m_worldForwardDirY;         // World space forward Y direction (normalised)
    int16         m_worldForwardDirZ;         // World space forward Z direction (normalised)
    int16         m_worldRightDirX;           // World space right X direction (normalised)
    int16         m_worldRightDirY;           // World space right Y direction (normalised)
    int16         m_worldRightDirZ;           // World space right Z direction (normalised)
    float         m_gForceLateral;            // Lateral G-Force component
    float         m_gForceLongitudinal;       // Longitudinal G-Force component
    float         m_gForceVertical;           // Vertical G-Force component
    float         m_yaw;                      // Yaw angle in radians
    float         m_pitch;                    // Pitch angle in radians
    float         m_roll;                     // Roll angle in radians
};

struct PacketMotionData { PacketHeader m_header; // Header CarMotionData m_carMotionData[20]; // Data for all cars on track // Extra player car ONLY data float m_suspensionPosition[4]; // Note: All wheel arrays have the following order: float m_suspensionVelocity[4]; // RL, RR, FL, FR float m_suspensionAcceleration[4]; // RL, RR, FL, FR float m_wheelSpeed[4]; // Speed of each wheel float m_wheelSlip[4]; // Slip ratio for each wheel float m_localVelocityX; // Velocity in local space float m_localVelocityY; // Velocity in local space float m_localVelocityZ; // Velocity in local space float m_angularVelocityX; // Angular velocity x-component float m_angularVelocityY; // Angular velocity y-component float m_angularVelocityZ; // Angular velocity z-component float m_angularAccelerationX; // Angular velocity x-component float m_angularAccelerationY; // Angular velocity y-component float m_angularAccelerationZ; // Angular velocity z-component float m_frontWheelsAngle; // Current front wheels angle in radians };

SESSION PACKET

The session packet includes details about the current session in progress.

Frequency: 2 per second

Size: 147 bytes

struct MarshalZone
{
    float  m_zoneStart;   // Fraction (0..1) of way through the lap the marshal zone starts
    int8   m_zoneFlag;    // -1 = invalid/unknown, 0 = none, 1 = green, 2 = blue, 3 = yellow, 4 = red
};

struct PacketSessionData
{
    PacketHeader    m_header;               	// Header

    uint8           m_weather;              	// Weather - 0 = clear, 1 = light cloud, 2 = overcast
                                            	// 3 = light rain, 4 = heavy rain, 5 = storm
    int8	    m_trackTemperature;    	// Track temp. in degrees celsius
    int8	    m_airTemperature;      	// Air temp. in degrees celsius
    uint8           m_totalLaps;           	// Total number of laps in this race
    uint16          m_trackLength;           	// Track length in metres
    uint8           m_sessionType;         	// 0 = unknown, 1 = P1, 2 = P2, 3 = P3, 4 = Short P
                                            	// 5 = Q1, 6 = Q2, 7 = Q3, 8 = Short Q, 9 = OSQ
                                            	// 10 = R, 11 = R2, 12 = Time Trial
    int8            m_trackId;         		// -1 for unknown, 0-21 for tracks, see appendix
    uint8           m_era;                  	// Era, 0 = modern, 1 = classic
    uint16          m_sessionTimeLeft;    	// Time left in session in seconds
    uint16          m_sessionDuration;     	// Session duration in seconds
    uint8           m_pitSpeedLimit;      	// Pit speed limit in kilometres per hour
    uint8           m_gamePaused;               // Whether the game is paused
    uint8           m_isSpectating;        	// Whether the player is spectating
    uint8           m_spectatorCarIndex;  	// Index of the car being spectated
    uint8           m_sliProNativeSupport;	// SLI Pro support, 0 = inactive, 1 = active
    uint8           m_numMarshalZones;         	// Number of marshal zones to follow
    MarshalZone     m_marshalZones[21];         // List of marshal zones – max 21
    uint8           m_safetyCarStatus;          // 0 = no safety car, 1 = full safety car
                                                // 2 = virtual safety car
    uint8          m_networkGame;              // 0 = offline, 1 = online
};

LAP DATA PACKET

The lap data packet gives details of all the cars in the session.

Frequency: Rate as specified in menus

Size: 841 bytes

struct LapData
{
    float       m_lastLapTime;           // Last lap time in seconds
    float       m_currentLapTime;        // Current time around the lap in seconds
    float       m_bestLapTime;           // Best lap time of the session in seconds
    float       m_sector1Time;           // Sector 1 time in seconds
    float       m_sector2Time;           // Sector 2 time in seconds
    float       m_lapDistance;           // Distance vehicle is around current lap in metres – could
                                         // be negative if line hasn’t been crossed yet
    float       m_totalDistance;         // Total distance travelled in session in metres – could
                                         // be negative if line hasn’t been crossed yet
    float       m_safetyCarDelta;        // Delta in seconds for safety car
    uint8       m_carPosition;           // Car race position
    uint8       m_currentLapNum;         // Current lap number
    uint8       m_pitStatus;             // 0 = none, 1 = pitting, 2 = in pit area
    uint8       m_sector;                // 0 = sector1, 1 = sector2, 2 = sector3
    uint8       m_currentLapInvalid;     // Current lap invalid - 0 = valid, 1 = invalid
    uint8       m_penalties;             // Accumulated time penalties in seconds to be added
    uint8       m_gridPosition;          // Grid position the vehicle started the race in
    uint8       m_driverStatus;          // Status of driver - 0 = in garage, 1 = flying lap
                                         // 2 = in lap, 3 = out lap, 4 = on track
    uint8       m_resultStatus;          // Result status - 0 = invalid, 1 = inactive, 2 = active
                                         // 3 = finished, 4 = disqualified, 5 = not classified
                                         // 6 = retired
};

struct PacketLapData
{
    PacketHeader    m_header;              // Header

    LapData         m_lapData[20];         // Lap data for all cars on track
};

EVENT PACKET

This packet gives details of events that happen during the course of the race.

Frequency: When the event occurs

Size: 25 bytes

struct PacketEventData
{
    PacketHeader    m_header;               // Header
    
    uint8           m_eventStringCode[4];   // Event string code, see above
};

PARTICIPANTS PACKET

This is a list of participants in the race. If the vehicle is controlled by AI, then the name will be the driver name. If this is a multiplayer game, the names will be the Steam Id on PC, or the LAN name if appropriate. On Xbox One, the names will always be the driver name, on PS4 the name will be the LAN name if playing a LAN game, otherwise it will be the driver name.

Frequency: Every 5 seconds

Size: 1082 bytes

struct ParticipantData
{
    uint8      m_aiControlled;           // Whether the vehicle is AI (1) or Human (0) controlled
    uint8      m_driverId;               // Driver id - see appendix
    uint8      m_teamId;                 // Team id - see appendix
    uint8      m_raceNumber;             // Race number of the car
    uint8      m_nationality;            // Nationality of the driver
    char       m_name[48];               // Name of participant in UTF-8 format – null terminated
                                         // Will be truncated with … (U+2026) if too long
};

struct PacketParticipantsData
{
    PacketHeader    m_header;            // Header

    uint8           m_numCars;           // Number of cars in the data
    ParticipantData m_participants[20];
};

CAR SETUPS PACKET

This packet details the car setups for each vehicle in the session. Note that in multiplayer games, other player cars will appear as blank, you will only be able to see your car setup and AI cars.

Frequency: Every 5 seconds

Size: 841 bytes

struct CarSetupData
{
    uint8     m_frontWing;                // Front wing aero
    uint8     m_rearWing;                 // Rear wing aero
    uint8     m_onThrottle;               // Differential adjustment on throttle (percentage)
    uint8     m_offThrottle;              // Differential adjustment off throttle (percentage)
    float     m_frontCamber;              // Front camber angle (suspension geometry)
    float     m_rearCamber;               // Rear camber angle (suspension geometry)
    float     m_frontToe;                 // Front toe angle (suspension geometry)
    float     m_rearToe;                  // Rear toe angle (suspension geometry)
    uint8     m_frontSuspension;          // Front suspension
    uint8     m_rearSuspension;           // Rear suspension
    uint8     m_frontAntiRollBar;         // Front anti-roll bar
    uint8     m_rearAntiRollBar;          // Front anti-roll bar
    uint8     m_frontSuspensionHeight;    // Front ride height
    uint8     m_rearSuspensionHeight;     // Rear ride height
    uint8     m_brakePressure;            // Brake pressure (percentage)
    uint8     m_brakeBias;                // Brake bias (percentage)
    float     m_frontTyrePressure;        // Front tyre pressure (PSI)
    float     m_rearTyrePressure;         // Rear tyre pressure (PSI)
    uint8     m_ballast;                  // Ballast
    float     m_fuelLoad;                 // Fuel load
};

struct PacketCarSetupData
{
    PacketHeader    m_header;            // Header

    CarSetupData    m_carSetups[20];
};

CAR TELEMETRY PACKET

This packet details telemetry for all the cars in the race. It details various values that would be recorded on the car such as speed, throttle application, DRS etc.

Frequency: Rate as specified in menus

Size: 1085 bytes

struct CarTelemetryData
{
    uint16    m_speed;                      // Speed of car in kilometres per hour
    uint8     m_throttle;                   // Amount of throttle applied (0 to 100)
    int8      m_steer;                      // Steering (-100 (full lock left) to 100 (full lock right))
    uint8     m_brake;                      // Amount of brake applied (0 to 100)
    uint8     m_clutch;                     // Amount of clutch applied (0 to 100)
    int8      m_gear;                       // Gear selected (1-8, N=0, R=-1)
    uint16    m_engineRPM;                  // Engine RPM
    uint8     m_drs;                        // 0 = off, 1 = on
    uint8     m_revLightsPercent;           // Rev lights indicator (percentage)
    uint16    m_brakesTemperature[4];       // Brakes temperature (celsius)
    uint16    m_tyresSurfaceTemperature[4]; // Tyres surface temperature (celsius)
    uint16    m_tyresInnerTemperature[4];   // Tyres inner temperature (celsius)
    uint16    m_engineTemperature;          // Engine temperature (celsius)
    float     m_tyresPressure[4];           // Tyres pressure (PSI)
};

struct PacketCarTelemetryData
{
    PacketHeader        m_header;                // Header

    CarTelemetryData    m_carTelemetryData[20];

    uint32              m_buttonStatus;         // Bit flags specifying which buttons are being
                                                // pressed currently - see appendices
};

CAR STATUS PACKET

This packet details car statuses for all the cars in the race. It includes values such as the damage readings on the car.

Frequency: 2 per second

Size: 1061 bytes

struct CarStatusData
{
    uint8       m_tractionControl;          // 0 (off) - 2 (high)
    uint8       m_antiLockBrakes;           // 0 (off) - 1 (on)
    uint8       m_fuelMix;                  // Fuel mix - 0 = lean, 1 = standard, 2 = rich, 3 = max
    uint8       m_frontBrakeBias;           // Front brake bias (percentage)
    uint8       m_pitLimiterStatus;         // Pit limiter status - 0 = off, 1 = on
    float       m_fuelInTank;               // Current fuel mass
    float       m_fuelCapacity;             // Fuel capacity
    uint16      m_maxRPM;                   // Cars max RPM, point of rev limiter
    uint16      m_idleRPM;                  // Cars idle RPM
    uint8       m_maxGears;                 // Maximum number of gears
    uint8       m_drsAllowed;               // 0 = not allowed, 1 = allowed, -1 = unknown
    uint8       m_tyresWear[4];             // Tyre wear percentage
    uint8       m_tyreCompound;             // Modern - 0 = hyper soft, 1 = ultra soft
                                            // 2 = super soft, 3 = soft, 4 = medium, 5 = hard
                                            // 6 = super hard, 7 = inter, 8 = wet
                                            // Classic - 0-6 = dry, 7-8 = wet
    uint8       m_tyresDamage[4];           // Tyre damage (percentage)
    uint8       m_frontLeftWingDamage;      // Front left wing damage (percentage)
    uint8       m_frontRightWingDamage;     // Front right wing damage (percentage)
    uint8       m_rearWingDamage;           // Rear wing damage (percentage)
    uint8       m_engineDamage;             // Engine damage (percentage)
    uint8       m_gearBoxDamage;            // Gear box damage (percentage)
    uint8       m_exhaustDamage;            // Exhaust damage (percentage)
    int8        m_vehicleFiaFlags;          // -1 = invalid/unknown, 0 = none, 1 = green
                                            // 2 = blue, 3 = yellow, 4 = red
    float       m_ersStoreEnergy;           // ERS energy store in Joules
    uint8       m_ersDeployMode;            // ERS deployment mode, 0 = none, 1 = low, 2 = medium
                                            // 3 = high, 4 = overtake, 5 = hotlap
    float       m_ersHarvestedThisLapMGUK;  // ERS energy harvested this lap by MGU-K
    float       m_ersHarvestedThisLapMGUH;  // ERS energy harvested this lap by MGU-H
    float       m_ersDeployedThisLap;       // ERS energy deployed this lap
};

struct PacketCarStatusData
{
    PacketHeader        m_header;            // Header

    CarStatusData       m_carStatusData[20];
};

**Hoo** · August 23, 2018

Appendices for the various IDs used in the UDP output:

(Hoo: IDs have been updated on 10th Sept 2018 as several of them were missing)

**Hoo** · August 23, 2018

FAQS

How do I enable the UDP Telemetry Output?

In F1 2018, UDP telemetry output is controlled via the menus. To enable this, enter the options menu from the main menu (triangle / Y), then enter the settings menu - the UDP option will be at the bottom of the list. From there you will be able to enable / disable the UDP output, configure the IP address and port for the receiving application, toggle broadcast mode and set the send rate. Broadcast mode transmits the data across the network subnet to allow multiple devices on the same subnet to be able to receive this information. When using broadcast mode it is not necessary to set a target IP address, just a target port for applications to listen on.

Can I configure the UDP output using an XML File?

PC users can edit the game’s configuration XML file to configure UDP output. The file is located here (after an initial boot of the game):

...\Documents\My Games\<game_folder>\hardwaresettings\hardware_settings_config.xml

You should see the tag:

...

...

</motion>

Here you can set the values manually. Note that any changes made within the game when it is running will overwrite any changes made manually.

What is the order of the wheel arrays?

All wheel arrays are in the following order:

0 – Rear Left (RL)

1 – Rear Right (RR)

2 – Front Left (FL)

3 – Front Right (FR)

Do the vehicle indices change?

During a session, each car is assigned a vehicle index. This will not change throughout the session and all the arrays that are sent use this vehicle index to dereference the correct piece of data.

What encoding format is used?

All values are encoded using Little Endian format.

Is the data packed?

Yes, all data is packed.

Will my F1 2017 app still work with F1 2018?

F1 2018 uses a new format for the UDP data. However, the F1 2017 implementation is still supported by the game and is referred to as the “legacy” format. This should allow most apps implemented using the previous data format to work with little or no change from the developer. To use the old format, please enter the UDP options menu and set “UDP Format” to “legacy”. Specifications for the legacy format can be seen here: http://forums.codemasters.com/discussion/53139/f1-2017-d-box-and-udp-output-specification/p1.

How do I enable D-BOX output?

D-BOX output is currently supported on the PC platform. In F1 2018, the D-BOX activation can be controlled via the menus. Navigate to Game Options->Settings->UDP Telemetry Settings->D-BOX to activate this on your system.

Advanced PC Users: It is possible to control D-BOX by editing the games’ configuration XML file. The file is located here (after an initial boot of the game):

...\Documents\My Games\<game_folder>\hardwaresettings\hardware_settings_config.xml

You should see the tag:

...

</motion>

Set the “enabled” value to “true” to allow the game to output to your D-BOX motion platform. Note that any changes made within the game when it is running will overwrite any changes made manually.

How can I disable in-game support for LED device?

The F1 game has native support for some of the basic features supported by some external LED devices, such as the Leo Bodnar SLI Pro and the Fanatec steering wheels. To avoid conflicts between Codemasters’ implementation and any third-party device managers on the PC platform it may be necessary to disable the native support. This is done using the following led_display flags in the hardware_settings_config.xml. The file is located here (after an initial boot of the game):

...\Documents\My Games\<game_folder>\hardwaresettings\hardware_settings_config.xml

The flags to enabled/disable LED output are:

<led_display fanatecNativeSupport="true" sliProNativeSupport="true" />

The sliProNativeSupport flag controls the output to SLI Pro devices. The fanatecNativeSupport flag controls the output to Fanatec (and some related) steering wheel LEDs. Set the values for any of these to “false” to disable them and avoid conflicts with your own device manager.

Please note there is an additional flag to manually control the LED brightness on the SLI Pro:

<led_display sliProForceBrightness="127" />

This option (using value in the range 0-255) will be ignored when setting the sliProNativeSupport flag to “false”.

Also note it is now possible to edit these values on the fly via the Game Options->Settings->UDP Telemetry Settings menu.

Alex35zombi · August 23, 2018

I have one question is the data streamed on replay mode and spectator?

gaetanomatonti · August 23, 2018

Wow that's a big load of data being transmitted, good job!

**Hoo** · August 24, 2018

Alex35zombi said:

I have one question is the data streamed on replay mode and spectator?

Yes. :)

Let us know if encounter any problems with this.

carlucio24 · August 24, 2018

Hi, great job with this new telemetry protocol.
What are MarshalZones ?

trenamax · August 24, 2018

Hi Hoo -
I wish I'd spotted this issue during the Beta so apologies about that. I play the game with fully functional replica F1 wheels (see here: https://www.youtube.com/watch?v=hrq2cmSdp04). I have an LED which illuminated when DRS is allowed, and an additional one which illuminates when DRS is active.

I've noticed whilst playing this evening there seems to be a delay in the DRS Legal LED illuminating when entering a DRS zone, and now I realise it's because m_drsAllowed is in the Car Status packet (only sent twice a second), whereas m_drs is in the Car Telemetery Data packet (sent at game setting which is 60hz in my case). My DRS LED works instantly I should add. Both worked perfectly in F1 2015-2017.

Is there any chance we can move m_drsAllowed into the Car Telemetery Data packet so it's sent at a descent rate please? It seems like the two should be sent in the same packet.

Many thanks, and loving the full version of the game :)

Mike

LonelyRacer · August 26, 2018

Hoo said:

CAR TELEMETRY PACKET

This packet details telemetry for all the cars in the race. It details various values that would be recorded on the car such as speed, throttle application, DRS etc.

Frequency: Rate as specified in menus

Size: 1085 bytes

struct CarTelemetryData
{
    uint16    m_speed;                      // Speed of car in kilometres per hour
    uint8     m_throttle;                   // Amount of throttle applied (0 to 100)
    int8      m_steer;                      // Steering (-100 (full lock left) to 100 (full lock right))
    uint8     m_brake;                      // Amount of brake applied (0 to 100)
    uint8     m_clutch;                     // Amount of clutch applied (0 to 100)
    int8      m_gear;                       // Gear selected (1-8, N=0, R=-1)
    uint16    m_engineRPM;                  // Engine RPM
    uint8     m_drs;                        // 0 = off, 1 = on
    uint8     m_revLightsPercent;           // Rev lights indicator (percentage)
    uint16    m_brakesTemperature[4];       // Brakes temperature (celsius)
    uint16    m_tyresSurfaceTemperature[4]; // Tyres surface temperature (celsius)
    uint16    m_tyresInnerTemperature[4];   // Tyres inner temperature (celsius)
    uint16    m_engineTemperature;          // Engine temperature (celsius)
    float     m_tyresPressure[4];           // Tyres pressure (PSI)
};

Thank you for the data.

Been converting my Telemetry Tool to accept the new data. I haven't looked into the data too deeply yet, but will do that during the coming days.

Classic drivers

One note. When you do the race in Classic era, there are drivers (e.g. m_driverId 41), which are not listed in the table above. Any change to send the updated list here?

Speed etc in Floats instead of Ints?

Would it be possible to provide the m_speed, m_throttle, m_steer and m_brake as floats instead of ints? It would only add few bytes to the CarTelemetryData, but for people doing the telemetry for Wheel users, the more granular data would be super helpful.

Thanks.

EnsiFerrum · August 27, 2018

Found a bug:
ParticipantData.m_teamId returns 35, no matter in which historic car I am.
Tested in Time-Trial mode.
This makes any per car setting useless.

Edit: It occurs only in Time Trial mode. After a quick look in my notes I can say we had this bug already in F1-2017. Never got fixed. Hope it will be adressed in the next patch, please.

cjorgens79 · August 28, 2018

@Hoo - what is the difference between m_tyresWear and m_tyresDamage in the Car Status packet? From what i can tell they always seem to have the exact same value. I thought that perhaps m_tyresDamage was related to the suspension or rim damage, however it just seems to be the same as the tyre wear percentage.

cjorgens79 · August 28, 2018

There appears to be some issues with the timing data for Time Trial, it seems to contain data for a number of additional non-existant players. The m_numCars is 1, however there are multiple entries in the lap data record that appear to be active. They show as lap 1, position 1 and for all intensive purposes appear to be an active player (albeit with overlapping race positions). They even have valid x/y/z world co-ordinates.

At the moment I have had to work around it by doing a check for m_numCars = 1, in which case i know there is only the "player", so i can use the m_playerCarIndex to make sure i grab the right entry, as they all overlap each other in terms of their result (race position).

ReddishTheGreat · August 28, 2018

Is there any chance we can move m_drsAllowed into the Car Telemetery Data packet so it's sent at a descent rate please? It seems like the two should be sent in the same packet.

A possible alternative would be to change the m_drs field in the Car Telemetry Packet to be a bitfield:

0 == no DRS allowed;
2 == DRS allowed but inactive;
3 == DRS allowed and active.

(We should never see 1, normally -- well perhaps if there is a 'DRS stuck open' fault mode).

ReddishTheGreat · August 28, 2018

Bug report (F1 2018 TELEMETRY):

At the beginning of a new session, some UDP packets are transmitted with the sessionUID field set to the previous session's UID.

In the first session after starting the game, a few packets with sessionUID equal to zero are transmitted.

Seems that the sessionUID field is set after enabling UDP telemetry, where it should be set before. So this may well be easy to fix.

EDIT: bug reported as top-level post, see:

http://forums.codemasters.com/discussion/138130/bug-f1-2018-pc-v1-0-4-udp-telemetry-bad-session-uid-in-first-few-packets-of-a-session

ReddishTheGreat · August 28, 2018

Suggested improvement to telemetry:

It would be very useful to get a telemetry value for terrain type (perhaps one per wheel, perhaps one for the car center). It could be as simple as an enumeration: 0==ASPHALT, 1==CURB, 2==GRASS, 3==GRAVEL.

willgarling · August 28, 2018

Can anyone tell me which platforms would be compatible with this game?

HassanKLD · August 30, 2018

Hello!

Firstly thanks for posting this @Hoo. I'm currently creating something for myself, but found the forum a little tedious to keep coming back to for the info, so I created a quick reference doc for myself. Others might find it useful. Link here. It's not fully complete I still need to port of the full appendices. @Hoo If you or anyone at Codemasters would like to take ownership of this I'm more than happy to. It's just a github repo, and the docs are written in Markdown and auto generated.

Ok so on the actual UDP spec side, I picked up a few things and just wanted to clarify/point few things out.

the buffer size for Motion packet is 1341 Bytes, after accounting for everything in the structs I get a total of 1221 Bytes. Is this correct? If so whats in the remaining 120 Bytes? anything useful or can it be simply ignored.
The m_eventStringCode in the PacketEventData Struct are mentioned to be UInt8[4], but in the table below it shows code as 'SSTA' and 'SEND'. is the UInt8 an error as they should be Chars
I agree with @trenamax to move the m_drsAllowed to the carTelemetryPacket
I would really like to have the track limits in the data stream, maybe m_trackLimitLeft and m_tackLimitRight maybe on the MotionData Packet. Edit: thinking more about this, I think it would be useful to get the world x,y, z of the left and right limit

thanks! Hass

trenamax · August 30, 2018

Hi @HassanKLD -

I wrote an app during the beta, and can confirm that the motion data packet does indeed total to 1341 bytes all used. So you must have missed something somewhere.

You might find this mapping spreadsheet I put together useful:

https://btcloud.bt.com/web/app/share/invite/cCKudhtU11

Pleased you agree about DRS Legal moving to the car telemetry packet, its really noticeable for me whilst driving.

HassanKLD · August 30, 2018

Hi @trenamax

Thanks for that spreadsheet, that helped. You are correct, was missing all the m_worldRgihtDirection entries in my app.

Alex35zombi · August 30, 2018

I'm using C# and my UDPClient is only able to access to the bytes from the PacketCarTelemetryData, any way I could make my client to receive the bytes from all structures?

UdpClient client = new UdpClient(20777);
IPEndPoint ep = new IPEndPoint(IPAddress.Any, 0);

void UpdateData()
{
    while (true)
    {
        byte[] arr = client.Receive(ref ep);
        Console.WriteLine(arr.Length.ToString()); // Output: 1085 (PacketCarTelemetryData byte size)
    }
}

LetMeThrashU · August 30, 2018

What is the total value that the ERS battery can store and harvest? Looking at the rules, the MGU-K can recover unto 2MJ/lap and the MGU-H is unlimited. What values do the steering wheels in your game use for max harvest and total energy?

Drospy · August 30, 2018

Hi all,

please Codemaster change the frequency for "Car Status Packet", 2 second is too high.

m_drsAllowed, m_vehicleFiaFlags, m_pitLimiterStatus and m_fuelMix are very important.

EnsiFerrum · August 30, 2018

LetMeThrashU said:

What is the total value that the ERS battery can store and harvest? Looking at the rules, the MGU-K can recover unto 2MJ/lap and the MGU-H is unlimited. What values do the steering wheels in your game use for max harvest and total energy?

Battery is 4MJ
Harvest is 2MJ

IJS84 · August 30, 2018

Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?
I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'
So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)
@Hoo

fierogt4 · August 31, 2018

how are you doing to put f1 2017 profile to f1 2018 for next level racing platform

Son4R · August 31, 2018

IJS84 said:

Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?
I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'
So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)
@Hoo

I'm receiving the correct AI names in career, and online I receive "Player" everyone.
Wondering if I am doing something wrong.

LetMeThrashU · August 31, 2018

Son4R said:

IJS84 said:

Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?
I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'
So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)
@Hoo

I'm receiving the correct AI names in career, and online I receive "Player" everyone.
Wondering if I am doing something wrong.

Do you have some code to show so that we can tell if there is an error? If you have a StackOverflow account, feel free to create a post there and link it here.

LonelyRacer · August 31, 2018

Son4R said:

IJS84 said:

Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?
I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'
So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)
@Hoo

I'm receiving the correct AI names in career, and online I receive "Player" everyone.
Wondering if I am doing something wrong.

Well, at least last year Hoo said that because of the privacy rules, they cannot push the player names to the UDP stream. I don't know if that has changed for this year.

sonder774 · August 31, 2018

Why is broadcast mode blatantly broken in both F1 2017 and F1 2018?

Am I misunderstanding something? It's supposed to allow multiple apps to listen/connect to the UDP port. Never have gotten it to work.. There's a 3rd party program written specfically for this issue, and F1 2018 is still bugged? Mates... Fernando is faster than you.

IJS84 · August 31, 2018

LonelyRacer said:

Son4R said:

IJS84 said:

Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?
I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'
So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)
@Hoo

I'm receiving the correct AI names in career, and online I receive "Player" everyone.
Wondering if I am doing something wrong.

Well, at least last year Hoo said that because of the privacy rules, they cannot push the player names to the UDP stream. I don't know if that has changed for this year.

Yeah for PS4 it does transmit the name - just seems to replace the first 7 characters with 'Player[null]', and the spec says it's LAN names for ps4 online sessions

SimShaker · September 1, 2018

Hi guys,
I'm trying to use m_gForceLongitudinal (Longitudinal G-Force component) data, capturing it from 2018 format Motion type packets, but getting multiple drop-outs to zero level as you can see on the screenshot attached. To compare, m_yaw (Yaw angle in radians) values coming in the same packets seem to be unbroken. Couldn't see such a problems with a Legacy telemetry format. Any suggestions?

Image: https://1.bp.blogspot.com/-eTGJrOTEqJo/W4q2Ze-f_yI/AAAAAAAAFPU/GlSnzZv-6xUZgCBQQHozmDEtqMnhsx5hQCLcBGAs/s1600/2018-09-01%2B18-47-58%2BChart%2BBuilder%2Bv.1.1.png

mrdezibel · September 2, 2018

can someone please test if this still works, in legacy mode?

https://play.google.com/store/apps/details?id=b4a.f1display

i have users telling me its Buggy and "shifting" the data…

but i am not sure if they using it with the right gamesettings…

any idea how to avoid the app showing data from the "wrong" mode ?

is the first value of f1 2018 always the beginning of the header with m_packetFormat saying 2018?

could be a way to differentiate the modes..

Son4R · September 2, 2018

IJS84 said:

Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?
I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'
So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)
@Hoo

You're correct. I've done some changes to my code, and I now receive Player 37 (name is SonaR1337).
I seriously hope this isn't done intentionally like @LonelyRacer says, since this is the only way I can link users on my website to the data.

LetMeThrashU · September 2, 2018

@Hoo The CarStatus packet is also too slow for the ERS charge.

ReddishTheGreat · September 3, 2018

sonder774 said:

Why is broadcast mode blatantly broken in both F1 2017 and F1 2018?

Am I misunderstanding something? It's supposed to allow multiple apps to listen/connect to the UDP port. Never have gotten it to work.. There's a 3rd party program written specfically for this issue, and F1 2018 is still bugged? Mates... Fernando is faster than you.

You are putting the blame at the wrong side. The game does proper UDP broadcasting. It's the receiving programs that are sloppy.

Receiving programs need to indicate to the operating system's network stack that the port they use for UDP reception may be reused by other programs, (i.e., that they don't claim the port on the computer for exclusive use). The way they should do that is to call ...

setsockopt(socket, SO_REUSEADDR, 1);

... before executing bind(), assuming they are running on Windows. If they don't, bind()ing multiple sockets to the same UDP port will fail on their side, after the first program claims the port.

A good explanation on how this works can be found here: https://stackoverflow.com/questions/14388706.

You should really not be pointing fingers without an understanding of the technical issues.

EDIT: fixed stack overflow URL

ReddishTheGreat · September 3, 2018

Does anyone else see really strange behavior while monitoring the stream of incoming UDP packets?

At the start of a session, I see two Event Start ("SSTA") packets, and at the end I see two Event Stop ("SSTO") packets. Also, I sometimes see short periods where alternating streams of UDP packets arrive with different sessionUID fields, and with different 'frameIndex' fields.

It looks to me as if there are multiple threads running inside the game that broadcast UDP info which are not properly terminated or synchronised. It's quite a mess.

**Hoo** · September 3, 2018

LetMeThrashU said:

What is the total value that the ERS battery can store and harvest? Looking at the rules, the MGU-K can recover unto 2MJ/lap and the MGU-H is unlimited. What values do the steering wheels in your game use for max harvest and total energy?

I believe the max deployment per lap is 4MJ.

**Hoo** · September 3, 2018

ReddishTheGreat said:

Does anyone else see really strange behavior while monitoring the stream of incoming UDP packets?

At the start of a session, I see two Event Start ("SSTA") packets, and at the end I see two Event Stop ("SSTO") packets. Also, I sometimes see short periods where alternating streams of UDP packets arrive with different sessionUID fields, and with different 'frameIndex' fields.

It looks to me as if there are multiple threads running inside the game that broadcast UDP info which are not properly terminated or synchronised. It's quite a mess.

Please can you confirm what game mode you are running and whether you are using broadcast mode and we'll see if we can repeat the issue that you are seeing? Thanks.

LetMeThrashU · September 3, 2018

Ignore me, figured it out.

SimShaker · September 3, 2018

ReddishTheGreat said:
setsockopt(socket, SO_REUSEADDR, 1); 
... before executing bind(), assuming they are running on Windows. If they don't, bind()ing multiple sockets to the same UDP port will fail on their side, after the first program claims the port.

A good explanation on how this works can be found here: https://stackoverflow.com/questions/14388706.

You should really not be pointing fingers without an understanding of the technical issues.

The explanation link seems to be broken...

**Hoo** · September 3, 2018

sonder774 said:

Why is broadcast mode blatantly broken in both F1 2017 and F1 2018?

Am I misunderstanding something? It's supposed to allow multiple apps to listen/connect to the UDP port. Never have gotten it to work.. There's a 3rd party program written specfically for this issue, and F1 2018 is still bugged? Mates... Fernando is faster than you.

Broadcast mode transmits data to the subnet that the game is connected to. Any listening app on the same subnet should be able to read the data. It should not require a specific IP/port to work. There was a bug in the original 2017 UDP implementation where specifying an IP would stop the broadcast feature working correctly, but that has since been fixed.

**Hoo** · September 3, 2018

SimShaker said:

Hi guys,
I'm trying to use m_gForceLongitudinal (Longitudinal G-Force component) data, capturing it from 2018 format Motion type packets, but getting multiple drop-outs to zero level as you can see on the screenshot attached. To compare, m_yaw (Yaw angle in radians) values coming in the same packets seem to be unbroken. Couldn't see such a problems with a Legacy telemetry format. Any suggestions?

Does the frequency of the packet updates affect the results that you are seeing? If you have a similar graph for the 2017 format that gives different results then that would be very interesting to see.

Alex35zombi · September 3, 2018

The player in carrer mode has the ID 1, why it isn't specified in the documentation?

evian004 · September 3, 2018

Hello guys,

i'm new to this but I want to play a little bit bit the data to make an app. Are there any good tutorials how you can start with it because I don't know what language you should use to read the data and convert it to the structure that is given.

Thanks in advance

SimShaker · September 3, 2018

Hoo said:

SimShaker said:

Hi guys,
I'm trying to use m_gForceLongitudinal (Longitudinal G-Force component) data, capturing it from 2018 format Motion type packets, but getting multiple drop-outs to zero level as you can see on the screenshot attached. To compare, m_yaw (Yaw angle in radians) values coming in the same packets seem to be unbroken. Couldn't see such a problems with a Legacy telemetry format. Any suggestions?

Does the frequency of the packet updates affect the results that you are seeing? If you have a similar graph for the 2017 format that gives different results then that would be very interesting to see.

I tried 60 Hz and 20 Hz, couldn't see any difference. Currently 20Hz is set.
In 2017 telemetry format it looks different. There is a couple of kind of drop-outs (I mean first two from the left), but their are not absolute zeros as that with 2018 format, just very small numbers.

Image: https://1.bp.blogspot.com/-z3DuxkwyI2Q/W42GSBgcGRI/AAAAAAAAFPg/oP1agHHxRlwYaKafGxspw38_UaRao4pHgCLcBGAs/s1600/2018-09-03%2B22-05-17%2BChart%2BBuilder%2Bv.1.1.png

LetMeThrashU · September 3, 2018

Whats the difference between tyresWear and tyresDamage? Tyres damage shows 8%, 7% 11% and 10%. This is what I thought tyresWear was. Tyres wear just shows all values as 0%.

Son4R · September 3, 2018

Son4R said:

IJS84 said:

Is anyone else seeing an issue with the participants name packet in multiplayer lobbies?
I was testing it and it replaces the first 7 characters of the human players names with 'Player[null]'
So for example, we have a guy in our league called bluemosquito - his name appears as Player_quito (where _ is the null character)
@Hoo

You're correct. I've done some changes to my code, and I now receive Player 37 (name is SonaR1337).
I seriously hope this isn't done intentionally like @LonelyRacer says, since this is the only way I can link users on my website to the data.

@hoo could you take a look at this? Would like to know if this is intentionally or not, so I could start working around this.

ReddishTheGreat · September 4, 2018

SimShaker said:
The explanation link seems to be broken...

Fixed it, thanks for pointing that out.

F1 2018 UDP Specification

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

FAQS

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment