>In>http://forums.avsim.net/dcboard.php?az=sho...ing_type=search>Ron Friemuth says:>>"I see MSFS iterates the FM only 16 times per second, doubling>to 32 Hz at times. JSBsim, used in FlightGear has a user>settable rate, and 120 per second is typical." >>The paper says:>>"Flight Simulator incorporates a subroutine which>computes what DeltaT should be based on the current framne>rate the program is achieving. As the performance of the>program degrades, the simulation dynamically alters the time>slice to take less processing time between cycles.>>Combat Flight Simulator utilizes a fixed DeltaT of>16Hz... We therefore incorporate a doubling... ultimately>achieving a fixed DeltaT of 32Hz">>I think we need hard evidence of where Microsoft is wrong ->not just unsubstantiated assertions.>The buck has been passed and maybe it's time for MS to show they actually understand their own program? Autopilot control surface movement effected through trim? Do you really expect simmers to prove that MS is wrong?Again, we have to remember that extreme flight model fidelity is NOT a Microsoft trait. They are singing to a different hymn. They are working to a set of averages and criteria that have no place in the cirtual world where force feedback is an exception, not a rule, where a range of extremes have to be tolerated in system performance & hardware configuration, even user skill and understanding. But if they know that, and we accept that, what WOULD be nice would be to have MS give us sliders that actually mean something by being able to `benchmark` against known criteria (that all-important but apparently secret `proprietary data`) so that we could, if we choose, set up our individual controllers and systems to best mimic the reponse of the aircraft simulated. Then we wouldn't have to rely on guesstimates or other peoples `feel` we could have a genuine in-sim benchmark to calibrate against. There has never been an FS benchmark.Allcott

>>There is no indication in that document that>>the author has been allowed access to the privileged>>information that would be required to reach the conclusions>he does, and indeed Ron Freimuth, one of the leading lights in>>the FDE world, has already pointed out errors in the>document, which suggest to me that the author - a wiz on aerodynmics ->>knows naff-all about the MSFS FDE. >>What that suggests to me is that neither you nor Ron F. know>just who Mike Zykowski is, or what his bona fides are: >>http://blogs.technet.com/skyhawk/>>I'll stick my neck out a bit and bet that a person who works>directly on the development of the product likely knows a>great deal more than anyone who merely works with the>product in question... :-lol I also checked Zyskowski's credentials. Certainly impressive. I believe he has MSA&A or MSAE from Kansas State. However, as I noted in more than one place, he is WRONG in several statements. Matters that can be verified. For one thing, there is no 'variation with Beta' in the Stability Derivatives. In fact, Jerry Beckwith pointed that out to me. Some of the effects alluded to have been broken in the later versions of MSFS. The 'Induced prop air flow' L:Var was dead when I checked it. Though, it is shown in the paper's block diagram. And, the 'prop blast on horizvertical stablizers' have both died since FS2K. One reason tail draggers are not realistic; you can't steer on the ground by using the prop blast on the rudder and you can't get the tail up from the prop blast, either. Many things that worked in CFS2 are dead in FS. The equations in the document show Cd_de, drag due to elevator deflection. FS has never had such an effect. JSBsim (Flight Gear) does. The block diagrams are only approximately correct. One shows throttle directly controlling N1. In fact, the throttle controls CN2 indirectly through TBL's 1503 and 1504. CN2 is then is mapped to CN1 through TBL 1502. N1 is CN1*Theta2^[1/2]. Where Theta2 is relative temperature of air at compressor intake. Relative to 15C (where it is 1.00). If those of use into this stuff didn't have the turbine and other relationships worked out exactly, apps such as AFSD wouldn't display the correct values. -------------------------------------- Finally, 'drag from windmilling prop' is incorrect. The drag is too low; due to the way Ceta (prop efficiency) is coded in the windmilling condition. I many ways, Zyskowski's paper describes a general 6 DOF simulator with both correct and incorrect specifics to CFS/MSFS. Ron

>In>http://forums.avsim.net/dcboard.php?az=sho...ing_type=search>Ron Friemuth says:>"I see MSFS iterates the FM only 16 times per second, doubling>to 32 Hz at times. JSBsim, used in FlightGear has a user>settable rate, and 120 per second is typical." >>The paper says:>>"Flight Simulator incorporates a subroutine which>computes what DeltaT should be based on the current framne>rate the program is achieving. As the performance of the>program degrades, the simulation dynamically alters the time>slice to take less processing time between cycles.>Combat Flight Simulator utilizes a fixed DeltaT of>16Hz... We therefore incorporate a doubling... ultimately>achieving a fixed DeltaT of 32Hz">I think we need hard evidence of where Microsoft is wrong ->not just unsubstantiated assertions. I probably interpreted that interation rate incorrectly, though Zyskowski's paper isn't clear just just how much 'DeltaT' changes. However, indirect evidence, noted when my Concorde gets into a physically impossible state, suggests the iteration rate isn't that high. The contrails become straight line segments during which I expect no (needed) calculations are done. Further, the iteration rate (or scaling of inertias and forces in the simulation code) is too low to model small AC correctly. I found very low Yaw damping in a 25 lb UAV, even 100 lb is too low for MSFS to handle. Light AC tend to jitter on the runway, increasing Roll MoI can reduce the jittering. I have never seen Heavy AC jitter. Ron

Thanks for that, Ron. Allcott

>For one thing, there is no 'variation with Beta' in theStability Derivatives. In fact, Jerry Beckwith pointed thatout to me.I'm guessing he meant only in equations 17 and 18, because if there was no 'variation with Beta' in 19, there would be no stability at all along the yaw axis. (the only other terms in eq 19 are due to aileron (adverse yaw), rudder and zero lift state.)

"The 'Induced prop air flow' L:Var was dead when I checked it."I can't find such a variable in Parameters.doc, although there are RECIP_ENGINEn_INDUCED_VELOCITY in TokenVar.doc. Are these dead too?"The block diagrams are only approximately correct. Oneshows throttle directly controlling N1. In fact, thethrottle controls CN2 indirectly through TBL's 1503 and 1504.CN2 is then is mapped to CN1 through TBL 1502."N1 is CN1*Theta2^[1/2]. Where Theta2 is relativetemperature of air at compressor intake. Relative to 15C(where it is 1.00)."The block diagram actually shows Commanded N1 to be a function of throttle, altitude, and Mach number. You are implying the direct connection. The block diagram is consistent with the throttle controlling CN2 which is mapped to CN1 which in turn is converted to N1. If T is the throttle setting then the sequence you describe is:CN2 = f1(T)CN1 = f2(CN2)N1 = f3(CN1)is equivalent to N1 = f3(f2(f1(T)))i.e. N1 is a function of T (amongst other things), which is what the paper actually says.

>"The 'Induced prop air flow' L:Var was dead when I checked>it.">>I can't find such a variable in Parameters.doc, although there>are RECIP_ENGINEn_INDUCED_VELOCITY in TokenVar.doc. Are these>dead too? That's what I meant. But I thought there was an XML version. I displayed a lot of engine/prop variables and whatever I used for the above was dead. That was based on FS2K2 documentation. That doesn't mean it's dead in the simulation code. Regardless, as I'd mentioned, the prop induced velocity on the vertical and horizontal stabilizers disappeared in FS2K2, and then FS9, respectively. Futher, there is no 'helical air flow' effect on the tail in FS9. >"The block diagrams are only approximately correct. One>shows throttle directly controlling N1. In fact, the>throttle controls CN2 indirectly through TBL's 1503 and 1504.>CN2 is then is mapped to CN1 through TBL 1502.">The block diagram actually shows Commanded N1 to be a function>of throttle, altitude, and Mach number. You are implying the>direct connection. The block diagram is consistent with the>throttle controlling CN2 which is mapped to CN1 which in turn>is converted to N1. If T is the throttle setting then the>sequence you describe is:>>CN2 = f1(T)>CN1 = f2(CN2)>N1 = f3(CN1)>>is equivalent to >N1 = f3(f2(f1(T)))>i.e. N1 is a function of T (amongst other things), which is>what the paper actually says. Someone else brought that up to me. The diagrams are so vaugue as to be nearly useless. More show then tell. "Gross Thrust" follows "N2: f(N1, Mach)". Well after the 'Commanded N1" In fact, Fng is really a function of CN1, Mach, and Delta2. All scaled from 'Thrust Reference'. The paper gives a general concept of CFS/MSFS, but is of little value otherwise. But then, I guess they didn't want to give away any "secrets". ;)Ron

>>For one thing, there is no 'variation with Beta' in the>Stability Derivatives. In fact, Jerry Beckwith pointed that>out to me.>>I'm guessing he meant only in equations 17 and 18, because if>there was no 'variation with Beta' in 19, there would be no>stability at all along the yaw axis. (the only other terms in>eq 19 are due to aileron (adverse yaw), rudder and zero lift>state.) It was eq 20 that shows CXalpha and XCbeta modifiers. If there are tables for variation of a stability derivative relative to Beta, we have never found them. Ron

> I also checked Zyskowski's credentials. Certainly>impressive. I believe he has MSA&A or MSAE from Kansas State.>> However, as I noted in more than one place, he is WRONG in>several statements. Matters that can be verified.Replied to via email... EOT for me... ;)

>>I'm guessing he meant only in equations 17 and 18,because if>there was no 'variation with Beta' in 19, there would beno>>stability at all along the yaw axis. (the only otherterms in>eq 19 are due to aileron (adverse yaw), rudder and zerolift>>state.)> It was eq 20 that shows CXalpha and XCbeta modifiers. Ifthere are tables for variation of a stability derivative>relative to Beta, we have never found them. Ok, you were referring to the variation due to the non-linear behavior of the coefficients at

RF>> It was eq 20 that shows CXalpha and XCbeta modifiers. If>there are tables for variation of a stability derivative>>relative to Beta, we have never found them. >Ok, you were referring to the variation due to the non-linear>behavior of the coefficients at

Rather interesting thread.Happens when people who knows what they're talking about gathers...Alcott and Billionaire are now on my list of "must-read" posts...Ron has been there for quite a loooong while :-)Thank you all.BTW: I use ELITE v8, and assymetric flight is rather convincing, together with prop effects on tail and HS.X-Plane is yet undetermined to me. Sometimes I find it good, very good, but on many other instances it looks very far from that...I keep tracking FG as well, specially when Ron got interested in it and started posting very informative details about what he found.

> I think I already mentioned that one doesn't get enoughprop windmilling drag*. The prop coding results in 'over>unity efficiency': there is less power extracted from theairstream than dissipated in >Friction Torque (which is all that is left if the engine is dead). That

>Happens when people who knows what they're talking about gathers...>Alcott and Billionaire are now on my list of "must-read" posts...I

Beware that without the proper hardware ELITE won't shine...The Genview version in the demo will also contribute to establish the difference between the amazing scenery we get in games like MSFS vs amazing flight and systems modeliing (within the normal flight envelope + assymetric flight).You can control throttle, prop and mixture/condition using the PgUp/PgDn, Home/End and Ins/Del combinations...