FSUIPC Throughput

[Doug Moldenhauer]

Pete, I was wondering what kind of throughput I might expect to get from FSUIPC. I've been writting a autopilot that is a external program that receives and sends data to FSX via FSUIPC.

I havn't done any real timing checks but it seems that the polling routine and PID routines currently run at around 10hz. If I disable the PID routines and leave the data reads and writes to FSX, the frequency stays about the same.

The values I'm currently reading and writing to:

offset size Description Direction

0570 8 Altitude, in metres and fractional metres Read

0578 4 Pitch, *360/(65536*65536) for degrees. Read

02C8 4 Vertical speed, signed, as 256 * metres/sec. Read

0BC0 2 Elevator trim control input: –16383 to +16383 Write

02BC 4 IAS: Indicated Air Speed, as knots * 128 Read

088C 2 Engine 1 Throttle lever, –4096 to +16384 Write

0924 2 Engine 2 Throttle lever, –4096 to +16384 Write

310A 1 Controls the joystick connection Write

I was wondering what the most efficient way to read/write this data is and what kind of throughput I might expect in a continuous polling situation? It sure would help if it was just a contiguous block of data, but my registers are all over

the place so that doesn't seem possible.

The Speed Regulator PID is nailed right on at the moment with its current configuration. The Altitude, Vertical Speed, and the Pitch PID regulators are working pretty well, however I'd like to Increase the Gains, but they tend to get a bit nervous when I get the gains much higher. I expect this is due to the lack of bandwidth. I'd like to increase PID update bandwidth if possible.

My current system is a Core2 Duo E8500 with 3Gig Memory and a Nvidia 9600GT 512mb Video Board. That should have enough horsepower to handle this with no problems. Perhaps I'm not doing the read/writes in the most efficient manner or have not configured correctly. I'm using the MFC version of your FSUIPC 4.40 SDK

Any Suggestions or Ideas would be greatly appreciated

Doug M

[Pete Dowson]

Pete, I was wondering what kind of throughput I might expect to get from FSUIPC. I've been writting a autopilot that is a external program that receives and sends data to FSX via FSUIPC.

No idea, but I run a cockpit with 10 PCs. The autopilot is on one WideFs client, PFD/ND displays for Pilot and Copilot are maintained on two others, the EICAS screen and Radar Contact menu are maintained on another, there are 2 PCs running the CDU/FMS, a main ancillary PC running Active Sky, Radar Contact, pmsystems and assorted other FSUIPC clients, a moving map (Jeppesen FliteMap) on another, and so on. There are also a couple of FSUIPC clients on the FS PC itslef, and with all that going on there's little measurable impact at all on FS.

I havn't done any real timing checks but it seems that the polling routine and PID routines currently run at around 10hz. If I disable the PID routines and leave the data reads and writes to FSX, the frequency stays about the same.

No idea what you mean by "PID", but surely your polling should be at the frequency YOU choose, not some random affair. Aren't you regulating it?

The data you are reading or writing is pretty irrelevant unless it is extreme. Try FSInterrogate, for example. Run it on the same PC as FS, in Windowed mode. If you select ALL of the values, the whole lot, and tell it to repeatedly read them, it will probably achieve 10Hz with no real problem -- but observe what happens to FS frame rates caused by the intense activity in FSInterrogate! Ugh. But that's nothing to do with what is happening in FSUIPC, that is to do with how much processor time is being stolen from FS to run FSInterrogate. Actually, for a multi-core PC, the bottleneck there is probably the screen drivers.

I was wondering what the most efficient way to read/write this data is and what kind of throughput I might expect in a continuous polling situation?

You should be polling at the frame rate. The data won't change faster than that in any case (well, mostly). set FS's frame rate to, say, 25, then poll once every 40 mSecs. You can go higher, depending on your system, but you should be choosing, not letting it loop with no governor.

Make sure you relinquish the processor whilst you are waiting, of course.

It sure would help if it was just a contiguous block of data, but my registers are all over

the place so that doesn't seem possible.

It wouldn't make much difference really. It's the FSUIPC_Process call which takes the time. Do only one per cycle -- e.g. one per 40 mSecs. The individual Reads and Writes merely add data to a structure, all in your program. On WideFS, if you were to run your program over a Network, only the Writes actually do anything once the Server knows which data you are reading -- it supplies the latter automatically then, only when it changes.

The Speed Regulator PID is nailed right on at the moment with its current configuration. The Altitude, Vertical Speed, and the Pitch PID regulators are working pretty well, however I'd like to Increase the Gains, but they tend to get a bit nervous when I get the gains much higher. I expect this is due to the lack of bandwidth. I'd like to increase PID update bandwidth if possible.

Sorry, that's all gibberish to me. What's a PID anyway?

Regards

Pete

[Doug Moldenhauer]

Sorry, that's all gibberish to me. What's a PID anyway?

Sorry Pete.....The PID Controllers that I'm Speaking of that I wrote are for a AutoThrottle Speed Hold, Altitude, Vertical Speed, and Pitch.

A PID Controller is Proportional + Integral + Derrivative controller used to control a process to a requested Setpoint.

PID controller - Wikipedia http://www.google.com/url?sa=U&start=1&q=http://en.wikipedia.org/wiki/PID_controller&ei=USViSfzKIZyxmQfK4o27Dg&usg=AFQjCNHkUua2Nb9ou3vIFxhNYknTgfmxdA

The current method I'm using is via a Timer Callback Routine in Visual C++ 6.0. I'm running it every 20ms which should produce 50hz, but I'm not getting that as the routine is getting stalled somewhere inside and it appeared to be related to FSUIPC Communications. Perhaps I have something else bottleing the routine up. It would be interesting to check the throughput and bandwidth of FSUIPC....I'll have to put together a timer and polling routine to check it out.

Anyway, I've always hated the responce the stock Jet Aircraft Autopilots have in FSX. You also cant get at all of the tuning parameters for the different autopilot modes. This, I think is why the Payware Plane Developers write their own autopilots I think.

I Also wanted a "Level Change Mode" for a managed Altitude change which uses a fixed N1% (for a Climb, and limited to Flight Idle durring decents)and manages Pitch to maintain your set Speed to reach your new altitude. This allows you to set your new target altitude and your speed, and then press the Level Change Mode button and the Autopilot increases the throttle to produce a Climb N1% Setting (for a climb) and then will vary pitch to maintain your set speed. This produces variable climb rates dependant on your speed setpoint and aircraft loading

The real aircraft has this but is missing in the 737-800 Stock plane. The Stock Plane also doesn't have a FMC which I'd like to mess around with in the future.

[Pete Dowson]

The current method I'm using is via a Timer Callback Routine in Visual C++ 6.0. I'm running it every 20ms which should produce 50hz, but I'm not getting that as the routine is getting stalled somewhere inside and it appeared to be related to FSUIPC Communications. Perhaps I have something else bottleing the routine up.

You have only one FSUIPC_Process call per Timer call? That's important.

50 fps seems pretty high to attain as a normal mininum in FSX -- what clock speed is your Core2 Duo E8500 running at? I use 2 x QX9775's overclocked to 4.0 GHz, watercooled, with an nVidia GTX280 (or 9800GTX+, not sure which is best at present), and I set the limiter to 25, which i can attain most of the time, but not all -- Aerosoft Heathrow drags it down to 10-12. Don't you think you are letting FSX take so much of your system that your program simply isn't getting timers at 50 Hz in any case? Timer calls are low priority, you know. if you want strict timing you need to run a timing thread which sleeps for n mSecs and sends a message or calls a routine regularly.

You could also consider running your program on a client PC. You still need to regulate FSX, though.

It would be interesting to check the throughput and bandwidth of FSUIPC....I'll have to put together a timer and polling routine to check it out.

Have you tried other programs? FSInterrogate2 is useful for this, especially if you use the Quick Data Windows, as you should be able to build one up with exactly the same data set that you are reading, then vary its cycle time, exactly, using the slider provided for it.

FSUIPC itself doesn't take any time at all measurably on each request, excepting perhaps when it is asked, through a WRITE, to request FS to do something long like load a flight or change the time by more than a minute. But those times are taken by FS doing whatever it needs to do.

For FSX, FSUIPC reads are filled in from data which is arriving all the time, completely aysnchronously, from SimConnect. From the time FSUIPC receives the Message stating your requests, to the time it exits from that message, so allowing, theoretically, transfer of control back to you, all it is doing is reading the offsets and sizes from the table, as sent in the shared memory pointed to by the message, and doing memory copies from its own 65k offset data table into the shared memory. That never takes more than a millisecond, usually much much less.

On FS9 and before it was a little different because most data items were only read when requested, and this sometimes involved actually calling routines inside FS. On the other hand, many values were grabbed directly from known structures in memory -- so, in fact, very fast. Overall it probably balances out, though with the difference that the FS9 and before values tend to be real-time synchronous whereas the FSX values will be read asynchronously (by SimConnect) and only "pretend" to be synchronous from FSUIPC to the application. (WideFS is like the latter in any case, on all versions of FS).

The main time involved, when running on the same PC, is in the process changes (from you to FS and back), and the list of messages in FS's message queue awaiting attention before the one FSUIPC needs is forwarded to it. All that is done once per Process Call.

Once you start WRITING things via FSUIPC it changes of course, because the actions required to achieve whatever you ask varies. Many will be fast, some will not.

Anyway, I've always hated ...

I use Project Magenta, no FS panels, not the FS autopilot or any of its subsystems. I don't know of any serious cockpit builders using default aircraft. Many use PMDG aircraft -- i use the PMDG 737NG model and air file from FS9, but none of its panels or systems, all of which are replaced by Project Magenta modules.

Regards

Pete

[Doug Moldenhauer]

You have only one FSUIPC_Process call per Timer call? That's important.

50 fps seems pretty high to attain as a normal mininum in FSX -- what clock speed is your Core2 Duo E8500 running at? I use 2 x QX9775's overclocked to 4.0 GHz, watercooled, with an nVidia GTX280 (or 9800GTX+, not sure which is best at present), and I set the limiter to 25, which i can attain most of the time, but not all -- Aerosoft Heathrow drags it down to 10-12. Don't you think you are letting FSX take so much of your system that your program simply isn't getting timers at 50 Hz in any case? Timer calls are low priority, you know. if you want strict timing you need to run a timing thread which sleeps for n mSecs and sends a message or calls a routine regularly.

Thanks for the insights Pete. I think I may have more than one process call in the routine. I'll have to correct that. As far as the timing is concerned, a year ago or so I wrote some stuff for a home built Autopilot MCP panel that I created from a

microcontroller. I exchanged data back and forth with the MCP via USB Communications. I had multiple threads that handled the data. I believe I used to sleep the thread for a specified time, then continue processing, and then rinse and repeat. I'll have to create a new thread for this and give that a shot when I get home from work.

I hadn't concidered that the data was updated based on screen rate FPS. I run mine locked at 30 and it maintains that almost

everywhere with the stock scenery. I have most everything set up on high, but I have the Traffic turned down. NYC JFK airport does drop my FPS a bit when I'm at the airport and there is alot of parked aircraft around. I'll try a more reasonalbe

frequency of 20 to 25 hz and see where that gets me.

For the PID Controllers to have decent responce, I'd like to get the gains up. But that will require that the data is refreshed at a fairly good rate(in both directions), and that the Simulator reponds quickly to the new changes. The time between getting the Data and the Simulator responce after a output change will dictate how good the responce of the controller can possibly be, and how high the gains can be.

Edit:

Pete....I just read about offset 0x06D0. You already have Autopilot functions in FSUIPC? How are the gain values changed...I don't see any information regarding those ie. Proportional Gain, Integral, and Derivative. Feedforward, Rate, ect.

[Pete Dowson]

I hadn't concidered that the data was updated based on screen rate FPS.

Well, it's whatever SimConnect considers the freame rate -- the one it reports.

I run mine locked at 30 and it maintains that almost

everywhere with the stock scenery. I have most everything set up on high, but I have the Traffic turned down. NYC JFK airport does drop my FPS a bit when I'm at the airport and there is alot of parked aircraft around. I'll try a more reasonalbe

frequency of 20 to 25 hz and see where that gets me.

Well, might as well try 30 Hz (33 mSecs interval) first if you have FS set to that.

Pete....I just read about offset 0x06D0. You already have Autopilot functions in FSUIPC? How are the gain values changed...I don't see any information regarding those ie. Proportional Gain, Integral, and Derivative. Feedforward, Rate, ect.

Not sure i use anything as sophisticated as your stuff, and those terms are too technical for me. Isn't the information provided? It was all done so long ago, and so little interest was shown by anyone, that i just left it as it was, a curiosity. If the information for modifying it isn't already provided I'd have to search for it.

Of course, nowadays, with the built-in Lua threads running in-process, you could write your own algorithms as plug-ins. Lua's quite powerful, and, although it is interpreted, it is quite fast once loaded and running. Being in-process with FS helps a lot, of course.

Regards

Pete

[Doug Moldenhauer]

Well thanks for the information. I'll try some of your suggestions now that I'm home and I'll see how it all goes. Also thanks for providing such a useful

utility for the FS world. I have purchased FS2004 version and now the FSX version. Alot of addons that are made today couldn't have come about

without your work.

I'd buy you a beer if I was still traveling to europe. I used to goto Harrow England, and Chalon Sur Sone France about once a year for work,

however I don't get over there anymore, so it'll have to be a virtual one :lol:

Thanks again

Doug

[Doug Moldenhauer]

Pete, I took a look at my code and it seemed to be hanging because I had several ReadAndProcess() commands in the same timer routine. Also a contributing factor was I have 3 timer routines and all of them are either reading or writing data to fsuipc using the same declaired connection. As the timer routines were running at different times, so the process() commands in each of the timer routine may have had data colliding.

Anyway, I declared 3 different connections and moved the routines into Worker Threads and everything is working fine

and has sped things up quite a bit.

Another question....There is 2 different offsets for vertical speed in FSUIPC. I've tried both but the data seems to be

filtered by FSX as it lags behind what is really happening. Caused some tuning issues for my Vertical Speed Controller.

I have it tuned fairly well now, but the lag in the data (or averaged data) keeps me from making it more responsive.

I was wondering when you wrote your autopilot if you found the same problem? Perhaps this is normal as Vertical Speed

feedback on a real plane is measuring the rate of change in atmosphereic pressure?

[Pete Dowson]

There is 2 different offsets for vertical speed in FSUIPC. I've tried both but the data seems to be

filtered by FSX as it lags behind what is really happening.

O2C8 is the value updated directly by SimConnect, the others are derivative. It will be updated at the same time as the other flight related values like pitch, bank, heading and airspeed. I know of nothing to make it different (but see [LATER]).

I was wondering when you wrote your autopilot if you found the same problem?

It isn't an autopilot, but a series of little feedback loops for pitch, bank and speed, so the V/S didn't come into it.

Perhaps this is normal as Vertical Speed feedback on a real plane is measuring the rate of change in atmosphereic pressure?

Maybe. I really don't know how it is computed in the sim. If you monitor it on screen with, say, the "Display Vals" Lua plug-in, is certainly seems to change rapidly enough.

[LATER]

Checking my code, the V/S is actually in the "visual frame rate" group rather than in the "Sim Rate group" like the latitude, longitude and so on. But so are the speeds. I can move them to the faster group, though I think a lot of the time the two equate. If you don't get anywhere, check again with version 4.415 or later when you see it posted in the updates announcement, probably before the weekend.

Regards

Pete

[Doug Moldenhauer]

Thanks for the info Pete.....I have one last question. The calls for ReadAndProcess, WriteAndProcess, and Process...are they blocking type calls or not? For example, will a call to Read and then a Process() stall at the Process call until until the data is available?

[Pete Dowson]

Thanks for the info Pete.....I have one last question. The calls for ReadAndProcess, WriteAndProcess, and Process...are they blocking type calls or not? For example, will a call to Read and then a Process() stall at the Process call until until the data is available?

None of the code I have produced have "ReadAndProcess" or "WriteAndProcess" calls. I wouldn't ever propose such calls because they tend to encourage folks to use one process call for each and every offset read or write. Ugh. The whole interface is designed to be used with regular blocks of requests -- one Process call for many reads and writes, mixed.

The Process call in my code is a "SendMessageTimeOut" with the timeout set to a number of seconds (you'd need to check the code for that, I don't recall), so yes, the Process call blocks unless it fails and so times out, in which case you'd get an error returned. On top of that I think some parts of the library code i provided do a number of retries, within the part incorporated into your code.

These calls have to block because the memory FSUIPC is being asked to dump the data into belongs to your program. If control were returned whilst FSUIPC was still accessing it, and you freed it or terminated, FS would crash.

The normal way to get around such blocking calls is to use threads.

Regards

Pete

[Doug Moldenhauer]

Thanks for the clarification.