FlyPT Mover

sallerding Thanks. It is not allowing me to do that. The problem seems to be in the telemetry option as it is not sending telemetry to mover and so the yellow connect button will not stay lit. If I boot NL2 to the menu screen I can get it to work by doing a Control - Alt - Delete and selecting task manager. This allows me to get to the desktop and click the connect button on mover. It is a work around. Fortunately I do not play NL2 that much. Most of the time I am in FS2020.

Sorry if this has been asked before, but I couldn't find anything searching on google.

I'm a bit confused regarding "Calculation rate" and its relation with the sampling frequency of the raw telemetry data.

Say for example that my game pushes telemetry data at 100Hz.
Is there a point then to have calculation rate anything lower than 10ms ?

In this case, what happens when I set the calculation rate to 1ms ?
Is there some upsampling happening somewhere on the original data ?
How does this impact the window upon which the filters act ?

Having experimented with it, I am quite confused: lowering the calculation rate (i.e. faster) seems to increase the overall gain of the system, and increasing the calculation rate (i.e. slower) seems to muddy everything.

I have experimented this on iRacing (which I think FlyPT is acquiring telemetry at 60Hz, but I can't be sure, as iRacing also allows for 360Hz telemetry with a delay of 16.6ms).

Sorry

Sorry. I’m Out of options . Only other option is to delete and then reinsert your telemetry launch options into steam….but you’ve probably already tried that.

From what i recall, iRacing has 360Hz, but not for all the data. Mover uses 60Hz.

You can change the rate in Mover, but this affects the filters behaviour.
In my opinion, you should keep the 2ms just because almost everyone is at 2ms and it will be easier to share setups and any comment about filters presumes you are using that frequency.
Most of the filters are sample based, not time, so the results are different if you change the frequency.
Also, even if the game send at 10ms, using 2ms gives you more resolution on the filter output:



The squared line is LFS data at 10ms, the smoother one is a filter over the same data at 2ms, "erasing" the square effect of the curve and giving you more resolution.
But this is just guidelines, Mover allows you to experiment.


EDIT:
The muddy effect happens in low pass filters, because passing from 2ms to 1ms is like apllying the low pass 2 times to the same data. EMA filters are sample based, producing that effect when you change the rate.

Hi,

Mover noob here, hence the question: is 60Hz the fixed frequency at which Mover is acquiring telemetry data, regardless of the frequency that the games uses for telemetry output?

By the way, do you know at what rate/frequency DCS outputs telemetry data?


Cheers,
DK

So calculation rate basically upsamples the original data to achieve the target frequency ?

So an original signal of 100Hz would be resampled @ 1Khz if calculation rate is 1ms, and the values would just be copied ?

I think that will introduce significant high frequency artefacts as each "edge" will be a high frequency impulse ?

Regarding iRacing, is there a way I could contribute a 360Hz version to mover?

Like loosing telemetry data, making the source go yellow?

DCS, not sure, need to check. The new release of Mover indicates the frequency at wich the game is sending data.

Mover gets data at the selected frequency, but the data is updated at the frequency the games sends it.
So if Mover is at 2ms and data at 10ms, Mover readsthe same value 5 times. So the filters use the same value 5 times.
There's some nuances:
In UDP, data packest are read when received, so data is updated at that frequency.
For shared memory, data is updated if there's changes, and Mover checks for chages in the data at Mover frequency.
If you have Mover at 10ms and data is at 5ms, you are going to loose some shared memory updates.

I did not update the iRacing source yet, but frequency will show like you see in the LFS source:



100Hz
This is a UDP source. In the Shared Memory:



We can use a dedicated thread to get data at the frequency of the game instead of Mover frequency.

This is all dependent on how we get data and how we check if the received data is new.

For iRacing, I can make it next, but getting it at 360 is no problem, unless something changed recentlly.

Thanks for your quick reply!

Unfortunately we're mixing units here, which makes it hard for a noob like me to follow.

1. You previously wrote Mover uses 60Hz, which equals intervals of approx. 17ms. For which process does Mover use these 60Hz? My understanding: this is only input data sampling, no matter how often the games sends data? So if game sends at 120Hz, Mover samples at 60Hz, so Mover is losing data here?

2. When you write

I'm assuming you mean: the internal calculation interval for Mover is 2ms, which equals 500Hz. The game's data output interval is 10ms, which equals 100Hz. But how does that work out with the 60Hz you mentioned above?

3.

What do you mean by "Mover at 10ms" - do you mean if I set calculation interval in "Options" to 10ms, instead of default 2ms?


Clarification would be much appreciated!
Thanks.

The iRacing 360Hz is a bit of a weird thing...

The MMF data is updated @ 60Hz, but each sample contains 6 points.
So the data is effectively delayed 16.6ms.

Let me know if I can help!
I would be glad to write out a Source DLL if you provide me an interface I can implement.

I don't have an interface for plugins right now (for Mover 4))
I messed it with other games.
I just took a look at the code I have in Mover, you have for example VertAccel_ST that contains 6 floats.
So you get at 60hz 6 values and that makes the 360hz. Problem is like you say, the oldest of those values get's a big delay.
Only values with ST have that, and we are talking about accelerations, velocities, steering wheel, shocks deflection and shocks velocity.

Maybe I did not understand how that data is updated.
Resuming and correct me if I'm wrong: Data is updated at 60 hz, but with an history of 6 values since last update making it the proclamed 360hz (with the resulting delay).

@DerKlausi

Ok, from scratch:

User interface in Mover works at the same frequency of Windows (usually 60Hz) unless the load is too high slowing it down.
The load increases with more Modules, and some are heavy in visuals.

Mover calculation thread uses an interval of 2ms by default, or 500Hz and is independent from the UI.
This means all calculations (including filters) are performed at that frequency. You can use 1ms or less in the high precision increasing the frequency or lowering (change it in options).


To output data I allow the user to say how many calculations exists between each output ()Interval loops). So if we use 2ms and we specify 5 calculations, the output is sent at 10ms or 100Hz.
So at 5 calculations 4 are discarded and not sent to the hardware.


Now the sources, your main question:
We receive data at the frequency the games send it. We get all the packets sent by the game in a dedicated thread.
Each time a packet is received, the data in Mover is updated.
Meanwhile the calculation is running and reads the stored data in Mover.
If the frequency of Mover is lower than the game frequency, you might loose some packets, but I don't know any game sending at more than 500 Hz.
Since the calulation uses an higher frequency, it uses the same value in multiple calculations.
For example game sends at 60Hz, Mover works at 500Hz, the same value is used around 8 times.
There's no interpolation in the received values. If you want to, you can use a filter to smooth and generate the interpolation.

There's many internal details that change with each game, like timers, identify new packets or calculate some values from others...
That's another problem.

Ok, would be great to be able to develop our own sources as well, for example if we want to mix in other peripherals. There is the custom UDP hook, but documentation is missing I think. From what I understand, we could use the UDP hook to update data at any frequency we want ?

That is correct.

Very clear, thank you so much!

Again, thank you for all your work.
I had already donated (a while back) and am looking to donate more in the future .

Thanks a lot for the detailed explanation!

So if I wanted to change the calculation interval from default 2ms to let's say 1ms, I would just have to multiply parameter2 (number of samples) for all filters by 2 and maybe adjust the number of output interval loops?


Cheers,
DK

Yes, but not sure the result is exactlly the same. If the data is at the same rate, yes, but filter hover another filter, not sure.
Let's say a value goes from 2 to 10 in a space of 10ms.
First filter is getting the same data, but another filter on the filter is going to use an "interpolated" value that might be different with another rate.

Ok I see, thanks. Maybe I'm gonna try, or maybe even "simulate" it statically via a calculation sheet beforehand.

Thanks for replying.
Does this MMF data stream "directly" feed a virtual tracker for OVRMC? Or do you have another idea for motion compensation?

I think my ultimate goal is to have my encoder data feed mover since I only want the yaw axis encoded while pitch roll and heave are compensated via mover. I'm open minded to something better though.

What I am doing now is either:
Joystick axis from arduino->FlyPT Mover->MMF to MC
Com port from Arduino->Opentrack via UDP->FlyPT Mover->MMF to MC

My future goal is:
Com port from Arduino->Custom software->MMF to MC

hello, you managed to use Flypt move and simttols, can you help me to configure it and how is the configuration in simtools

Before I buy it. Does FlyPt Mover work with Forza Horizon 5? I see it has horizon 4 listed. But not sure if that also supports 5