Jump to content
Sign in to follow this  
Guest airhead

Enabling and managing power output (including WEP) in F...

Recommended Posts

Guest Ian_K

Doug,which one are you refering to:http://www3.addall.com/New/submitNew.cgi?q...e=&dispCurr=GBP1. Airframe and Powerplant Mechanics Gen HandbookUsdot ~ ~ ISBN: 1125875135 ~ TRADE PAPERclick here to compare the book price ...2. Airframe and Powerplant Mechanics General Handbook (Advisory Circular Series, No. 65-12A) (S/N 050-007-00373-1)~ Government Printing Office June, 1976 ~ ISBN: 0160051444 ~ click here to compare the book price ...3. Airframe and Powerplant Mechanics General Handbook (Ea Ac 659A) revised ed -JS312602)Federal Aviation Administration, ~ Jepperson Sanderson Aviation January, 1979 ~ ISBN: 089100078X ~ click here to compare the book price ...4. Airframe and Powerplant Mechanics: Airframe Handbook~ ~ ISBN: 0160362091 ~ Paperbackclick here to compare the book price ...5. Airframe and Powerplant Mechanics: Airframe HandbookFederal Aviation Administration, ~ Jepperson Sanderson Aviation March, 1979 ~ ISBN: 0891000801 ~ click here to compare the book price ...6. Airframe and Powerplant Mechanics: Airframe Handbook IndexJoseph J. Diamond, ~ Jepperson Sanderson Aviation June, 1979 ~ ISBN: 0891000933 ~ click here to compare the book price ...7. Airframe and Powerplant Mechanics: Powerplant Handbook (JS312608)Federal Aviation Administration, ~ Jepperson Sanderson Aviation January, 1979 ~ ISBN: 0891000798 ~ click here to compare the book price ...8. Powerplant Mechanic Study Guide for Airframe and Powerplant Mechanics: Powerplant Handbook, Federal Aviation Administration Publication Ac65-12aDale Crane, ~ Capstan Publications January, 1988 ~ ISBN: 091456532X ~ Secondly, what do you recommend as useful to model turboprops for MSFS if any?Ian

Share this post


Link to post
Share on other sites
Guest Douglas K

>However I intend to stick to talking about MSFS in any future posts as checking what I think I know about the details and history of real aircraft against the appropriate references is too time consuming and probably off topic anyway.You do not need any data you cannot impose, or do not have the intention to impose, on TBL 508 and TBL 509. There are no other relevant curves available to you for use in FS9.Do you know why magnetoes are stamped with "D" or "G" to indicate rotation direction? Bet there aren't many around who know the answer.< Ron, I'm also betting that there aren't many people around who know the answer to that question.I know that I am not among them. I asked probably a dozen guys at work last night and nobody knew. The only 'D' anyone had ever seen on a magneto was on the Bendix dual mag single drive (D for dual mag single drive, S for single mag), and that has nothing to do with the direction of rotation. 'L' and 'R' tell you that. FSAviators D for Droit and G for Gauche answer looks good to me.

Share this post


Link to post
Share on other sites
Guest Ron Freimuth

>>.................>>Do you know why magnetoes are stamped with "D" or "G" to>indicate rotation direction? Bet there aren't many around who>know the answer.< >>Ron, >>I'm also betting that there aren't many people around who know>the answer to that question.>>I know that I am not among them. I asked probably a dozen guys>at work last night and nobody knew. The only 'D' anyone had>ever seen on a magneto was on the Bendix dual mag single drive>(D for dual mag single drive, S for single mag), and that has>nothing to do with the direction of rotation. 'L' and 'R' tell>you that. >>FSAviators D for Droit and G for Gauche answer looks good to>me. Right. I guess they didn't have CW and CCW circle punches so used letter punches. Just the thing to make things difficult. Anyway, France wasn't supplying magnetos for the Allies for long. I learned that in two semesters of A&P night classes I took a long time ago. What a drag, seems we spent most of out time doing W&B calculations by hand. No calculators back in the 60's. I turned to more useful learning about a mile away from the A&P classes in Palo Alto CA. At a place known as 'The Farm'. Ron

Share this post


Link to post
Share on other sites
Guest Ron Freimuth

>I regret that there were some material inaccuracies>concerning the development and deployment of the P-38 in my>...>Briefly the actual situation was that the British Purchasing>Commission ordered 143 x Lightning I analogous to the P-38E,>but with superchargers and without handed engines, .... I made a discovery with MSFS. When the props rotate the same direction Yaw stability is improved. I expect only with 'realistic' flight models. I had an AC set to turn props in opposite directions to cover up the bug in FS2K2 where twins would pull to the left on TO unless one made the props counter-rotate. That was fixed in FS9 so I tried setting the props to turn the same direction, as in the real AC. I found Yaw stability improved. I expect due to the uncancelled 'gyro' effects. However, you do get the disadvantages of same direction rotation, including gyro and Yaw P-Factor adding rather than subtracting between the two props.>It all comes down to the original question. How do I enable>and use the various power limits of a piston engined aircraft>in FS9. This still comes down to using the throttle and rpm>controls within FS9 to set the limit MAP and rpm values stated>in the handling notes. For MSFS product development the>internal details of the power train may be interesting, but>are otherwise completely irrelevant. You do not need any data>you cannot impose, or do not have the intention to impose, on>TBL 508 and TBL 509. There are no other relevant curves>available to you for use in FS9. Actually, the "IMEP" 'Torque TBL 508' and 'Friction Torque TBL 509' are also significant. MS has the torque tables wrong, they don't know #@%!. Also, the Friction Torque is way too high. I have a P&W curve for 'Friction HP' and figured how Friction Torque varies from that. I simply scale the curve based on cylinder displacement to all my engines. Friction doesn't have a varying effect until one is past the critical altitude. Or, with a normally aspired engine. In those cases, it makes the HP drop faster than air density decreases. By the time ambient pressure in 5" there is only enough torque to overcome friction losses. Reducing RPM reduces Friction more than 'internal power' (if properly set) and I've actually seen FS/CFS AC will reach a higher ceiling when RPM is pulled back. There are two basic components to 'Friction Torque'. 'Rubbing Friction' (mainly the rings) and 'Pumping Losses'. The latter are much higher with WOT. Note an auto with a manual transmission will slow more rapidly with the ignition cut when one holds the accelerator wide open. That's because it takes a lot of power to pump the air through the engine. Unfortunately, the MS model doesn't include the effect of throttle position. That's mainly important with the prop windmilling, since it affects windmilling drag. One can glide farther in a FP prop AC if he can manage to stop rotation. A stopped prop, even with fixed blades, creates less drag than a windmilling one. I had Herve' add several elements related to the above reciprocating tables to AFSD. One can see: Indicated (internal) or Shaft(Brake) Torque MEP Friction>Finally Ron, the British also took over the French order for>P-38s in June 1940, (after France fell). They had specified>handed engines so I expect some parts of (some) handed engines>were stamped D for Droit and G for Gauche during manufacture. ...>FSAviator I commented more on that in another reply. I can never remember which is CW and which CCW.Ron

Share this post


Link to post
Share on other sites
Guest Douglas K

>I learned that in two semesters of A&P night classes I took a long time ago. What a drag, seems we spent most of out time doing W&B calculations by hand. No calculators back in the 60's.I turned to more useful learning about a mile away from the A&P classes in Palo Alto CA. At a place known as 'The Farm'.< Stanford in the 60's, that must have been interesting. Have to agree that whatever you learned there was probably more useful than learning aircraft maintenance, just about anything you can name results in a better paycheck than aviation.>I commented more on that in another reply. I can never remember which is CW and which CCW.

Share this post


Link to post
Share on other sites
Guest _FSAviator

Earlier I said,>However I intend to stick to talking about MSFS in any future posts as checking what I think I know about the details and history of real aircraft against the appropriate references is too time consuming and probably off topic anyway.>Entirely my fault Douglas I wandered off into historical stuff that needs careful checking against multiple sources before posting.I said,<< You do not need any data you cannot impose, or do not have the intention to impose, on TBL 508 and TBL 509. There are no other relevant curves available to you for use in FS9. Ron replied,<>I conclude that we are in complete agreement. <>I proposed the reason that the default curves have false values earlier in this thread. <>The rpm should pull itself back in most cases. The rpm lever only demands an rpm. Towards ceiling it is unlikely the engine will deliver. There are only specific circumstances under which it might. This was also discussed earlier in this thread. If all the power and airscrew curves are TRUE the system will seek its own energy equilibrium and will adjust rpm delivered in a fairly realistic way regardless of rpm demanded. FSAviator

Share this post


Link to post
Share on other sites
Guest Ron Freimuth

<>>The rpm should pull itself back in most cases. The rpm lever only demands an rpm. Towards ceiling it is unlikely the engine will deliver. There are only specific circumstances under which it might. This was also discussed earlier in this thread. If all the power and airscrew curves are TRUE the system will seek its own energy equilibrium and will adjust rpm delivered in a fairly realistic way regardless of rpm demanded. >FSAviator I've managed to get %HP, MP, GPH, RPM and TAS close to PoH tables by spending a lot of time on these tables. The engine curves interact with the prop coefficients. FP props don't have an automatic adjusment to hold RPM and in ways are more difficult than CS props. Since I have worked out how to scale Friction Toqure from a real engine curve that leaves 'Torque vs RPM' to adjust. A flat curve that sets the correct SL HP at rated MP isn't too bad, but I set a curve that peaks around 2300 RPM and drops some at the last high RPM setting (which I make higher than RED Line, since the engine may overspeed). The drop is only 2 or 3% relative to a typical max around 0.48. I set about the same drop at 1800 RPM. Then, adjust the value at 0 RPM in part to set Idle Speed. If one sets Idle with Friction torque at the low end that curve is likely to not have the correct slope in the normal operating range. These two engine curves interact with the two prop curves to account for the end values of RPM, Thrust, etc. I understand engines better than props and also have data on them that lets me set HP at different altitudes and RPM's. So, I set the engine curves mainly from the above ideas. That leaves the two prop curves (of course, prop diameter is very important). For a CS prop I may leave the Cp table as it is. I adjust the prop efficiency table to reduce efficiency to around 60 to 75 % for climb Beta and J. And, set the entries so efficiency is around 83% to 86% in cruise. Small changes in efficiency have limited effect on TAS but do affect PPH directly. For FP props I may use AirUpdate to set just one column of data for the Blade Angle I set. Though, one could leave a column on each side so he can adjust beta a bit to tweek the results. I then adjust the Cp (Power Coefficient) entries to get correct RPM at a given %HP. A higher Cp loads the engine more, RPM and HP drop. Similar to setting the gear ratio in a mechanical transmission. Finally, I adjust the Efficiency entries to get appropriate climb efficincy and about 83% to 85% cruise efficiency. I may change the Friction Torque a bit to adjust % HP at high altitudes but the main idea is to start with either good engine curves or good prop curves. Since prop details depend on fuselage interference and I also put some of the engine efficiency variation wrt RPM in the Ce tables I mainly tweek the prop tables. I've noted the PoH for Cessna AC shows %HP not dropping as fast with altitude as RPM and MP would indicate. That's due to reduced back pressure and appears to be significant even for normally aspired AC. Fortunately, FS appears to model that well, at least for the AC I've done. There are small deviations in my results relative to the old, hand calculated PoH tables which I suspect are errors in the tables rather than in my end results. I might mention that FS models intake restriction also. I never felt a need to change the 0.98 at the high end. I think it's hard coded in FS9. This has a significant effect on torque vs RPM and MP in addition to the 'torque table'. I need to add a Percent HP to my Prop Test gauge. That will be easy, though I'll have to set rated HP in the XML constants for a specific AC. I already set Prop Diameter so I can calculate and display J, Ct and Cp. As far as I'm concerned, the main limitation on the FS reciprocating engine model is engine SFC is independent of RPM. SHP is appropriate, but SFC varies only with mixture. I can calculate a more appropriate GPH by taking friction torque losses into account. The main problem is to drain the tanks at the correct rate with an independent gph reading. It looks like others have worked at least part of that out in XML. With appropriate variation of SFC wrt RPM, I should be able to model the effect of RPM and turbocharging better. I have curves of SFC for an old gearned engine, and SPC increases to 0.75 at full turbocharged RPM/power, but drops to about 0.52 at cruies RPM and MP. A bit lower at low RPM's. CHT is another MS screwup. It appears to vary mainly with RPM. That tends to work for a FP prop, but isn't good for a CS prop. Certainly CHT drops when one reduces MP at a constant RPM in a real AC. Nor does CHT change appropriate wrt Mixture. Another thing I want to fix in a gauge. Ron

Share this post


Link to post
Share on other sites
Guest _FSAviator

Inevitably this thread is now drifting off into a general debate about all things aircraft. That's OK, but it means that I feel the need to clarify and dispute some things that I was not expecting to deal with in this thread. That is unfortunate as with the Christmas and New Year break well behind us this will be my final opportunity to contribute to this thread.So far this thread relates explicitly to power creation and management in super compressed, throttle gated and multi throttle engines. So when Ron's says.<>I would like to remind everyone that in FS9 this relates only to normally aspirated engines. In FS8 it was a flight dynamics variable within REC506. In FS9 it is a constant in the flight model. The intake restriction can in theory be manipulated by the FDE author by other means, even in FS9, but in practice it is much easier for the gauge author to manipulate the displayed output. Unfortunately the hard coded value in FS9 is significantly in error for many engines. It is wrong by almost 10% for some current Lycomings for instance, and doubtless by more for even older normally aspirated engines. Concerning (only) normally aspirated engines in FS9 Ron goes on to point out that,<> This is why, (save for co-incidence), a single set of gauges for an aircraft with normally aspirated engines cannot work correctly in both FS8 and FS9. In FS9 MAP, Ata and Boost gauges for normally aspirated engines are engine specific and cannot be used with a different engine. This is a problem for gauge authors, not FDE authors, even though it arises from deletion of REC 506 from the FS9 air file. The relevant code has not migrated to the aircraft.cfg. Different types of engines require different solutions. Normally aspirated engines (alone) require a gauge based solution. Which is why I had explicitly excluded them from anything I have posted previously.Briefly on the subject of other gauge issues, CHT and other temperature outputs specific to particular engines are routinely manipulated outside MSFS and within freeware gauges. This is just one reason that panels, aircraft, and FDE are not mix and match. It is relatively easy to manipulate variation of SFC and its consequences inside MSFS using a modular approach via FSUIPC if the data required is available for encoding, but this cannot be done externally within a gauge. I was hoping to avoid airscrew theory altogether in this thread, but a significant problem arises from Ron's latest post.<>This implies that airscrew efficiency (from TBL 511 of the air file) can have an effect on what is happening in the engine. Since I have said throughout that power and related issues such as PPH, (fuel flow in pounds per hour), depend only on the content of TBL 509 and TBL 510 I feel that I must now explain why TBL 511 is not relevant and why the last sentence above is wrong on both counts.There is zero correlation between airscrew efficiency and specific fuel consumption (SFC), or any other attribute of the engine. If I put enough fuel in the tanks to turn a prop shaft for an hour at 1000 brake horsepower with an airscrew on the front that is 80% efficient the aircraft will go somewhere. If I substitute an airscrew (with flat blades) of zero efficiency the fuel will run out at exactly the same time (same PPH) but the aircraft will go nowhere.In this example these are two different fixed pitch props, but the above still applies if it is one variable pitch, or constant speed screw, which can vary between any two pitches which have variable efficiencies. So as you can see airscrew efficiency correlates strongly to MPH (miles per hour = TAS) but has zero correlation to PPH (pounds per hour = SFC). The nature of the correlation with MPH (aka TAS) is well known. All other things being equal the TAS varies as the square root of the airscrew efficiency. A 4% gain in airscrew efficiency will add 4% to the thrust and 2% to the TAS. It can never add or subtract any fuel flow in the engine. A more efficient airscrew increases range at any power setting but conversely endurance at that power setting does not change. In this case the range would increase by 2% but the fuel would run out at exactly the same time. Airscrew efficiency correlates to MPG (miles per gallon) but does not correlate to either PPH or GPH (gallons per hour).This is important because as FDE authors we rarely have access to the real efficiency curves for the airscrew. We have to create them from other known data including payload/range curves. If FDE authors start to think that airscrew efficiency (from TBL511) can impact either engine input or engine output they are doomed to go round and round in circles during FDE development. If airscrew (thrust) attributes are seen to vary piston engine (power) attributes during testing there are faults in the relevant parts of the air file. With appropriate care the relationships I have just explained allow the FDE author to discriminate between errors in the airscrew code and errors in the engine code when testing against known range and endurance. Other factors are involved.It is a wholly separate subject to the one discussed so far in this thread, but since it has now been brought up I will offer the following thoughts concerning the general principles of airscrew encoding. Ron and I share many views concerning air file development, but differ concerning airscrew development philosophy so my method differs from Ron's. My advice would be that unless FDE authors have a profound understanding of airscrew theory, they would be well advised to vary only airscrew efficiency, (ignoring the other airscrew variables), and furthermore vary airscrew efficiency only to deliver the correct range, rate of climb and ceiling AFTER developing the rest of the air file. This approach applies to more than airscrew encoding so I will explain in general terms. In any equation of general form;X = A*B*C / (D*E*F)where X is an output variable from MSFS and all the others are input variables, I only have to alter the value of any one variable to create an accurate value for X. My philosophy is to do just that unless the end user will be required to input the variables A to F inclusive.If A = MAP and B = rpm then I ensure that A AND B = TRUE because I am going to promulgate A and B as realistic inputs in the handling notes. If D = airscrew pitch and E = airscrew efficiency and I do not intend to mention either of them to the end user in the handling notes I will not worry whether either is accurate. I will however adjust the values of efficiency E all along the efficiency curves until A AND B AND X = TRUE. I will not research or impose true values for C to F inclusive.Nevertheless when the end user inputs realistic A and realistic B as specified in the handling notes they will create realistic output X. Any air file I create is explicitly based on the handling notes and will contain derivatives. The dynamics in MSFS were designed to facilitate the use of derivatives. Many variables are held constant whilst one derived value is calculated and imposed on only one of them to give the correct solution even though (potentially) no variable in the equation is accurate for the particular case. The alternative philosophy is to evaluate and code all the variables accurately. This may require a lot more research, a lot more knowledge, and a lot more iterative testing. There will be no difference in the output value X. Each FDE author must make a personal choice. Turning to the specifics of airscrew encoding, the efficiency of each airscrew pitch, at each advance ratio, is in TBL 511. MSFS interpolates between the multiple nested 3D surfaces that TBL 511 defines. Visualising those nested 3D surfaces is difficult. My advice is don't try. Just alter the relevant airscrew efficiency if the observed performance of the aircraft is wrong AFTER everything else in the air file is as good as it can be. This will not guarantee a realistic air file since the file may be offsetting an error in drag data with an equal and opposite error in thrust data. Chances are both will be wrong, but that will be true however many airscrew parameters are varied from default if there are residual errors in the drag code. Resolution of thrust error versus drag error is well beyond the remit of this thread.Returning to the main thrust of this thread, throughout I have tried to explain why managing power realistically in FS8/9 is not really about air files at all. As I have tried to emphasise all along it is all about handling notes and using them. When the aircraft is being created, and when the aircraft is being flown later.Worrying about whether there is a 1% or even a 10% error in the power curve or the thrust curve is utterly pointless if the person using the simulation does not know how much power is created with this engine rpm and that MAP. The download servers are full of FDE claiming to be 'realistic' or within n% of reality, but if the end user is not told that the engine in question must be throttled to e.g. 1000hp for the duration of the climb, and is not also told what MAP and what engine rpm create 1000hp, they will never know what power limit applies to which circumstance or how to apply (only) that power.Creating FDE that closely replicate reality is all very well, and I heartily approve, but what is the point if the end user can never figure out how to observe the current power limit to within 20%? There is no earthly reason to create FDE that are better than the handling notes available to operate them by. Lose sight of that and an FDE author can spend months researching data, and then more months trying to impose realistic data on the air file, that no one will ever benefit from, even if the FDE author succeeds. FSAviator

Share this post


Link to post
Share on other sites
Guest Ron Freimuth

"Creating FDE that closely replicate reality is all very well, and I heartily approve, but what is the point if the end user can never figure out how to observe the current power limit to within 20%? There is no earthly reason to create FDE that are better than the handling notes available to operate them by. Lose sight of that and an FDE author can spend months researching data, and then more months trying to impose realistic data on the air file, that no one will ever benefit from, even if the FDE author succeeds. FSAviator" I just added "Percent HP" to my Prop Test gauge. I had to set '200' HP as a constant in the gauge for the rated SL power. Then, it displays 75.1%, etc. So, it's easy to set to the standard HP percentages given in PoH's. The pilot doesn't have a Percent HP gauge and has to set RPM(FP) or RPM and MP for a CS prop and refer to tables to see what power level he is operating on. Though, HP is approximatly proportional to MP * RPM. (MP - 5") * RPM would be more accurate since at 5" the engine is just idling. With a FP prop, RPM is critical. Just 20 RPM change will change HP quite a bit. There is a big difference flying at 2400 vs 2500 RPM in a FP PA 28. Maybe enought so one runs out of fuel an hour sooner at 2500 than 2400 RPM. You can't trust cheap AC fuel gauges, so had better know what GPH a given RPM is giving on longer flights, especially in bad weather. I already calculate 'drag' in my XML test gauges with equivalent formulas to what FS uses (I have to add a few more constants, such as Cdo, S, b, and e in Prop Test). I've been seeing Drag within a fraction of 1% of Thrust in both a prop AC and two jet transports. Reciprocating engines are typically rated on percent HP for TO (5 min) vs continuous. Though, normally aspired engines can be run at 100% -- they just don't last as long. And, use a lot more fuel, since the mixture has to be rich at that level. Turbines are more complex. T.I.T., EGT, EPR don't mean much if they aren't accurate. It appears a more general indication of how close the turbine is operating to its cont or 5 minute rating is Fn/delta. Where Fn is Net Thrust and delta is air pressure relative to SL. There is some question as to wheter ambient or total pressure is most applicable, but my Boeing Manual uses ambient. I now calculate and display Fnr, which is net thrust normalized to rated TO thrust and divided by delta. 0.90 would be about the low altitude limit for continuous, but Boeing shows the ratio increases about 10% at maximum Mach numbers. When I used my Jet Test gauge on an AC with close drag and SFC settings that's about what I saw. 'Fnr' increased about 10% above the 0.90 SL continuous rating at FL 350. Turbines have RPM, Temperature, and EPR limits. RPM may be limiting at times, EGT or EPR at others. RPM might hit its limit on hot days, that's not hard to understand. But just how thurst limit is related to EGT, EPR, or ITT isn't so obvious. Clearly temperature will degrade the engine. But, just what combination of a single temperature reading combines with other stresses at a given thrust and ambient pressure would depend on internal details of the unit. Perhaps the main point wrt turbines is that some theoretical understanding and readings aid in setting the AIR file tables so they are most consistent with various thrust limits. Ron

Share this post


Link to post
Share on other sites
Guest airhead

Wow, I didn't think I was gone that long, but see this thread has tripled in size since my last visit.Unfortunately, shortly after my last post I received a phone call in regards to the passing of a close family member and have been unable to get back here to keep up with the info in this thread until today.I would like to thank all who have contributed here, I have learned a lot so far and am trying to learn more as I read through the new postings. This thread has brought me to the painful realization that I may not be the best person to author FDE, yet I still forge onward. I feel I know so little, and the literal mountain of information, knowledge and experience needed to write good FDE may very well be beyond me. I suppose that is why many FS developers choose a specific aspect of development and stick with it. That being said, I am still glad to see that those "in the know" are so willing to assist and impart their vast knowledge of flight dynamics on noobs such as myself. :)One quick question I do have that maybe someone can answer. I have seen some of you make reference to a set of testing gauges and an associated panel/panel.cfg for working with FDE. Could someone point me to the place where I can acquire the aforementioned? Seems like it is a very useful, possibly necessary tool, and I'm hoping it may help me out a bit.Again, thanks for the assitance guys, know that it is sincerely appreciated.

Share this post


Link to post
Share on other sites
Guest _FSAviator

Greetings 'Airhead',I was sorry to hear of your recent loss.This reply also for the benefit of a wider audience.The only FDE testing utility you are likely to need is AFSD by Herve Sors.http://perso.wanadoo.fr/hsors/FS_Soft/index.htmlAFSD is a freeware real time updating spreadsheet divided into pages that track particular attributes of the FDE. Different versions of MSFS may require different versions of AFSD. Some of the values it reports are direct reads from memory and others are the product of its own equations which assume that MS assigned a particular value to a particular constant which appears within the equation. It may therefore have minor inaccuracies that are impossible to resolve, but it should nevertheless meet all your needs. FDE are usually developed before a panel (or MDL) exists. It may take a long time to get all the bugs out of the candidate release panel especially if the panel maker is not a gauge author. In most cases the candidate release panel is hardly used during FDE development. It will be integrated later as a separate process.Instead a test panel is used in conjunction with AFSD. The test panel houses all the input gauges you may need, including an easy to use multi function autopilot, and the output gauges which relate to all the functions which are not on the current page of AFSD. It will be used for many aircraft and is not specific to one. You need a different test panel for each flight model and for each version of the sim you intend to develop for. You create it yourself in whatever layout you find easiest to use. A monotonal rectangular half screen bitmap is fine. It has to be large enough to hold a lot of gauges.Digital gauges are more likely to be useful than analogue. The key requirement is that the gauges are WYSIWYG for that flight model and that version of the sim. It is up to you to create the gauges or else to test whether existing gauges have bugs, have display scalars, or do not work with the version you are developing FDE for. Unfortunately you cannot assume that default MS gauges are accurate enough for FDE development. Some have significant errors. Many gauges in third party releases do not work except in relation to the specific FDE which were written to drive them, or outside the version of the sim for which they were made. However many gauges made for the CFS range of products are WYSIWYG in FS9. It is up to you to ensure that the gauges used during FDE development work correctly and are not distorting either input or output. For instance you will need to check whether 'rpm' gauges display engine or airscrew rpm, and so on. You can test whether the gauges you may wish to use in a test panel are WYSIWYG using AFSD as the comparator. It will be at least as accurate as any gauges that you may obtain. If the project has no gauge author, the FDE author may also need to add candidate release gauges to the test panel for beta testing against the reference gauges, either to ensure that they read the same or to ensure that they have the desired offsets. You may for instance need to compare flap deployed in degrees versus flap deployed in stages to see that they match in bitmap display terms as well as internally within the code, and so on. FSAviator

Share this post


Link to post
Share on other sites
Guest airhead

Hello FSAviator,>> I was sorry to hear of your recent loss.Your sympathy is appreciated. Thank you.My mistake, AFSD was the item I had in mind when I posted. I guess I wasn't exactly sure what "it" was. While poking around at Herve's site, I did come across what I believe made me think of the panel. Apparently Jerry Beckwith developed a testing panel for FS2002 containing numeric readouts for relevant input/output data for use when working through FDE. Sorry for the mix-up. I have no idea if it is still good for use with FS9, but I would assume so if it doesn't taint the values at all. If it doesn't work, I may give it a go myself in XML.As always, your offerings of information and assitance are appreciated. Don't be a stranger... :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...