MotoGP18 real time telemetry

[D4rw1n]

Hi!
Is there any plan to get a real time telemetry data from MotoGP18?

If not, would that be a technical constraint (i.e. MotoGP not streaming data in real time) or just a decision from Sim Racing Telemetry developers?

Thanks in advance.

[D4rw1n]

+ according to your official website (https://www.simracingtelemetry.com/help/MOTOGP18/):

"The game will send useful telemetry data only while you are driving in a timed lap (no data are recorded during out-laps). SRT stores only complete timed laps (incomplete laps are discarded), so ensure to finish your timed laps."

Hence my question from initial post, as I'm not sure how to understand following statements:

"SRT stores only complete timed laps" -> does that mean it *is* technically possible for you to store telemetry data during an out-lap (like leaving the pit lane to the track)?

I would expect some data like lean angle, RPMs, speed, etc should be available anytime, whilst lap time wouldn't be available unless you are on the track and pass the line at least one time to start the chrono.

[UNAmedia]

Hi, thanks for asking! Here a slightly long and - unfortunately - technical answer, I'll try to keep it simple.

MotoGP 18 sends telemetry data in real-time, but SRT - at the moment - doesn't support the real-time reconstruction of the telemetry stream (needed for analysis, charts, etc.). We would like to add this feature in the future.

Data received from the UDP network protocols (the one used by MotoGP 18 for example) are usually quite "dirt": packets arrive in unspecified order and some packets can go lost. So we have to reorder them and fill the missing ones later, this adds a first layer of "delay" in data processing.
In addition, data received are not directly suitable for telemetry output: telemetry data must be mapped against distances on track, but the data we receive have a lot of "holes" (e.g. one sample received from the game could be about distance 1000m and the next received sample about distance 1040m - we have to extrapolate all the missing data from 1001m to 1039m). We have a relatively complex algorithm that "fills the missing holes", reconstructing a proper telemetry stream for every distance on track. Unfortunately, at the moment, this algorithm can't operate in real-time while receiving data.

We have this feature in our TODO list, as it's very important during eSports competitions. Unfortunately it's a complex task, so at the moment we don't have an ETA for it.

About the documentation: the game doesn't send always useful data, and SRT must discard any data that is not about a valid timed lap. This mostly to avoid ambiguous situations. In addition, if a timed lap contains only partial data (e.g. because you aborted the lap), SRT - at the moment - discards this lap. In the future we would like to preserve these laps, but it heavily depends on what data the games share to track correctly the gaming session (e.g to manage re-starts etc, often we have to use custom heuristics to detect them correctly).

Sorry for the long and maybe obscure answer. I hope it could help.

[D4rw1n]

Thank you very much for taking time to answer with so many details to my questions!

So because it's UDP based, i.e. best effort order, I would have indeed expected some misordered packets in the end, and therefore a need for some buffer, even for "real" time telemetry.

Do you mean as well that you really have some "absence" of data randomly during the lap?
Like .. even after re-ordering everything over 5 seconds, there would still be some unknown holes?

If that is the case, that's very disappointing and I'd be curious to know more from Milestone developers why this is happening. Have you already got some clarification from their side?

I understand why UDP is chosen here, but at the same time I would expect some minimal ordering data into UDP payload (e.g. incremental integer value), to avoid the need of creating a dedicated algorithm literally guessing missing data, like you had to do.

My interest for such real time data is because I'm in a project of creating a physical motorcycle simulator to reflect in a best possible way the physics of a motorcycle game.

So far so good, only GP Bikes seems to provide officially to anyone such thing, with open access to DLL and typedef struct definitions provided by its only developer (Piboso).

Seeing telemetry data existence for MotoGP18 has been a good surprise for me, but without a minimal consistency of the UDP stream, I couldn't consider the game compatible with my expectations.

Some other questions:

- What is the rate/frequency of the telemetry sent by UDP? Is is consistent?
- Can you change that rate?
- Are these loss of data happening even on a localhost network, without a real physical layer in between the game and your software?
- Have you tried to use cheatengine or memory hook techniques to cross check UDP telemetry data against the ones from cheatengine for exemple?


Thank you very much in advance !

[UNAmedia]

Hi!

I didn't checked, but MotoGP18 should send data at quite high frequency (it should be 60 packets per second - in "sync" with the main game loop). The communication protocol has been developed in partnership with Milestone, so it has everything we need to rebuild the telemetry stream (e.g. information to properly reorder received packets). And UDP has been chosen to be able to support also the consoles (PS4, Xbox One), where shared memory is not available.

Packets loss and/or wrong ordering is something related to generic networking with UDP packets (so not MotoGP18 related): it happens infrequently on local wired network, it happens with a few % of packets with local wireless networks, and it happens quite frequently with Internet connections. Our algorithm has been developed to manage the "worst case" and this is partially the cause we can't show telemetry in real-time actually; but as said, we would like to improve it.

About the reconstruction of the telemetry stream, "holes" can happen for two reasons: packets loss due network communication, realtime sampling of data. While the first is clear, the second could need some explanation: also in real telemetry, data is sampled at +/- fixed intervals, with a vehicle moving at 300 kph ( = 83.3 meters/sec) with a sampling frequency of 60 Hz, between two samples the vehicle could have moved 1.38 meters. Games often send data with lower frequency (e.g. 20 Hz) and packets can be lost, causing the vehicle to appear at greater distance (is not infrequent to have samples with distances of 5-10 meters between them). To manage this, we have developed a relatively complex algorithm that "fills the holes" in a discrete representation of the track, with different algorithms for each type of telemetry parameter (eg: "gears" can't be interpolated, while "fuel" could; radial parameters must be interpolated with special formulas, the same for vectors where their modulus has a particular meaning; etc). In addition there are games that allows the user to "travel backward in time" (e.g. the F1 series), that add a lot of further complexity to this algorithm. This is the second reason we can't, at the moment, show telemetry in real-time.

Cheers!

[PCDOK2R3N]

Hello UNAMedia

Theresia something I Din't understand, because I also own (beside Your program SRT)
a lFULL license for the Android App 'SimDashboard' where MotoGP18 recently also became available..

And in the SimDashboard App I can get a lot of REAL-Time information show in the Dashboard (that is customizeable)..

So WHY do You claim that You can't do the same..???

[D4rw1n]

Thanks for the further explanations UNAmedia.

For interpolation algorithm, I'm guessing your algorithm is using some PID loops somewhere to smooth and "guess" the intermediate parts, isn't it (of course, it's not only about PID loop, as you have already explained very well).

Because my simulator would be connected directly by wire (UTP) to the gaming device (PC), I would not be worried that much about the loss of packet due to network media.

For the ~60hz frequency & sampling related issues with the equivalent distance, in my case that means I would need to smooth the input into the simulator from the host or maybe the simulator would handle such thing itself (using PID to smooth data such lean angle, RPMs, G force, etc).

I appreciate a lot you took time to detail your answer! :)

[UNAmedia]

@d4rw1n a pleasure :)

@PCDOK2R3N SimDashboard is a dashboard, while SRT is a telemetry analysis application. They manage the data in a completely different way: a dashboard shows you the last available data, ignoring lost or unordered packets (and often ignoring all previous data); while for a telemetry analysis application this is not possible, to make analysis we need a correctly ordered stream of all data without any holes. In the previous 2 posts it's explained why we can't show telemetry in real time at the moment.