Interfacing the PS4 console (not the controller)

Daestrum said:
@Cableguy if you need help deciphering the packet data give me a shout :)
Click to expand...
I most certainly will... I think of starting fiddling with this tomorrow...
I will keep you posted
 
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.
 
avalle said:
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.
Click to expand...
Thanks...
From your experience, would a wemos D1 be powerful enough for the job?
(Retrieving packets, parsing them, send to Newton display)
 
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.
 
And sorry what is the Newton display?
Not this one, I'm assuming...
1612170418268.png
 
Last edited:
avalle said:
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.
Click to expand...
From what I could read I think the max data outbound rate will be 4 per second...
 
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.
 
avalle said:
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.
Click to expand...
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
 
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.
 
avalle said:
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.
Click to expand...
Thanks for the suggestion, I will do that...
I will report, maybe in a couple of days...
 
OK, so...

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

1612181699849.png


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...
 
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.
 
avalle said:
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.
Click to expand...
I will try my best...
Can you post one example of how would such a function look like?
 
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 www.b4x.com

Hope it helps
 
avalle said:
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 www.b4x.com

Hope it helps
Click to expand...
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...
 
convert uint8 to short - effectively an unsigned byte

Code: 
Sub Uint8(b As Byte) As Short
    Return Bit.And(0xff,b)
End Sub
 
The packet Cableguy is interested with is the following:

[CODE lang="c" title="Car Telemetry Packet"]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
};[/CODE]

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.
 
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.
 
you also need byte 22 to get 'your' car in the data array that follows
 
You must log in or register to reply here.
Back
Top