Welcome to the Codemasters Forums! Be sure to check the FAQ and Forum Rules before you get started.

F1 2017 D-Box and UDP Output Specification

178101213

Comments

  • cjorgens79cjorgens79 Member Unleaded
    tiagovt said:
    How I convert CarUDPData, I don't understand stucture CarUDPData. I was able to convert the rest of the data minus CarUDPData
    what in particular are you having trouble with, how are you trying to read it? Did you set the structure packing correctly as per the earlier post from trbnb?
  • tiagovttiagovt Member New Car Smell
    edited November 2017
    tiagovt said:
    How I convert CarUDPData, I don't understand stucture CarUDPData. I was able to convert the rest of the data minus CarUDPData
    what in particular are you having trouble with, how are you trying to read it? Did you set the structure packing correctly as per the earlier post from trbnb?

    I using Java, I get
    this.setTime(byteBuffer.getFloat(0));
    this.setLapTime(byteBuffer.getFloat(4));

    But I dont know positions in the CarUDPData and your position stucture position

  • cjorgens79cjorgens79 Member Unleaded
    tiagovt said:
    I using Java, I get
    this.setTime(byteBuffer.getFloat(0));
    this.setLapTime(byteBuffer.getFloat(4));

    But I dont know positions in the CarUDPData and your position stucture position

    I dont know what your byteBuffer in the example above is relative too. 

    If the byteBuffer represents the entire UDP packet, then your starting point to get the first value in CarUDPData will be the sum of the sizes of all the variables that appear before
    CarUDPData  m_car_data[20];
    in the struct, so +4 for all the floats and +1 for all the bytes that appear before m_car_data. 
    Now that you have the starting offset for m_car_data, you just loop 20 times from that position, each loop reading out all the fields within the CarUDPData structure which represent a participant.
  • Alex35zombiAlex35zombi Member Unleaded
    edited December 2017
    Hello, I'm making a telemetry app coded in C# and I have the following issue when I am in Q2 or Q3 my driver standing are incorrect but in the other modes are fine

    EDIT: I already fixed the issue
    Post edited by Alex35zombi on
  • iulukayaiulukaya Member New Car Smell
    I have the csl elite wheel p1 with Fanatec v2.5 base on Xbox one x. My leds on the wheels never show telemetry. How to setup
  • steviejay69steviejay69 Member Petrol Head
    iulukaya said:
    I have the csl elite wheel p1 with Fanatec v2.5 base on Xbox one x. My leds on the wheels never show telemetry. How to setup
    Nothing to do with telemetry option. This would be a wheel firmware issue, if it is up to date then this belongs in F1 Technical Assistance where other users could advise you.
    I'm not stupid, I just don't always have all the necessary information,...stupid.
  • ElectricTurtleElectricTurtle Member New Car Smell
    Hi Guys!!!!

    Newbie to the F1 Game (and the telemetry UDP stream) here.

    I am interested in using some of the telemetry data for a machine learning application and I had a few questions I was hoping some of the experts here could help answer:

    1. What does the "m_time" field represent? Is it just time from the start of the race (in seconds? milliseconds?)?

    2.  When, exactly, does the game start spitting out UDP packets? As soon as the "go" signal for the race is given?  I ask because I want to sync the telemetry data with live screenshots captured during a run of the game. If I bind a socket to the address and port the game sends UDP packets to and then listen for data BEFORE I start the game, can I safely assume that the very first packet received signifies the start of the race? (I will run the UDP stream on loopback, so no other programs can s
  • cjorgens79cjorgens79 Member Unleaded
    Hi Guys!!!!

    Newbie to the F1 Game (and the telemetry UDP stream) here.

    I am interested in using some of the telemetry data for a machine learning application and I had a few questions I was hoping some of the experts here could help answer:

    1. What does the "m_time" field represent? Is it just time from the start of the race (in seconds? milliseconds?)?

    2.  When, exactly, does the game start spitting out UDP packets? As soon as the "go" signal for the race is given?  I ask because I want to sync the telemetry data with live screenshots captured during a run of the game. If I bind a socket to the address and port the game sends UDP packets to and then listen for data BEFORE I start the game, can I safely assume that the very first packet received signifies the start of the race? (I will run the UDP stream on loopback, so no other programs can s
    m_time is the current elapsed session time in seconds. The decimal portion of the float is the milliseconds. 

    Telemetry starts as soon as the player appears in their car from memory, whether that be in the garage for prac/qual sessions or on the grid waiting for the starting lights for races. Use the lap timer and lap number to detect once races have started.
  • BDub1027BDub1027 Member New Car Smell
    @Hoo
    Any word on UDP availability / spec for F1 2018? I would love it if we could get car setup data in the UDP packets to help with testing various setups against one another. That would make the telemetry even more useful for those of us who really enjoy tuning the cars.
  • HooHoo Member, Codemasters admin
    Hi @BDub1027,
    The team are planning to re-work parts of this system to help accommodate some of the feature requests that we couldn't previously support. I'll get someone to post any updated specs once they are available (not likely to be for a while though).
  • LopenskyLopensky Member Unleaded
    Hi @Hoo , since the codemaster team is re-working on this, and since i am developing things (like graphics, and general custom UI) for live streaming, is it possible to know what are you going to do?
    Not asking for specific and "final" data.. i just would like to know what are you going to focus on so i don't waste my time developing something that (like this year) will then come out as complete useless.
    Formula Italian Team - Driver & Staffer
    Formula Europe - Staffer

    F1 2018 Beta Tester

    Platform: PS4   -  Games: F1 2016, F1 2017, F1 2018, Assetto Corsa  -  Wheel: T300 GTE & G29
  • HooHoo Member, Codemasters admin
    The main issue we had previously was that the packet size was nearing its maximum, so we were unable to add support for any extra feature requests. The intention is to break this info down into multiple smaller packets covering different things, e.g. Motion Data, Session Info, Lap Data, Session Events, Participant Info, Car Setups, Car Telemetry. This should make the system more flexible and easier for us to support the different requests that come in. 
  • LopenskyLopensky Member Unleaded
    Just for example, this year i spent lots of time creating a live streaming app for positions and timings (and i wasn't the only one who did one.. there were others who did the same) and then codemasters came out with an integrated app with the eSports patch.

    The integrated spectator application it's nice and we are all happy for it, but of course since you knew you were working on that, you could have informed us lots before the patch so we could have avoided to waste time for something wich now became an absolutely useless thing.. :|
    Formula Italian Team - Driver & Staffer
    Formula Europe - Staffer

    F1 2018 Beta Tester

    Platform: PS4   -  Games: F1 2016, F1 2017, F1 2018, Assetto Corsa  -  Wheel: T300 GTE & G29
  • HooHoo Member, Codemasters admin
    I see your point. I'll have a talk with the team here and see if there is a better way to communicate our internal feature development for things like this. 
  • KafumantoKafumanto Member New Car Smell
    Hoo said:
    The main issue we had previously was that the packet size was nearing its maximum, so we were unable to add support for any extra feature requests. The intention is to break this info down into multiple smaller packets covering different things, e.g. Motion Data, Session Info, Lap Data, Session Events, Participant Info, Car Setups, Car Telemetry. This should make the system more flexible and easier for us to support the different requests that come in. 
    Slightly Mad Studios did the same for the new protocol of Project Cars 2 and it doesn't worked well, they are trying to fix it only now (http://forum.projectcarsgame.com/showthread.php?56963-PCARS2-UDP-API-Bug-reports&p=1476950&viewfull=1#post1476950). Splitting data across different packet types on UDP complicates a lot the reading client if it want/must reconstruct the stream of data. Clearly it's the only way if you have to share a lot of data, but please double check it :)
  • LopenskyLopensky Member Unleaded
    I think the best way it's to separate on different data pipes informations which are NOT connected, grouping packet data types for their purpouse and not only by concept.

    For example, there could be a single output stream for motion data, one for live timings, one for single driver "additional hud" (like additional external screens), and so on.. this way there will be no need  to keep packets "syncronized" at runtime  :)
    Formula Italian Team - Driver & Staffer
    Formula Europe - Staffer

    F1 2018 Beta Tester

    Platform: PS4   -  Games: F1 2016, F1 2017, F1 2018, Assetto Corsa  -  Wheel: T300 GTE & G29
  • KafumantoKafumanto Member New Car Smell
    But this is wrong if you capture real time telemetries ;) For example motion data and live timings must be synchronized, otherwise telemetry data are simply wrong. The protocol must let client to precisely reconstruct the original stream, with synchronization up to the game frame. Here for example the same problem with PCAR2: http://forum.projectcarsgame.com/showthread.php?56963-PCARS2-UDP-API-Bug-reports&p=1477022&viewfull=1#post1477022 
  • LopenskyLopensky Member Unleaded
    I can't see why Motion Data (as far as i know used to "drive" some kind of simulators) HAVE to be read in perfect synch with timings data.

    Maybe i am simply not understanding your point, but if you encapsule in every "packet type" all informations you need for a specific purpouse (examples: "drive" a simulator, additional screens, live streaming applications, data storages, etc..), then you just have to tell the game which packet type you want it to send and eventually where (why not, sending different types of packets to different UDP listeners).

    Formula Italian Team - Driver & Staffer
    Formula Europe - Staffer

    F1 2018 Beta Tester

    Platform: PS4   -  Games: F1 2016, F1 2017, F1 2018, Assetto Corsa  -  Wheel: T300 GTE & G29
  • cjorgens79cjorgens79 Member Unleaded
    Hoo said:
    The main issue we had previously was that the packet size was nearing its maximum, so we were unable to add support for any extra feature requests. The intention is to break this info down into multiple smaller packets covering different things, e.g. Motion Data, Session Info, Lap Data, Session Events, Participant Info, Car Setups, Car Telemetry. This should make the system more flexible and easier for us to support the different requests that come in. 
    Rather than split them up into multiple separate network packets (which would increase load on the wifi networks they are being sent on, especially in broadcast mode), another option may be to alternate the packets being sent. All the data that needs to be high resolution would be included in each packet, with the alternating part of it containing other information that doesn't need to be updated as often. So as a very basic example, something like speed and rpm would need to be included with every packet, however other things like session time remaining, tyre wear, tyre pressures etc could be in alternating packets. So you would have a structure which has all the 'real time' fields (ie motion data, vehicle data), followed by a variable sub packet type indicating what data is contained in the remainder of the packet for this particular tick (eg timing data, session data etc). You would then just rotate between those sub packets for each tick. Obviously careful thought would need to go into what data needs to be real time and what data can happily be sent only every 2nd or 3rd or 4th etc (depending on how many subpackets are required).

    You could also save a heap of space in the existing structure by using more efficient data types for some of the fields. For example, num laps doesn't need to be a float (4 bytes), a single byte will be sufficient. There are also a number of bool (or 3 state) values which are floats, they could easily be packed into smaller data types to save space. 

    Hopefully the reworking of the telemetry will address the fundamental flaw in the current design with the telemetry stream stopping (in single player) as soon as the player finishes as it makes it impossible to get accurate race results in those situations for any driver that finished after the player.

    The biggest space consumer in telemetry in general (across alot of racing sims) in strings. In the F1 series of games, you have an advantage in that you can use a fixed track id, car/team id as they don't change and are somewhat limited in their quantity so strings haven't been needed up to this point. However if you do intend to supply driver names for multiplayer, then obviously this will start to consume a fair chunk of the telemetry space. It is critical to keep the player names in sync with the timing data for that player, this is one area that was particularly problematic with the PCARS1 UDP interface, as the string packets were split and there were no unique ID's for drivers, so if a player left a MP session the timing data would get rearranged in its slots, but you wouldnt necessarily have the updated player names yet which meant the data could now be interpreted as from the wrong driver. The PCARS2 UDP structure which is even more split up attempts to address this by having a unique driver id key which is supplied with both the timing and strings data so they can be married up correctly. If planned out properly, i think it should be possible to fit the timing data all in the subpacket idea without having to split it up, you also have the advantage of only needing to support 20 players, where as PCARS2 technically handles up to 64 which is harder to deal with in the available telemetry space.

    Anyway, enough rambling from me. If you want any assistance or feedback on potential implementation ideas, please let me know as i've had a fair bit of experience with this stuff over the last 5 years.
  • LopenskyLopensky Member Unleaded
    As i said a possible solution would be to enable packet type specific abilitiation so users can activate only those packets they want, rather than all or nothing. :)
    Formula Italian Team - Driver & Staffer
    Formula Europe - Staffer

    F1 2018 Beta Tester

    Platform: PS4   -  Games: F1 2016, F1 2017, F1 2018, Assetto Corsa  -  Wheel: T300 GTE & G29
Sign In or Register to comment.