Problems driving MS FS2004 Position using FSUIPC

[bigskyfunk]

I am using my own aero model to generate the position and attitude, (lat, lon, alt, phi, theta, psi), for MS FS2004 using FSUIPC. The problem is the display is visibly jittery. Is there anyway to improve performance? I am using a PIII 860Mhz machine to pass the data via a 100mps Ehternet connection. Would it work faster if I hosted my app on the same machine as MS FS2004? The app simply retrieve my data from a high speed reflective memory and then assigns position and attitude via FSUIPC.

Any suggestions are welcome!

[scruffyduck]

How often are you writing the data back - if you want to control the aircraft position etc is the sim in normal mode or slew mode? I would expect things to be slower if you have your application on a separate machine - try it on the FS machine and see if it makes any difference

[maufus]

When driving aircraft position via FSUIPC you have to:

- set SLEW MODE or

- set PAUSE MODE or

- set SIMULATION RATE to 0 (but this prevents you from seeing effects like rain, moving AI aircrafts etc).

BYE!

[bigskyfunk]

I'll see what happens!

[JWhitlock]

When driving aircraft position via FSUIPC you have to:

- set SLEW MODE or

- set PAUSE MODE or

- set SIMULATION RATE to 0 (but this prevents you from seeing effects like rain, moving AI aircrafts etc).

BYE!

A few other things:

- Limit the rate of MS Flight Sim, and try to match the rate (or maybe beat it slightly)

- Set HIDEINFOTEXT=1 in FS9.CFG (see http://forums.simflight.com/viewtopic.php?t=35693)

However, you may not be happy with the results. I've done all of this, running over the network, etc., but it still looks choppy. Not horribly choppy, but not as smooth as MSFS flys or slews.

Has anyone gotten really good results in dynamically updating position using FSUIPC?

[maufus]

Well, we're using MS FS2004 for a serious visual system and we got wonderful output.

We send data (position and attitude plus a set of other custom data) at 10ms rate or 20ms in other cases.

We set the frame rate limited to 50FPS and everything's fine.

The only problem with us was that we needed a multi-monitor output, so we had to buy a very powerful computer. Believe me - it's not easy to buy a top performance PC (in Italy, at least!).

[bigskyfunk]

How do you pass your position info to FSUIPC?

[maufus]

We use the 0560 and 0568 offsets.

Pay attention to the conversion functions: I suppose you send latitude and longitude degrees or radians angles over the net, maybe in a 'float' or 'double' field, and then convert them to 'FS UNITS'. Changing the order of multiplications/divisions may affect the conversion precision.

What do you exactly mean with "choppy" ? We get smooth flying - very nice!

Try installing FS9 on two separate machines. On one machine read FS UNITS and send them continously over the net without conversion. On the other side put directly the FS UNITS in FS9 and see what happens.

[JWhitlock]

What do you exactly mean with "choppy" ? We get smooth flying - very nice!

Try installing FS9 on two separate machines. On one machine read FS UNITS and send them continously over the net without conversion. On the other side put directly the FS UNITS in FS9 and see what happens.

That's a good idea, and probably answers one of my questions. We use WideFS for our network transport, and it sounds like you use your own ethernet routines. Does your ethernet run under a real-time system, or are you using Windows timing functions?

Straight and level flying looks fine. It's takeoffs and turns that don't look smooth. There is subtle lurching on takeoff, as if it misses a frame then jumps ahead two. Turning is similar - the heading doesn't change as smooth as it should.

My suspects are either my scheduler (trying to make Windows XP act realtime is a mess) or the network transport (maybe WideFS is queing up two passes, or some such thing). I'm writing an app to do a takeoff with canned data, so it can run on the MSFS PC, which should eliminate network problems. Running flight siim data to flight sim would help eliminate the network. Then, I'll be stuck without ideas again...

[maufus]

Does your ethernet run under a real-time system, or are you using Windows timing functions?

For FS-to-FS test case we do use windows timing: it's not very precise timing, but almost quick. With a simple 'Sleep(0)' in the data read&send loop we send messages at intervals ranging from 5-6 to 15ms.

To get quicker sending times, just minimize the source FS window (when minimized FS continues to run but its CPU usage is 1/10 than usual).

My main loop at receiver's side is:

  while (netRunning == true)
  {
    itmp = sizeof(inaddr);
    retval = csock->ReceiveFrom(inbuff, BUFSZ, (SOCKADDR*) &inaddr, &itmp, 0);
    if (retval == sizeof(indata))
    {
      fslat = inpkt->Latitude * LAT_DEG2FS;
      fslon = inpkt->Longitude * LON_DEG2FS;
      fsalt = inpkt->Altitude * ASL_M2FS;
      fspitch = inpkt->Thetad * PRY_DEG2FS;
      fsroll = inpkt->Phid * PRY_DEG2FS;
      fsyaw = inpkt->Psid * PRY_DEG2FS;

      fsuipc.Write(FS_LAT_FSUNITS, FS_LAT_FSUNITS_size, &fslat);
      fsuipc.Write(FS_LON_FSUNITS, FS_LON_FSUNITS_size, &fslon);
      fsuipc.Write(FS_ASLHGT_M65536, FS_ASLHGT_M65536_size, &fsalt);
      fsuipc.Write(FS_PITCH_CIRCLE, FS_PITCH_CIRCLE_size, &fspitch);
      fsuipc.Write(FS_ROLL_CIRCLE, FS_ROLL_CIRCLE_size, &fsroll);
      fsuipc.Write(FS_HDG_CIRCLE, FS_HDG_CIRCLE_size, &fsyaw);

      retval = fsuipc.Process();
    }
  }

while at the sender's:

  while (this->runFlag_ == TRUE)
  {
    Sleep(0);

    latDeg = FSDataInterface::GetLatDegrees(); // fsuipc->ReadAndProcess(0x560...)
    lonDeg = FSDataInterface::GetLonDegrees(); // fsuipc->ReadAndProcess(0x568...)

    hdgDeg = FSDataInterface::GetHeadingDegrees(); // fsuipc->ReadAndProcess(0x580...)
    pitchDeg = FSDataInterface::GetPitchDegrees(); // fsuipc->ReadAndProcess(0x578...)
    rollDeg = FSDataInterface::GetRollDegrees(); // fsuipc->ReadAndProcess(0x57c...)
    hgtasl_m = FSDataInterface::GetAltitudeASL_m(); // fsuipc->ReadAndProcess(0x570...)

    // ----------------- SEND DATA
    indata omsg;
    omsg.Latitude = latDeg;
    omsg.Longitude = lonDeg;
    omsg.Altitude = hgtasl_m;
    omsg.Thetad = pitchDeg;
    omsg.Phid = rollDeg;
    omsg.Psid = hdgDeg;

    pData = (void*) &omsg;
    dataLen = sizeof(omsg);
    dsink->Send(pData, dataLen); // This is a simple UDP socket
  }

As an example, the FSDataInterface::GetLatDegrees() is

double FSDataInterface::GetLatDegrees()
{
  double dval = 0.0;
  DWORD dwResult;
  __int64 rVal;
  if (FSUIPC_Read(FS_LAT_FSUNITS, FS_LAT_FSUNITS_size, &rVal, &dwResult) &&
  FSUIPC_Process(&dwResult))
  {
    dval = (double) rVal;
    dval = dval * 90.0 / (10001750.0 * 65536.0 * 65536.0);
  }
  return dval;
}

PLS NOTE that we use 'double' because 'float' has insufficient precision!

ALSO note that this code is stripped out of a test application so may be somehow incomplete/incorrect.

Sorry for the long post - hope it's useful to somebody.

[bigskyfunk]

Maufus thank you for your suggestions. I will try and implement them ASAP and let you know how it works out.

[bigskyfunk]

I have implemented most of the suggestions offered and I am still getting choppy performance on "Final Approach" just before touchdown. Once on the ground it is noticeably better, but the the last 300' feet are like descending stairs.

Here is the code used to pass lat, lon, and alt to FS:

myLat = (latitude * 57.295779513082320876798154814105) * (10001750.0 * 65536.0 * 65536.0) / 90.0;

myLon = (longitude * -57.295779513082320876798154814105) * (65536.0 * 65536.0 * 65536.0 * 65536.0) / 360.0;

llat = (LONGLONG) myLat;

llon = (LONGLONG) myLon;

dataWrite(0x560, sizeof(LONGLONG), (unsigned char *) &llat);

dataWrite(0x568, sizeof(LONGLONG), (unsigned char *) &llon);

f = vars.h_agl + 30.5f;

if (f < 5.0f) f = 5.0f;

f = f / METERS_TO_FEET + 0.5f;

data[1] = (DWORD) f;

data[0] = (DWORD) ((f - ((int) f)) * 65536.0f);

// Compute pitch bias as function of altitude

thetabias = (float) (pow(vars.h_agl,2)*-1.285271e-010)

+ (float) (vars.h_agl*6.586e-006)

+ 0.0545f;

// APPLY ATTITUDE BIAS HERE!!!

// Pitch, roll, true heading

data[2] = (DWORD) ((-vars.pitch1+thetabias) * RAD_TO_DEG * FLOAT_ADJ);

data[3] = (DWORD) ((-vars.roll1-.01) * RAD_TO_DEG * FLOAT_ADJ);

data[4] = (DWORD) ((vars.truHdg1-.009) * RAD_TO_DEG * FLOAT_ADJ);

dataWrite(0x570, 5 * sizeof(DWORD), (unsigned char *) data);

Thanks for your helpful suggestions!

[vdkeybus]

Have you tried logging what you send and plotting that afterwards ?

Or you could eventually try to read back what you wrote the last timestep. I don't exactly know how FSUIPC handles combined reads and writes to the same offsets, but I imagine that you might be reading the value right before you actually overwrite it.

Another option is what I suggested already a few months ago: also update the speeds (delta LLAPBHs) and use normal flight mode (no pause or slew). FS will do the smoothing (interpolation) for you and performance may actually be a lot better if you send, like, only 10 samples per second or so.

Keeping the frame rate limiter on would also seem a very sensible idea.

Regards,

J.

[Pete Dowson]

I have implemented most of the suggestions offered and I am still getting choppy performance on "Final Approach" just before touchdown. Once on the ground it is noticeably better, but the the last 300' feet are like descending stairs.

Sounds like the normal jerkiness on finals when approaching a densely designed airport, one with a lot of buildings or AI traffic or autogen scenery.

It may be exaggerating the sort of slow-down you'd normally see because your process is being starved of sufficient time to do the updates at the intervals you need.

What are the relative frame rates in FS, between your smooth results and these? That should give you an indication of what is going on.

If you are running on a P4 with hyperthreading, check the Windows task manager -- see if you are using one "virtual processor" whilst FS is using the other. that should make things run smoother. If you are not using a P4 3.0 Gz or better, think about upgrading.

Reduce your autogen density -- the autogen scenery has a greater and greater effect on performance as you near the ground. Once you land it is less because the views are then effectively two dimensional.

See if reducing other density adjustments help -- scenery density and AI density.

Regards,

Pete

[bigskyfunk]

Pete,

Thanks for you insight, but I have a pretty hot machine. It is a 3.4 GHz Hyperthreading processor with 2GB of the fastest ram Corsair makes. Also, I am using a reflective memory board with essentially 0 transport delay to pass the data between my simulation and FS9 , (this eliminates delays due to wideview, network cards, etc...).

I have a hunch it could be related to the way I am computing lat/lon. I am using the localizer antenna as my reference lat/lon coordinate. From there I compute a range and heading to the aircraft and then compute the A/C lat/lon. However, I think this calculation may create a racheting effect as I get closer to the localizer due to the higher angular rates.

I am positive that the altitude data being sent to FS9 is "smooth", (I logged it to a file and plotted it). However, I am not as sure about the lat/lon calculation. I may try to implement a differnent lat/lon calculation and see if I get better results, unless someone has a better idea.

Speaking of better ideas, do you know what VDKEYBUS was talking about when he said I should pass my speed, to FS9?

VDKEYBUS Wrote:

Another option is what I suggested already a few months ago: also update the speeds (delta LLAPBHs) and use normal flight mode (no pause or slew). FS will do the smoothing (interpolation) for you and performance may actually be a lot better if you send, like, only 10 samples per second or so.

Thanks for any suggestions!

[Pete Dowson]

Speaking of better ideas, do you know what VDKEYBUS was talking about when he said I should pass my speed, to FS9?

Probably writing the velocities and even maybe accelerations to all or some of the offsets 3060 - 30B8 and 3178 - 31D0. These are all "writable" but have temporary effect, or at some have an effect and others may not. I know, for instance, the the aircraft carrier operations programs uses these for tailhook decelerations and, more importantly, catapult launchings.

But I'm afraid I don't know which, if not all, would need to be written and which are totally ineffective, if any. If you went down that path you'd need to experiment.

Regards,

Pete

[vdkeybus]

The main advantage of passing delta LLAPBS values (velocities) is that you can run the sim in normal mode.

Suppose we want to have the plane flying straight and level.

The technique discussed so far involved freezing the sim and passing 50 position and attitude values at precisely spaced time instants per second. This is not an easy task to manage.

What I propose is to keep the sim engine running, send a position, and, from then on, read the position and write the velocities to steer the plane along the desired path. (offsets 3178, 3180, 3188, 31A8, 31B0, 31B8) Because the path of an airplane can be well approximated by a series of straight lines, much less updates are needed and they do not need to be evenly spaced. The nice thing is: the sim engine will keep your motion smooth and, best of all, it is informed of your movements, allowing it to efficiently cache scenery etc.

And you have sound...

J.

[jordi]

Hi bigskyfunk,

I don't know if you finally solve your problem, I experienced the same situation as you.

In my application I have two threads:

1. For generating the simulation data (50Hz)

2. For refreshing the data in FS using FSUIPC (25Hz should be enough)

The refresh problem with FSUIPC is that Process() consumes a lot of time,

so use only one Process() call per frame, otherwise you will get jittery, because you lose a lot of cycles of simulation data.

This will improve a lot your performance. Afterwards you can implement a linear filter. The next position is averaged from the last received and the previous. This will reduce the effect of big changes in heading or pitch, specially when you are landing.

Setting the aircraft speed is not a good idea because after some minutes the aircraft position will be quite different from the real position.

Try these suggestions, in my case they worked very well.

Jordi

[bigskyfunk]

Thanks to everyone for your suggestions. It turns out the problem was that I incorrectly formatted the altitude input, offset (0x570). I was only setting the upper half of the word. When I correctly set the altitude everything smoothed out and looks great!

[paologunny]

hi bigskyfunk

i read the posts on the forum and i think i got more or less the same problem.

did you notice a sudden change in the altitude displayed by fs in slew mode? my problem is that altitude drops suddenly by (roughly) 3 feet when ascending or goes up by 3 feet when descending.

what format are you using for the altitude variable? double precision? or single?

my model is developed with simulink and i'm using a third-party s-function to pass the data to fs, i got it up and running but there's still this problem.

thanx for any suggestions

Paolo

[Pete Dowson]

did you notice a sudden change in the altitude displayed by fs in slew mode? my problem is that altitude drops suddenly by (roughly) 3 feet when ascending or goes up by 3 feet when descending.

Probably a metre (3.28084 feet). Sounds like you aren't dealing with the fractional part? Mind you, in slew mode maybe FS doesn't either?

Regards,

Pete

[bigskyfunk]

Hello Paolo,

First, may I suggest you get a copy of FS-Interogator if you have not already. This application is a great aide in debugging applications using FSUIPC. Just go to Peter's site and you should be able to find it. I give it my highest recommedations.

I think this may help. Here is the code I use to pass data to FS9 via FSUIPC.

// Note vars.z is float as well

float f;

f = -vars.z + 23.5f; // We add 23.5 to get the eye pt where we want it

f = f / METERS_TO_FEET + 0.5f; // Add .5 to round up

data[1] = (DWORD) f;

data[0] = (DWORD) ((f * 65536.0f * 65536.0f));

dataWrite(0x570, 2 * sizeof(DWORD), (unsigned char *) data);

//... and then later

fsu.Process();

did you notice a sudden change in the altitude displayed by fs in slew mode?

Yes, in pause mode as well.

my problem is that altitude drops suddenly by (roughly) 3 feet when ascending or goes up by 3 feet when descending.

Sounds just like my problem.

what format are you using for the altitude variable? double precision? or single?

My source is a float, the output is cast as a Double precision.

my model is developed with simulink and i'm using a third-party s-function to pass the data to fs, i got it up and running but there's still this problem.

Where did you get the S-Function, I would be interested in this feature. We use simulink as well and I have been tasked with creating this capability. More info would be welcome! :)

[paologunny]

I think we have the same problem then.

The s-function i mentioned is part of a blockset which was produced by Unmanned Dynamycs. the site is http://www.u-dynamics.com

It's called the aerosim blockset, it's free for non-commercial users. there's also the source code for the s-function used to interface to fs.

i wasn't able to find fs-interrogator.

i'm still having the same problem and i am sure there's no mistake b4 the s-function so it must be it. but... i'm not a programmer so i can't see if there's a problem in the source code.

i'm also using widefs but that's ok, i tried to run both on the same machine but had the same problem.

bigskyfunk, u want to talk about this on msn?

cheers

[Pete Dowson]

i wasn't able to find fs-interrogator.

It is in the FSUIPC SDK, and has been for years. Get the SDK from http://www.schiratti.com/dowson.

Regards,

Pete

[/url]

[paologunny]

Thanx really much.

As i said i'm just a beginner....

Paolo