Flight Model DOF data

[AJArena]

What do I need to do to retreive the position, velocity, and acceleration data for the six degrees of freedom (Pitch, Roll, Yaw, Heave, Surge, Sway)? Can this data be retreived in realtime (ie less than 1 millesecond delay)?

[Pete Dowson]

What do I need to do to retreive the position, velocity, and acceleration data for the six degrees of freedom (Pitch, Roll, Yaw, Heave, Surge, Sway)?

Check the Programmer's Guide in the FSUIPC SDK (http://www.schiratti.com/dowson)

Can this data be retreived in realtime (ie less than 1 millesecond delay)?

No, never. Nowhere near in fact. 1 millisecond would represent 1000 frames per second being calculated, if not displayed, in FS. How are you going to achieve that with today's hardware? Even process switching is going to take nearly that long, often significantly longer.

Most things in FS are calculated frame by frame, and even if they are performed quicker there's no way to get at them faster.

Regards,

Pete

[AJArena]

Pete,

I appreciate your response, but I think I may not have clearly stated my question. Let's say we are working with a 60 frame per second update rate. Then all the flight data would be updated 60 times a second. My question is one of latency. How long after the visuals are updated are the pilot's eye view 6 DOF data available to the FSUIPC interface? Is all data posted at the same time for each frame or does the data stream out sequentially within each frame. If sequential, where in the stream is the DOF data relative to the screen update?

[Pete Dowson]

I appreciate your response, but I think I may not have clearly stated my question. Let's say we are working with a 60 frame per second update rate. Then all the flight data would be updated 60 times a second. My question is one of latency. How long after the visuals are updated are the pilot's eye view 6 DOF data available to the FSUIPC interface?

No idea, sorry. In the time FS has to make one frame it is doing all sorts of things, and drawing the graphics is only one of them. Presumably most of the actual calculations leading to the values you need are done early in the frame, as new positional data then needs feeding to the graphics routines which have to draw things. Whether the values I am mapping to are those evaluated initially, or derived some other way, I've no way of telling.

I really don't even know if it actually is synchronously doing one computation per graphics frame -- it may be doing a lot more for all I know. It won't (shouldn't) be doing less, and I don't see a lot of point in it doing a lot more -- though that depends on its algorithms, presumably. But FSUIPC is locked to frame rates for obvious reasons. Updates to all of its client programs need to be as smooth as FS is, and that is the best way.

Even if I did know when things really happen, your program would presumably be reading the data from an external program by sending a message and getting a reply. Even if you managed to get your timing synchronised to the FS recalculation loop, how could you guarantee to have the request in my code at precisely the instant after the values are recalculated and available? You cannot, in fact.

On top of all that there are very very many things going on in FS which are simply not synchronous in any case. Most of the events (like input control movements) actually get posted via Windows messages. They form a queue and take their chances with everything else.

I think all you can do is experiment and find out if you can get what you want.

Regards,

Pete