Interfacing the PS4 console (not the controller)

[Cableguy]

@Cableguy if you need help deciphering the packet data give me a shout

I most certainly will... I think of starting fiddling with this tomorrow...
I will keep you posted

 

[avalle]

I can help with UDP with ESPxxx. I've made multiple home devices based on that. It's not that hard.
Send me the info on the F1 UDP specs and I'll share some baseline UDP code.

 

[Cableguy]

I can help with UDP with ESPxxx. I've made multiple home devices based on that. It's not that hard.
Send me the info on the F1 UDP specs and I'll share some baseline UDP code.

Thanks...
From your experience, would a wemos D1 be powerful enough for the job?
(Retrieving packets, parsing them, send to Newton display)

 

[avalle]

It depends on the volume of data. I'm assuming yes because I don't think they're flooding the bandwidth with a massive data rate.
The main goal of using UDP is that it's a one way data protocol, so no guarantee of data integrity, but you get the bonus of high speed and low resource demand.

 

[avalle]

And sorry what is the Newton display?
Not this one, I'm assuming...

 

[Cableguy]

And sorry what is the Newton display?
Not this one, I'm assuming...
View attachment 107225

Sorry, t9 auto-corrected it....
I plan to interface with a NEXTION display

 

[Cableguy]

It depends on the volume of data. I'm assuming yes because I don't think they're flooding the bandwidth with a massive data rate.
The main goal of using UDP is that it's a one way data protocol, so no guarantee of data integrity, but you get the bonus of high speed and low resource demand.

From what I could read I think the max data outbound rate will be 4 per second...

 

[avalle]

Think of UDP as a stream of data. So 4 per second is not that much, but it depends on how big is each message. You can transfer up to about 65000 bytes with a single UDP datagram.
I had a quick look at the F1 2020 UDP specs (assuming this is the right source: https://forums.codemasters.com/topic/50942-f1-2020-udp-specification/) and the amount of data really seems to change based on which information is transferred.
For example I'm not sure if all data is always sent, if you can configure the game to send out only some data instead of everything, etc.

 

[Cableguy]

Think of UDP as a stream of data. So 4 per second is not that much, but it depends on how big is each message. You can transfer up to about 65000 bytes with a single UDP datagram.
I had a quick look at the F1 2020 UDP specs (assuming this is the right source: https://forums.codemasters.com/topic/50942-f1-2020-udp-specification/) and the amount of data really seems to change based on which information is transferred.
For example I'm not sure if all data is always sent, if you can configure the game to send out only some data instead of everything, etc.

I will try to dig a bit into this... I think you are correct about the data packages changing...
The ones I'm interested in, at least for now, are telemetry... like speed, rpm, brake temp, turbo pressure et...
I'm not into gaming but I do like the idea of bringing out to the real world a virtual scene

 

[avalle]

For car telemetry I see that packet size is 1307 bytes and frequency rate is as specified in menus.
This is affordable for the ESP8266, but it also depends on the amount of the other packets that are sent at the same time.
Not sure if all data are sent to the same UDP port. If so, then you'll have to receive everything and filter only the packets you're interested with.

I'd suggest you first start with a B4J application running on a PC to make sure you can receive and process the packets properly with enough computing power and networking bandwidth. Then you move the code to the ESP to detect resource issues more easily.

I don't have that game so I can't really help with testing, but this sounds like a fascinating world.

 

[Cableguy]

For car telemetry I see that packet size is 1307 bytes and frequency rate is as specified in menus.
This is affordable for the ESP8266, but it also depends on the amount of the other packets that are sent at the same time.
Not sure if all data are sent to the same UDP port. If so, then you'll have to receive everything and filter only the packets you're interested with.

I'd suggest you first start with a B4J application running on a PC to make sure you can receive and process the packets properly with enough computing power and networking bandwidth. Then you move the code to the ESP to detect resource issues more easily.

I don't have that game so I can't really help with testing, but this sounds like a fascinating world.

Thanks for the suggestion, I will do that...
I will report, maybe in a couple of days...

 

[Cableguy]

OK, so...

Due to some very bad weather today, I decided to come home earlier from work, and picked up a small UDP example...

I post a screen simply because copy/paste the Logs does not show these logs correctly...
This is comming from the game to my PC.
So I guess I can at least get an idea of what I am looking for...

 

[avalle]

Great to see your progress. As you see it's not that difficult, the most complex part is filtering and parsing the telemetry packets.
You have to write a couple of functions to decode the data types correctly (e.g. uint8, uint16, uint32, float) and then deal with the data accordingly.

 

[Cableguy]

Great to see your progress. As you see it's not that difficult, the most complex part is filtering and parsing the telemetry packets.
You have to write a couple of functions to decode the data types correctly (e.g. uint8, uint16, uint32, float) and then deal with the data accordingly.

I will try my best...
Can you post one example of how would such a function look like?

 

[avalle]

Honestly so far I've only worked with strings or simple streams of bytes, so I have not much code to share.
I'd approach this by defining a custom Type equivalent to the telemetry packet, then you read it with the serializator function.

See this as an example:

[B4X] B4RSerializator - Send and receive objects instead of bytes

B4R v1.50 includes a new type named B4RSerializator (in rRandomAccessFile library). B4RSerializator solves a difficult and common task. Sending messages with multiple fields to other platforms. B4RSerializator takes an array of objects with numbers, strings and arrays of bytes and returns an...

www.b4x.com

Hope it helps

 

[Cableguy]

Honestly so far I've only worked with strings or simple streams of bytes, so I have not much code to share.
I'd approach this by defining a custom Type equivalent to the telemetry packet, then you read it with the serializator function.

See this as an example:

[B4X] B4RSerializator - Send and receive objects instead of bytes

B4R v1.50 includes a new type named B4RSerializator (in rRandomAccessFile library). B4RSerializator solves a difficult and common task. Sending messages with multiple fields to other platforms. B4RSerializator takes an array of objects with numbers, strings and arrays of bytes and returns an...

www.b4x.com

Hope it helps

I had thought of creating a type for easier handling...
Will see how it goes in a few hours.. now it's time for essential shopping...

 

[Daestrum]

convert uint8 to short - effectively an unsigned byte

Sub Uint8(b As Byte) As Short
    Return Bit.And(0xff,b)
End Sub

 

[avalle]

The packet Cableguy is interested with is the following:

struct CarTelemetryData
{
    uint16    m_speed;                         // Speed of car in kilometres per hour
    float     m_throttle;                      // Amount of throttle applied (0.0 to 1.0)
    float     m_steer;                         // Steering (-1.0 (full lock left) to 1.0 (full lock right))
    float     m_brake;                         // Amount of brake applied (0.0 to 1.0)
    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)
    uint8     m_tyresSurfaceTemperature[4];    // Tyres surface temperature (celsius)
    uint8     m_tyresInnerTemperature[4];      // Tyres inner temperature (celsius)
    uint16    m_engineTemperature;             // Engine temperature (celsius)
    float     m_tyresPressure[4];              // Tyres pressure (PSI)
    uint8     m_surfaceType[4];                // Driving surface, see appendices
};

struct PacketCarTelemetryData
{
    PacketHeader        m_header;           // Header

    CarTelemetryData    m_carTelemetryData[22];

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

    // Added in Beta 3:
    uint8               m_mfdPanelIndex;       // Index of MFD panel open - 255 = MFD closed
                                               // Single player, race – 0 = Car setup, 1 = Pits
                                               // 2 = Damage, 3 =  Engine, 4 = Temperatures
                                               // May vary depending on game mode
    uint8               m_mfdPanelIndexSecondaryPlayer;   // See above
    int8                m_suggestedGear;       // Suggested gear for the player (1-8)
                                               // 0 if no gear suggested
};

So my suggestion was to create a custom type for PacketCarTelemetryData and then to serialize the buffer of Bytes to the specific types and values.
That should make reading the values out of a packet more affordable.

 

[Daestrum]

byte 5 of the packet you get will tell you the type of data - you only need byte 5 to be a 6 for telemetry data packet, you could ignore any others.

 

[Daestrum]

you also need byte 22 to get 'your' car in the data array that follows