External flight dynamics model.

[Jozef Bury]

Hello,

I develop 6DoF flight dynamics model of Mi8 helicopter. It is hel.exe file and it is designed for 50 Hz frame

rate. Now I need write module (helMi8.dll in Modules directory) into FS2002 to visualize flying and inter

process communication. Could you tell me, where I can find information and documentation about this?

I want to send to Fs2002 positions, angles, velocities, accelerations and some data to panel instruments.

I tried to use FSUIPC, but it does not work every frame and visualization is not smooth.

Thanks a lot.

Jozef Bury

[Pete Dowson]

Now I need write module (helMi8.dll in Modules directory) into FS2002 to visualize flying and inter process communication. Could you tell me, where I can find information and documentation about this?

There is none easily available. You'll need to work out how to do it. start by writing a Gauge. Gauges are just DLLs loaded by PANEL CFG files.

I tried to use FSUIPC, but it does not work every frame and visualization is not smooth.

Well FSUIPC is synchronised to FS's frame rate -- it needs to be because aynchronous settings can upset things. If you aren't achieving a smooth change via FSUIPC I think you need to look again at what you are doing.

Attempting 50 fps is a bit ambitious in the first place -- you are allowing 20 mSecs per frame including the process swapping needed between your EXE and FS. Maybe in a Pentium 4 3.0 or better with hyperthreading you can achieve this, with many FS settings turned down, but even then I would think it doubtful. Try 25 fps, with the FS frame rate limiter set to 25 so that it doesn't do more than it has to.

Regards,

Pete

[scottme]

Hi Pete and all,

Rather than starting a new topic, I though I'd recycle this one.

I am also trying to run an external flight model. My system runs like so:

1. Flight data (Lat, Long, Altitude plus 3 attitude angles) is sent from an external PC in real time at 50hz (MATLAB / xPC target). Data is sent via network UDP

2. A C++ program receives UDP packets on FS2004 machine and fires these 6 data values to FSUIPC/FS2004

The visual system must be smooth and as close to 50Hz as possible.

My first trials have shown that every few second or so, 10 or more frames are dropped, so the motion is fairly smooth then stops and resumes so the overall effect is stuttering.

I was wondering if anyone had any experience (successful or otherwise) of running FS2004 like this. I know FS2004 can be sped up by turning everything off in the setting and using low res, but are there any non obvious ways of significantly speeding FS2004 up, such as removing all a/c but 1, changing thread priorities etc. Also, I presume running XP as "light" as possible would also be a requirment. Any other hints?

Pete, is it possible to safely change the thread priority of FSUIPC alone, or must I change it for FS2004 as well?. Is matching the FS2004 framerate with the incoming data rate vital for this process?

I will be quite happy to share my c++ program if any is interested.

Thanks for the fantastic support forum and hope all is now well with your eye. I almost imagine that your eye problem occurred from all your typing in this forum! :)

My FS2004 system spec is :

Windows XP

Pentium IV 2.8 Prescott on Asus P4C800-E delux MB

Asus FX5700 video

1024Mb RAM

Best Regards,

Scott (registered FSUIPC user).

[vdkeybus]

Hi scottme,

Have you tried reducing the sample rate to e.g. 25 Hz first ? Chances are that the stutters still exist and you're chasing waterfalls here by trying to improve framerates.

I think many problems can be solved by synchronizing your xPC target to the FS2004 packets. If no synchronization exists, you will always get a rollover sometime.

It might also be your communications channel. Try using the serial port. It is fast enough and not so heavy on the processor as the IP stack code.

Another option would be to pass the simulation time to the Simulink engine and run your model in Variable Step Size mode. Or interpolate the data yourself.

I also suggest you run FS2004 in slew mode (at least for a start). Otherwise the FS sim engine might overwrite your values. That may look like a stutter ?... And I take it you do all your data reads/writes before calling a single FSUIPC_Process() for each time frame ?

Hope this helps. Let me (us) know.

Jeroen.

[Pete Dowson]

My first trials have shown that every few second or so, 10 or more frames are dropped, so the motion is fairly smooth then stops and resumes so the overall effect is stuttering.

That sounds like other processes in your PC. The most usual stutter with a few-second cycle is the one where Windows seeks IP addresses. You can stop that one by making sure all PCs on your netwrok have fixed allocated IP addresses.

But there are plenty of other causes -- active virus checkers, Windows XP file indexing service, and so on.

You need to disable altogether as many of the extraneous processes going on in your system as possible.

Pete, is it possible to safely change the thread priority of FSUIPC alone

FSUIPC isn't a single separate thread. Most of it runs in the main FS thread. Separate threads of higher priority are used for special timing and scanning purposes, but you can't change any of them.

Is matching the FS2004 framerate with the incoming data rate vital for this process?

I would think the whole process would be smoother if it were -- I don't know how you differentiate between the 50 fps you want to achieve and 25 fps though. They would look the same to me. It's changes in frame rate which you want to eliminate. If you are getting regular jerking at several-second intervals it is almost certainly due to outside influences, nothing internal in FS or FSUIPC is likely to do that.

Regards,

Pete

[scottme]

Thanks Pete and Jeroen,

Some useful stuff here.

I had tried this last week and sort of gave up and jumped onto X-Plane, hoping I could get something running quickly while I solved the FS problems - turned out not to be the case!

Interesting one about the serial interface over the net interface. A little tricky in c++, but I might check it out. Never really considered Variable time-step mode in "real time" mode, might be interesting to consider (hehe, you've played with this stuff before...).

I am going to hit this with a big hammer and start from the minimum running FS9 spec and 30fps, and kill any non-vital XP processes and see where I stand.

We are doing all this work in a referbished Link 707 3dof simuulator base, so should be fantastic when it gets up and running.

Thanks once again,

Scott

[Pete Dowson]

Interesting one about the serial interface over the net interface.

If you stay with UDP you might want to investigate whethere you have the TCP/IP protocol set in a mode where it coalesces short blocks into one -- I think this is the default action. It waits foir so many milliseconds to see if you are going to send soimething else so it can send them together. This makes sense on the Internet proper, as it cuts down on overheads substantially, but it is a pain when trying to use it for real-time interaction between two local machines.

In Windows "WinSock" the option is turned off by a SetSockOpt with TCP_NODELAY.

Before I discovered this, when I changed WideFS over to TCP/IP from IPX/SPX I had a lot of stuttering problems. Every so often loads of small changes were bunching and being sent in one block.

Regards,

Pete

[roch]

Hi all,

This is a useful thread, so let me revive it once more.

I also work on real-time simulator based on Simulink 6DoF model and MSFS's visualization. At present, I run both the simulation target and the MSFS on the same machine under Win2k. Since I am using generic real-time target, I am trying to achieve "soft" real time by synchronizing the simulation with the system clock.

Up to now, I used, with relative success, the "Flight Video" feature of MSFS for driving the aircraft position and other data. On my modest machine (PIV 2.4, 512Mb RAM, FX5200) I am able to keep up with real time at integration step of 5ms (or even less) and FS running at 25-40 fps. As you see, simulation step and FS frame updates are NOT synchronized. However, it is essential to send data to FS at as high rate as possible (as I try to increase the step I get the unexpected result of ruining the MSFS performance).

Up to now this was an introduction. It would be interesting to know if anybody has similar experience, but I came to this forum because of FSUIPC. So far, very few people use "Flight Video" that was described in the Netpipes SDK from MS. FSUIPC is far more popular and has some capabilities that "flight video" doesn't - like bilateral communication, more comprehansive set of parameters, and, as I hoped, better performance. The question is, whether it is suitable at all for real-time applications.

As I see in the FSUIPC SDK sources, what is FSUIPC_Process doing is sending message to FSUIPC and waiting 100 ms - and so up to 10 times. So, retrying sending the message introduces huge delays to simulation. It would be good to know several things: how often such retris may happen? How long takes SendMessage itself? What is the actual time that processing write request may take? How is synchronization with FS frame rate done? Finally, is there any sense in sending data to FSUIPC at a rate higher than FS frame rate? Since calls to FSUIPC directly from the simulation block the execution, I see the only solution in writing another module that will be able to receive data from simulation at some fixed rate without blocking the simulation and feeding data to FSUIPC as it is ready to receive it.

I'll appreciate any advice.

Alexei Rosich

[Pete Dowson]

FSUIPC is far more popular and has some capabilities that "flight video" doesn't - like bilateral communication, more comprehansive set of parameters, and, as I hoped, better performance. The question is, whether it is suitable at all for real-time applications.

That's something you have to try, then tell me.

As I see in the FSUIPC SDK sources, what is FSUIPC_Process doing is sending message to FSUIPC and waiting 100 ms

No, that is not true. The 100 millisecond Sleep is only executed if the SendMessageTimeOut fails (i.e. times out after 2 seconds!) and the retry count is not expired. The purpose of this is to give a 21 second window over which the Message has a chance of succeeding during times when FS simply isn't processing its message queue, as when it is reading large files from disc and so on. Mostly it would only ever happen to use the 100 mSec sleep when FS is in a menu somewhere or loading up an aircraft after being in a menu.

The 100 mSecs is nothing compared to the 2000 seconds already lost through the SendMessageTimeout failing.

It would be good to know several things: how often such retris may happen?

That depends on how often the user goes into menus, how slow the disk is, how fragmented the disk is, how much real memory is (to allow more caching and prevent thrashing) and so on. The better shape your system, the less often, and perhaps never if you have things right.

How long takes SendMessage itself?

The call causes a Process switch. How long does that take? I don't know, you'll need to measure it. But whatever method you use will have process switches when you have separate processes.

What is the actual time that processing write request may take?

Depends on what you write. In FS98 and before, writing to values in the GLOBALS.DLL actually directly affected what FS was doing. Easy, fast. Since FS2000 more and more things are removed from that sort of operation and made procedural. Actually OOPs -- calls to specific virtual functions on classes in containers in other classes in other containers. Ugh. Just like Windows itself, as machines have become faster and bigger, the software has bloated to match. Did I ever tell you I hated OOP? I'm a machine programmer by training and at heart and I find hacking through the monstrously complex machine code in FS very difficult and annoying these days, so much apparent inefficiency. It isn't the programmers fault, it is Windows and C++ and compilers.

How is synchronization with FS frame rate done?

Not sure it is true synchronization, but it's the best I found -- it latches on to one of the regular chains which is also used to update gauges and so on.

Finally, is there any sense in sending data to FSUIPC at a rate higher than FS frame rate?

I don't know, but I wouldn't have thought so. Try it and see. The problem is more how to ensure smoothness, no jerks and stutters, which is why I would always recommend using the FS frame rate limiter to set a low enough value that FS can always achieve reasonably easily, then matching that in your program. I suppose you could try 2 updates per frame, etc, but I'm not sure what it would accomplish. But definitely don't make them irregular if it is possible to avoid that.

Since calls to FSUIPC directly from the simulation block the execution, I see the only solution in writing another module that will be able to receive data from simulation at some fixed rate without blocking the simulation and feeding data to FSUIPC as it is ready to receive it.

Er, try threads?

I'm rather confused now. Are you writing an EXTERNAL process or an internal FS module? If the latter then what are you doing looking at the IPCuser source? You must use the Module User's library code -- see the separate ZIP in the SDK. That, of course, invlolves no process switch, no memory mapped files, just a normal SendMessage call with no timeouts, sleeps, and no retries. Look at ModuleUser.c.

I'm made an newer version of ModuleUser which can be used from any thread -- the current one should be used only from the main FS thread. However, the new one needs a new version of FSUIPC too.

Regards,

Pete

[roch]

Pete,

Thanks for a prompt answer. You made the general picture clearer, although leaving it up to me to figure out the details.

If it wasn't unclear from my questions, I am not writing an MSFS module, but connecting external program (i.e. aircraft simulation compiled to standalone executable). I used the word "module" just as a general term for any software module - as you suggest, I may try multithreading as well.

Also, if you wonder, I use FS2004.

I can make my simulation unaffected by delays caused by writing data to FSUIPC, but then, the question is - citing you: "how to ensure smothness, no jerks and stutters". I get that this is the problem that many people have (like scottme in this thread). Why can this happen: external simulation runs smoothly, framerate that MSFS displays is somewhere around 45 fps, but the plane is jerking back and forth (slew mode is on)? The same thing with slew mode off. What can be wrong? Ordering of the data? MSFS overwriting the values? I don't have such problems when using Flight Video (i.e. making the MSFS to playback the data stream in FSR format that I feed from my simulation).

I also don't succeed in getting correct display of airspeed and vertical speed in the cockpit, although I write them to correct offsets. Any ideas?

Thanks once again,

Alexei

[Pete Dowson]

... the question is - citing you: "how to ensure smothness, no jerks and stutters". I get that this is the problem that many people have (like scottme in this thread).

It's the Holy Grail of flight simulation -- smoothness is really more important than frame rates, but more difficult to measure. There are heaps of threads about how to get FS to run smoothly in many forums. There's even a business set up which I think is doing a good job telling folks how to set up their systems. And the answers tend to be different according to the type of scenery you use -- photorealistic seems to be better with different settings to plain repeating texture scenery.

Why can this happen: external simulation runs smoothly, framerate that MSFS displays is somewhere around 45 fps, but the plane is jerking back and forth (slew mode is on)?

Sounds like things are arriving in little batches. Possibly this is a result of Windows timeslicing, plus message queue handling, on a system not really fully up to the task. In my opinion there is no system currently available which will drive FS at 45 fps consistently without stutters. Set the frame rate limiter to 20 or 25 and try again.

Other things which may help include using a Pentium with hyperthreading, and run FS in one "virtual processor" and your application in another -- FS only seems to run in one in any case.

Also, try not using slew mode. It isn't really necessary. You can use pause mode or zero sim rate mode, or, in FS2004 only, even normal running mode.

I don't have such problems when using Flight Video (i.e. making the MSFS to playback the data stream in FSR format that I feed from my simulation).

I don't know it at all, but it is probably designed for this and does interpolations, by time, for you. If it suits your needs, why not use it?

I also don't succeed in getting correct display of airspeed and vertical speed in the cockpit, although I write them to correct offsets. Any ideas?

They are results of simulation, not controlled directly. The gauges which measure what is happening will do that. You make it happen, the gauge will follow (unless you are in a mode where the gauges aren't updated).

If you want to control cockpit indications directly you probably need to design your own gauges which read private values you can control yourself, like Project Magenta and other external cockpit implementations.

Regards,

Pete

[vdkeybus]

the plane is jerking back and forth

Perhaps the visual output and the simulation engine are running in two separate threads in FS ?

Back and forth: do you mean the plane is really going backwards some of the times ?

BTW: 45 fps is very ambitious. Turn on some clouds, go near an airport and watch that number fade away... What is this application that requires more frames than the eye can perceive ?

J.

[prandtl]

Hi, I sow that someone has some experience in xPc and real time simulation. My problem is that I have a dynamic model running in xPc and a Simulink model on the host machine and I don't know how to keep them sinchronize. The UDP comunication has some problem as well, because the data sent by the target are not correctly seen by the host. How can i solve this problem?

Regards