• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Sim Connect Data Performance Issues

M

mattford1

Messages
4
Country
us-california
Hi Guys-

I'm trying to use sim connect to drive a Level D visual system extracting Lat/Long/Alt and other necessary variables and sending it off to the visual system via a UDP connection (so FS is the host). I'm finding that:

1. The frame rate of the data is fairly choppy (even though FS is running at about 65hz). I have the data period set to SIMCONNECT_PERIOD_SIM_FRAME on the request data on sim object.
2. The data buffer seems to run behind. In other words lat long data keeps running for about 10 seconds after pausing the sim.

I've basically used the Tagged Data example in the SDK. Is this the best method to extract data from sim connect? I'm fairly new to C++ so I'm still trying to get my head around it. Any help would be appreciated!

Cheers,
Matt
www.737sim.com
 
Hi,

mattford1 said:
1. The frame rate of the data is fairly choppy (even though FS is running at about 65hz). I have the data period set to SIMCONNECT_PERIOD_SIM_FRAME on the request data on sim object.
Click to expand...

I've used SimConnect PER_FRAME notifications and they don't seem to lag. That's not tagged, though, just a generic data request. I think the tagged method allows you to set a minimum delta - that is, it doesn't bother sending data until the variable changes by a certain amount. Could this be affecting your code?

I suppose if you're requesting huge amounts of data that might be a problem too. What are you asking SimConnect for?

Cheers,
Jim
 
mattford1 said:
1. The frame rate of the data is fairly choppy (even though FS is running at about 65hz). I have the data period set to SIMCONNECT_PERIOD_SIM_FRAME on the request data on sim object.
2. The data buffer seems to run behind. In other words lat long data keeps running for about 10 seconds after pausing the sim.
Click to expand...

Sounds like queuing, and I'm not surprised if you are trying to sustain an FSX frame rate of 65! That only gives 30 mSecs for every batch of data including everything FSx has to do, everything you are doing, and the process switches involved.

Set the frame rate limiter to something more sensible, like 20 or 25, then re-test.

Also make sure you are using SP2 or Acceleration level SimConnect, so it is using Pipes not TCP/IP. And you probably want to run your own networking part in a separate thread. Note that just having SP2/Accel installed doesn't mean it will use Pipes. You must compile to that level of SimConnect too.

I've basically used the Tagged Data example in the SDK. Is this the best method to extract data from sim connect?
Click to expand...

If all the data you are asking for is changing to the significance you need all the time, then, no, tagging would be less efficient than having the data sent in a fixed structure. However, if much of it can be omitted most of the time, tagging is best.

BTW you seem to be asking similar types of questions in several different places, and I've replied every time, then heard no more. Are you never seeing my replies?

Regards

Pete
 
SimConnect

Pete-

Hi. Did just go through my emails and replied to you and thanks for your help. Just asking for some other opinions as well. I am running SP2 but am finding better response using your FSUIPC, so I think I might stay there.

I need to extract data at no less than 60Hz. Would you say then that FSX neeeds to run at double that? Of course I'm not using the FSX visuals at all so I have all of the graphics turned down to virtually nill.

Who is the guy that did the MFC SDK for FSUIPC? I'm wondering if it might be better to contact him since he wrote it?

Thanks,
matt
 
mattford1 said:
I need to extract data at no less than 60Hz.
Click to expand...

Why? That's a very high rate to try to maintain with any smoothness at all without a 5GHz processor and Solid State Disks. You are much MUCH more likely to get smooth consistent rates by limiting the frame rate to something below your minimum normal rate. 20 or 25 should be fine, 30 at a push.

If the equipment needs 60, try for 30 and interpolate once midway between each reading.

Also, don't forget that because SimConnect is asynchronous there's not necessarily exactly the same interval between each reading you receive. That is, you may receive them all irregularly even though the values are theoretically correctly at the frame rate. You'd need to feed them out regularly, evening out the variations. Ideally SimConnect should have timestamped them all at origin so they could be timed exactly in use. Of course, you end result would be running a bit behind the sim in any case. That's unavoidable.

Would you say then that FSX neeeds to run at double that?
Click to expand...

No, you'll make things worse. How on Earth could you get anywhere near running at 120 fps with no nasty stutters? Ugh. You got a Cray at your disposal? ;-)

Regards

Pete
 
Pete-

Yes 60hz is what the gear needs, but keep in mind this stuff is built for FFS's. I think the extrapolation is a good idea. I'll give that a try.

I had no luck getting the buffering issue to stop so i went with your FSUIPC. The performance seemed to be better anyway with your stuff. I understand your stuff so I think I'll stay in your camp :-).

Matt




Quote:
Originally Posted by mattford1 View Post
I need to extract data at no less than 60Hz.
Why? That's a very high rate to try to maintain with any smoothness at all without a 5GHz processor and Solid State Disks. You are much MUCH more likely to get smooth consistent rates by limiting the frame rate to something below your minimum normal rate. 20 or 25 should be fine, 30 at a push.

If the equipment needs 60, try for 30 and interpolate once midway between each reading.

Also, don't forget that because SimConnect is asynchronous there's not necessarily exactly the same interval between each reading you receive. That is, you may receive them all irregularly even though the values are theoretically correctly at the frame rate. You'd need to feed them out regularly, evening out the variations. Ideally SimConnect should have timestamped them all at origin so they could be timed exactly in use. Of course, you end result would be running a bit behind the sim in any case. That's unavoidable.

Quote:
Would you say then that FSX neeeds to run at double that?
No, you'll make things worse. How on Earth could you get anywhere near running at 120 fps with no nasty stutters? Ugh. You got a Cray at your disposal? ;-)

Regards

Pete
 
If you really need the data every sim frame then you could do it this way:

1) Create an in-process gauge dll and open a SimConnect connection within it and set an event trap on each visual frame.

2) Within the event trap in the SimConnect callback, use gauge code like:
Code: 
FLOAT64 ex_AAircraftLatitude_f64 = aircraft_varget( get_aircraft_var_enum("PLANE LATITUDE"), get_units_enum("degrees"), 0);

to get the specific variables.

3) Package them up and pipe them out yourself using UDP.

If your FPS is not rock steady at 60 fps, you could simply update local variables in the SimConnect callback and create a separate Windows timer callback that runs at 60 Hz, and do the piping out from within that.

Si
 
Hey All,

As Pete said way up, unless most of the data in your data structure won't be changing every frame, you are better off using the non-tagged version of the RequestDataOnSimObject call.

Also, as has been mentioned, if you can make your SimConnect to IG module as an in-proc C++ DLL Module, there will be much less lag in the data (an in-proc DLL's message callback routine is ran directly within one of FS's threads and bypasses both TCP/IP and Pipes, passing data structure pointers directly to the client) - since you will be running within a FS thread, also follow Pete's advice to use a seperate background thread to handle the communications with the IG system(s) or else you will slow down the frame rate in the main sim.

Here's a pointer to a blog entry that talks about creating in-proc DLL based simconnect clients:

In-Proc DLL Blog Entry

And here's a pointer to a sample in-proc DLL client:

In-Proc DLL Sample Client
 
Simconnect

Let me give that a try. I'm brand new to C++ so a DLL seems a little intimidating :-). I'll look at those tutorials.

Thanks!
Matt
:)
 
I think the accuracy of data that extracted Lat/Long/Alt was is too low.

so I suggest you should define a struct as follow:

struct position
{
double Lat;
double Lat;
double Lat;

};
 
I think the accuracy of data that extracted Lat/Long/Alt was is too low.

so I suggest you should define a struct as follow:

struct position
{
double Lat;
double Long;
double alt;
};
use this cast pointer to extrcat data in the message loop :rolleyes:
 
I have the exact same problem with lag in SimConnect. I've tried differens refresh-rates (visual frame or sim frame). I even tried limiting FS to like 10 fps and still a lot of lag.

I have a project that is some external flight instruments that is to run on a separate computer (like for ex. Project Magenta), and this doesn't work with like 10 seconds of lag. I have now converted this project to FSUIPC and it works quite well (at least no lag!). But in FSUIPC, I can't get the AI-traffic-info for my TCAS display.

Could the gauge DLL be something for me as well? Does it work with C#?
 
you might want to start a new thread rather than necro this one, but I think you've just got a bug in your code.

Are you running the app with the simconnect API code on the same machine as FSX, or running simconnect over tcpip ?

Maybe try temporarily *reducing* the update rate by subscribing to the 4sec event and try measuring the latency. With a very high event rate I wonder if you are not processing the events fast enough and they're queuing up. If you detect a 10-second delay on a single event that would tell you a lot.

B21
 
You must log in or register to reply here.
Back
Top