Performance problem with FSUIPC and/or FSUIPC CLient.DLL

[drnicolas]

Just as the meteorological autumn has started, I begin to think about my Simulator-project again for the winter.

My question goes to Pete Dowson and/ or the developer of the FSUIPC Client DLL.

Let me first explain my goal:

I am building my own small cockpit with mechanical instruments.

For this, I have a program running on the FSX-PC which reads or writes airspeed, heading, bank pitch and many other values from or to the simulator and also sends data to or from the mechanical panel. On the mechanical panel, those values are displayed as pointer positions using R/C-servos.

The PC program uses the combination of FSUIPC and FSUIPC client.DLL

For servicing i have a program where I can test the instruments moving some slider controls with the mouse. There, the positioning of the pointers works very well - smooth and quick movements. I assume, the panel and the underlying software works fine.

In the real simulation process it is different:

The pointers do not move smooth but in steps. At first, I thought I have to increase the update frequency from 5/s to something higher.

But it diesn't really help..

So my question is: Is there a general limitation of the update frequency in either FSUIPC or FSUIPC client DLL ?

[Pete Dowson]

So my question is: Is there a general limitation of the update frequency in either FSUIPC or FSUIPC client DLL ?

I've no idea what FSUIPC client DLL does, so I'm afraid you'll need to await an answer separately for that, but FSUIPC's data is updated when it changes. It receives changes (only) from SimConnect. It is asynchronous, though, because of the way SimConnect works (unlike how FSUIPC got data in FS9 and before, where FSUIPC grabbed it specifically on each frame, i.e. synchronously).

The main determining factor on update rates will be FSX performance -- its frame rates. Really you should be reading the data at the FS frame rate, so limit the frame rate in FSX (eg to 25 fps) and read the data at matching intervals (e.g. 40 mSecs in this case).

Note that FSX SP2/Acceleration is much more efficient in keeping to frame rates than the unpatched FSX or FSX+SP1 because of the way SimConnect changed its mechanisms for in-process clients -- before SP2 it still used TCP/IP protocols for this.

The way your program, and this DLL you are using, is written will also determine what results you get. Each time data is requested (the "FSUIPC_Process" call to FSUIPC) there's a message placed on FSX's queue, and your own process is held up till that is processed and a response is made. if your program is resulting in many process calls per cycle, that will make it extremely inefficient. All of the data you need, per cycle, should be requested in one call, once per cycle. I suspect you are not doing this -- this bad programming practice is the usual reason for poorly performing programs.

Finally, note that even at relatively good frame rates, larger (than the FS panel ones) and more realistic gauges can often still be observed to "step" unless you apply some smoothing in your own program. In other words interpolate or extrapolate between steps and keep the needles or whatever moving when they should be.

Regards

Pete

[drnicolas]

It seems, that I have to write some simple testing programs to find the reason for the problems.

[Pete Dowson]

It seems, that I have to write some simple testing programs to find the reason for the problems.

Are you sure your program is getting enough processor time to actually run frequently enough? FSX is very processor intensive -- it will use 100% of one core, easily. If you are using a 2 or 4 core PC you might want to make sure FSX is using a different one to you. Try using the Affinitymask parameter in FSX.CFG to stop it using core 0, i.e.

{JOBSCHEDULER]

Affinitymask=14

for a 4-core processor, but use =2 for a 2 core one.

Regards

Pete

[Paul Henty]

There's nothing in my DLL that will add any delay or jerkyness to the data. The exchange of data between the DLL and FSUIPC follows exactly the C SDK and is mostly done with unmanaged code.

I think Pete is right about the need for interpolation code. Many years ago I did some work on an external panel that I wrote in DirectX. It too was visibly 'stepping' until I added some smoothing code to it. The problem you've got is that the values from FS only come at a fixed interval which is generally not small enough to make a gauge look really smooth. You need to update the gauge state more often than you get the data back. That way you can fill in the gaps between the data points making your gauge look smooth.

Paul