-
Notifications
You must be signed in to change notification settings - Fork 454
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fixing the mixture for JSBSim piston aircraft #1037
Comments
Thanks @hbeni for submitting this issue. I'm a bit curious about where this equation is coming from ? Can you document it ? At the moment, as far as I can tell (I'm no specialist in internal combustion engines) this diff is replacing some magic numbers by other magic numbers. Are the new values applicable to all piston engines under the sun ? |
So you're proposing to change |
Yep, in addition I don't see the point in modifying the C++ code as the same result could be achieved using a <channel name="Mixture control">
<fcs_function>
<function>
<product>
<value>1.27</value> <!-- 1.65 / 1.3 -->
<sqrt>
<property>fcs/mixture-cmd-norm</property>
</sqrt>
</product>
</function>
<output>fcs/mixture-pos-norm</output>
</fcs_function>
</channel> |
@dany93 could you comment on this topic ? |
I'm not inventing anything here as this is done in a number of our aircraft. See the 6 examples below: Lines 521 to 551 in 92daf89
jsbsim/aircraft/Camel/Systems/automixture.xml Lines 7 to 67 in 92daf89
jsbsim/aircraft/p51d/Systems/mixture-control.xml Lines 27 to 61 in 92daf89
jsbsim/aircraft/Short_S23/Systems/engines.xml Lines 145 to 170 in 92daf89
jsbsim/aircraft/ZLT-NT/Systems/engine-control.xml Lines 263 to 278 in 92daf89
jsbsim/check_cases/piston_takeoff/aircraft/c172x/c172x.xml Lines 237 to 257 in 92daf89
|
I did post this back to the discussion on the forums: https://forum.flightgear.org/viewtopic.php?p=419011#p419011 |
I have some experience on ultralights only, I fully trust David Megginson on the mixture subject. However, I notice:
I would rather agree with @bcoconni. Modifying the C++ code can have negative effects on current aircraft. |
The issue with the current c++ code is, you cant go richer than the current 1.0 setting. Davids patch fixes this. |
Maybe another alternative, if you dont want to change it directly in the code for all aircraft, add in a factor read optionally from another new property, so aircraft can implement this. |
Not sure what you mean by that. But the properties I've checked by modifying the script diff --git a/scripts/c1721.xml b/scripts/c1721.xml
index 461cb93e..a02eea93 100644
--- a/scripts/c1721.xml
+++ b/scripts/c1721.xml
@@ -8,10 +8,19 @@
<event name="event name">
<condition>simulation/sim-time-sec ge 0.25</condition>
<set name="fcs/aileron-cmd-norm" action="FG_STEP" value="0.25" tc="0.25"/>
+ <set name="fcs/mixture-cmd-norm" action="FG_STEP" value="-15.3" tc="0.25"/>
+ <notify>
+ <property>fcs/mixture-cmd-norm</property>
+ <property>fcs/mixture-pos-norm</property>
+ </notify>
</event>
<event name="event name">
<condition>simulation/sim-time-sec ge 0.5</condition>
<set name="fcs/aileron-cmd-norm" action="FG_EXP" type="FG_DELTA" value="0.5" tc="0.5"/>
+ <notify>
+ <property>fcs/mixture-cmd-norm</property>
+ <property>fcs/mixture-pos-norm</property>
+ </notify>
</event>
<event name="event name">
<condition>simulation/sim-time-sec ge 1.5</condition> Script output:
|
Okay, understood. Thank you for elaborating - but more info on the wiki would be good. I think there just was a misconception about the clamping - the clamping in the 172p comes from the direct transmisison of the lever position (which is clamped to 1.0 for animation reasons). In c172p.xml: <fcs_function name="fcs/mixture-unit-cmd">
<function>
<product>
<value>1.27</value> <!-- 1.65 / 1.3 -->
<sqrt>
<!--<property>fcs/mixture-cmd-norm</property>-->
<property>/controls/engines/current-engine/mixture</property>
</sqrt>
</product>
</function>
<output>fcs/mixture-cmd-norm[0]</output>
<output>fcs/mixture-cmd-norm[1]</output>
</fcs_function> Does what the C++ patch would do. |
See: - Forums post from Davod Megginson: https://forum.flightgear.org/viewtopic.php?f=49&t=42055 - JSBSim discussion: JSBSim-Team/jsbsim#1037
From the Forums:
|
So, David said he will get on touch and comment here. But he also already did elaborate extensively in the forums, so the tldr is:
|
First, apologies that this is a complex topic. Leaning mattered a lot to me during my 19 years of flying, because it affected my fuel reserves for long IFR flights, but I know it's not something non-pilots pay much attention to. The JSBSim code is designed right now so that (by default) full rich mixture (1.0 input from FlightGear) is clamped to approximately peak power (see diagram below). That would make sense to a physicist — why would anyone want to use more fuel to produce (relatively) less power? — but it's completely wrong from an engineering PoV. The problem is that petroleum (avgas) piston engines risk predetonation if internal cylinder pressure gets too high — that means that the fuel/air mixture ignites before the spark fires, throwing off the timing. In the best case scenario, that means tens of thousands of dollars in premature engine overhauls; in the worst case, catastrophic in-flight engine damage. As a result, all petroleum/avgas piston engines (at least since the 1930s) are designed so that they fly somewhat inefficiently when the mixture is advanced to full rich. That means that when someone is using full takeoff power (typically above 75%), the internal cylinder pressure won't get as high (the diagram shows CHT, which is a proxy for internal pressure, since its curve is identical). Once in cruise, at 75% power or below, the pilot can lean to a more-efficient fuel/air mixture. For higher-elevation takeoffs, where a normally-aspirated engine can't make above 75% power anyway, the recommendation is to lean for takeoff precisely so that the pilot will have the maximum power available. So in real life, you will always see an increase in power (using RPM as a proxy with a fixed-pitch prop) as you start to lean, before the power drops again. With JSBSim aircraft, you do not see that unless the aircraft designer has deliberately kludged around this bug. I strongly recommend that we fix this in the FDM itself, rather than relying on each aircraft designer to kludge around it, because we'll end up with more-consistent realism for our piston aircraft. I also suggest making this change only in the FlightGear 4.0 candidate codestream (leave the current 3.0 production release alone), so that aircraft designers who have used kludges can undo them and rely on the correct behaviour from the FDM itself. Here is the chart. I lived and breathed (and staked my life on it) for many years of flying my former PA-28-161. I'll be happy to answer any questions. And please note that I'm not asserting that my patch is the best possible one; only that it produces the expected behaviour in FlightGear, while the current JSBSim FDM does not. Please feel free to substitute a better patch that produces the same behaviour. If the behaviour is correct, then putting the parking brake on (e.g.) the Cessna 172p, advancing the throttle to full, then gradually leaning should show a noticeably increase in RPM as you lean, before the RPM starts falling again. David out. |
Many thanks, @davidmegginson for this superb explanation. I was totally unaware of this point prior to this discussion. Now, I agree with you and @hbeni, the best solution is to fix it in the JSBSim code. I have a question:
I believed that the self-detonation (which causes predetonation) was firstly due to the pressure increase by the piston (which gives a temperature increase for the gas mixture). Like in Diesel engines, where there are no sparking plugs. Does your explanation means that the self-detonation (predetonation) will not happen when the mixture is inefficient, too rich here? |
I agree that leaning behavior is important in any piston and therefore to appropriately capture in JSBSim. (Ever have one start running rough until you burn off some carbon on the plugs by running lean? That would be harder to simulate).
I think that the outstanding question is whether it is something that should be captured at the airplane model level (xml) or the overall JSBSim level (c-code). You think that one seems like a kludge, while the other could break many existing models.
…--Adam
On Feb 16, 2024, at 11:44 AM, David Megginson ***@***.***> wrote:
First, apologies that this is a complex topic. Leaning mattered a lot to me during my 19 years of flying, because it affected my fuel reserves for long IFR flights, but I know it's not something non-pilots pay much attention to.
The JSBSim code is designed right now so that (by default) full rich mixture (1.0 input from FlightGear) is clamped to approximately peak power (see diagram below). That would make sense to a physicist — why would anyone want to use more fuel to produce (relatively) less power? — but it's completely wrong from an engineering PoV.
The problem is that petroleum (avgas) piston engines risk predetonation if internal cylinder pressure gets too high — that means that the fuel/air mixture ignites before the spark fires, throwing off the timing. In the best case scenario, that means tens of thousands of dollars in premature engine overhauls; in the worst case, catastrophic in-flight engine damage.
As a result, all petroleum/avgas piston engines (at least since the 1930s) are designed so that they fly somewhat inefficiently when the mixture is advanced to full rich. That means that when someone is using full takeoff power (typically above 75%), the internal cylinder pressure won't get as high (the diagram shows CHT, which is a proxy for internal pressure, since its curve is identical). Once in cruise, at 75% power or below, the pilot can lean to a more-efficient fuel/air mixture.
For higher-elevation takeoffs, where a normally-aspirated engine can't make above 75% power anyway, the recommendation is to lean for takeoff precisely so that the pilot will have the maximum power available.
So in real life, you will always see an increase in power (using RPM as a proxy with a fixed-pitch prop) as you start to lean, before the power drops again. With JSBSim aircraft, you do not see that unless the aircraft designer has deliberately kludged around this bug.
I strongly recommend that we fix this in the FDM itself, rather than relying on each aircraft designer to kludge around it, because we'll end up with more-consistent realism for our piston aircraft. I also suggest making this change only in the FlightGear 4.0 candidate codestream (leave the current 3.0 production release alone), so that aircraft designers who have used kludges can undo them and rely on the correct behaviour from the FDM itself.
Here is the chart. I lived and breathed (and staked my life on it) for many years of flying my former PA-28-161. I'll be happy to ask any questions.
And please note that I'm not asserting that my patch is the best possibly one; only that it produces the expected behaviour in FlightGear, while the current JSBSim FDM does not. Please feel free to substitute a better patch that produces the same behaviour. If the behaviour is correct, then putting the parking brake on (e.g.) the Cessna 172p, advancing the throttle to full, then gradually leaning should show a noticeably increase in RPM as you lean, before the RPM starts falling again.
David out.
Leaning.diagram.png (view on web) <https://github.com/JSBSim-Team/jsbsim/assets/2810060/77c5d714-32b4-4e43-a7a5-9ea51cfd9f73>
—
Reply to this email directly, view it on GitHub <#1037 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQ44XHSTGIES3EINBKNMBTYT6EFFAVCNFSM6AAAAABDDRWNE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBYHA2TQMJUHA>.
You are receiving this because you are subscribed to this thread.
|
I think generic fundamentals like leaning behaviour should be simulated at the generic piston simulation level (jsbsim). |
This is similar to the effect of running out of gas, you know, when the engine starts to perform even better and revs up right before it dies. Is this simulated in the JSB code? Also choking the engine can buy you fractions of a second more as it drains the system. Interesting subject! |
Also fuel vapor forming could be simulated... Alot of things spring to mind. |
I understand this from an operational PoV rather than a theoretical one, so I'll share what I know. Generally speaking, we use EGT as the reference, because exhaust-gas-temperature gauges were formerly cheaper and easier to install (CHT requires probes right in the cylinders), though they're also less accurate. Peak EGT is where the EGT curve is highest on the chart I shared earlier; use the temperature scale on the top right to figure out how many degF lean of peak (LOP) or rich of peak (ROP) EGT you are elsewhere on the curves. As you'll see in the chart, the CHT (and internal pressure) curve peaks at about 50 ROP, while the power curve peaks at about 100 ROP. Those two are very close in terms of movement in the mixture knob or lever, and the odds are that not all cylinders are in exactly the same place on the curve, so the general cruise-leaning recommendation for pilots not using a modern, all-cylinder engine monitor is either to lean to peak power and then enrich slightly (which is easier with a fixed-pitch prop), so that you land around 150 ROP or richer, or to lean right past peak EGT to the LOP side; the challenge with the latter is that the power curve falls off much more steeply on the lean side than it does on the rich side, so if the fuel/air distribution to the cylinders is too uneven, the engine will run very rough LOP (I was able to do it in my former Piper PA-28-161 with a four-cylinder Lycoming O-320, but most pilots with carbureted six-cylinder engines are not). So back to the question of why you don't get predetonation with a full-rich mixture and full throttle at sea level. The pressure still increases, of course, as the cylinder compresses the mixture, but — and I'm on shaky ground here in the theoretical stuff — with more fuel and less air, the mixture doesn't ignite as easily, perhaps because the fuel is less compressible, or perhaps because of the lower temperature, as someone else mentioned (??? help me here — I'm flailing when I get into the theory). So you don't get the pre-ignition before the plug fires. When the engine is producing less power (below 75%), the compression cycle is happening more slowly, and perhaps that makes the difference. But again, I'm a pilot, not a theoretician. If you want to dive deeply into this stuff, Mike Busch has written dozens of videos and articles and several books around the topic, so you can do a quick search for his name together with "leaning". I used to own his hefty, 508-page book on piston engines, but I donated it to my local flying club when Transport Canada took away my medical and I had to sell my plane. |
There is an open Issue from 2018 that is related, if not the same. It's regarding the peak power, mixture, and exhaust temp. #96 (also posted to c172p-team/c172p#1128). In this other comment, Sean graphed the power output #116 (comment):
/ So you can see there clearly a prior issue with the engine. Lets figure out how to solve it. If I look at the Mixture_Efficiency_Correlation table here and then map it to a graph, it's appears to be fairly decent curve that's similar enough to what's expected of a real world engine. jsbsim/src/models/propulsion/FGPiston.cpp Lines 333 to 350 in 32d2c3b
So the mixture table doesn't appear to be the culprit. Although it was added in 2008 with this commit: Added Ron Jensen's piston engine model changes. While at the same time a Power_Mixture_Correlation table was removed and some code altered in the DoFuelFlow. David's fix seems to be in the correct general area of code. But as asked twice before, where did the original If no one knows exactly, then it could take some time for members to investigate and re-solve where that math comes from in DoFuelFlow. Edit: Also the horsepower is able to reach over 250 in flight when the engine file states maxhp of 160? Seems a little excessive which further suggests there is some miscalculation happening. |
Thank you @davidmegginson for your response. |
The 1.3 is the original factor for multiplying the mixture-control input (0.0 - 1.0) to map into the mixture table. I gave it 1.65 instead, because that seems to give about the right RPM drop rich of best power in the Cessna 172, but it's based on trial-and-error. So far, aircraft designers and pilots in the forum have reported that the behaviour seems reasonable. The sqrt was just a response to pilots who find the mixture movement a bit unrealistic (cutoff too early). Since it's a feel thing, I have no objection to removing it, and letting it be handled in the joystick configuration. Obviously, sqrt(0.0) is still 0.0, and sqrt(1.0) is still 1.0, so you get the full range from lean-cutoff to full rich, but sqrt(0.5) for example is about 0.7, so it ensures that the you can make finer adjustments to the mixture in the functional range before you hit cutoff. |
This has been fixed by the PR #1048 which has just been merged in the |
I think the docs were correct, since all of the other control inputs (AFAIK) are normalised to between 0.0 and 1.0 (or -1.0 and 1.0), but we do need to allow a exception to work around this specific issue. |
@davidmegginson Flightgear and the c172 nasal engine file are clamping the mixture to 0.0 to 1.0. There is no JSBSim code that is clamping or normalizing the mixture controls to 1.0. https://github.com/FlightGear/flightgear/blob/cf4801e11c5b69b107f87191584eefda3c5a9b26/src/Aircraft/controls.cxx#L822-L832 I realize this link is a three year old copy of flightgear and I have no idea if this code is current or relevant but I'm using it as an example, since sourceforge files are not able to be searched without downloading the files. And here's one part of the c172 nasal script that is also clamping the mixture input. (I saw three locations total in the script) The mixture being clamped/normalized is by Flightgear & c172p model. You can start up a standalone JSBSim and easily set the mixture to any amount you wish. That being said, as I mentioned in another comment - there is already an open Issue with JSBSim from 2018 regarding the engine model which shows the same issue you've mentioned. The engine issue is also noted and open in the c172p repository. I recently spent some time checking the engine model code and checking line by line the expected results and verifying each formula. I opened a copy of "The Internal-Combustion Engine in Theory and Practice. Vol. I_ Thermodynamics, Fluid Flow, Performance" by Charles Fayette Taylor. I didn't see any glaring issues but I'm still investigating, which is why I have not posted any comments or results yet. To be honest there are some questionable parts of the engine model code, such the indicated horsepower is equal to the fuel flow rate * mixture efficiency, but fuel flow is determined from air flow, which is determined from RPM, and RPM is determined from horsepower... Seems a bit of feedback loop between the horsepower and fuelflow, and might be the cause of the slightly overrich conditions as noted in the 2018 issue. And it's why you notice the engine already being too lean at full rich, because the curve is being cutoff from being overly rich to begin with. So until someone can prove a solution which fixes the AFR and thereby giving a normalized access to the full mixture curve, then any suggestions to fix only the mixture input value is just another workaround, which no one wants. Sean mentioned he would investigate the engine model and I'm still investigating it. I'm not sure what else you want. No one has disagreed that there is a engine model/mixture issue. |
Its not flightgear itself clamping the value. Its basicly the input mappings. If done in the plane, you can easily exceed |
Everyone wants to avoid that. There's an Open engine Issue I linked 16 comments prior. I'm going to focus on solving that problem, which includes the mixture issue. |
I agree, let's figure out the root cause(s) and work on those as opposed to adding band-aids. |
There's really no need to look further for a root cause:
There's lots else we could improve in the piston engine model, but this isn't a difficult bug, and I've been a bit puzzled that it became controversial; it took me only a few minutes to diagnose,even though I'm not very familiar with the JSBSim code. (thanks to a helpful comment in the source where the original coder documented their assumption — +1 for good commenting practice). |
Just a couple of initial/immediate issues/questions. If you take a look at the graph I generated you see engine power hitting ~200hp for a mixture-pos of 1.0, and peaking around ~215hp for a mixture-pos of ~1.1, whereas the engine file as mentioned by @gallonmate mentions a max of 160hp. How accurate and representative is the mixture efficiency correlation table? The earlier issue and the graph, repeated above, with regards to the plot of power versus AFR and it's relative shift compared to the wikipedia example? |
David, Changing the multiplier to Here's a summary of changing the multiplier- Potential Issues per aircraft: You have two people that volunteered to investigate the issues. But instead you just say: "There's really no need to look further for a root cause". That's great that you've solved the leaning behavior for manual mixture piston aircraft and that you're happy with the results. It's not great that you're continuing to ignore everything else about the effects of the |
Ah, that's interesting -- thanks. Based on the original coder's comment, I'd thought that it was just a multiplier for a reference into the lookup table. And yes, I've never heard of an aircraft piston engine that clamped full-rich mixture to peak power, because such an engine would wear out quickly (or even eventually tear itself apart) at full/takeoff throttle power (peak power is just barely rich of peak CHT) — when you open up the throttle all the way near sea level it needs to well rich of peak power to inhibit predetonation. Rich of peak power is the common fail-safe for the "full rich" mixture setting, which is why at higher-elevations airports you need to carefully lean to peak power for takeoff (as you'll see in numerous articles from AOPA and other aviation sources) — if you tried to take off from Leadville CO without leaning with a normally-aspirated piston engine to peak power, for example, you'd probably never escape ground effect. There could be some very early (1920s or 1910s) aircraft engines that set up the mixture different, and FlightGear aircraft designers could treat them as special cases, but overwhelmingly JSBSim is displaying the wrong default behaviour for nearly every piston engine, and we need to shift it. |
Isn‘t a good way forward to note Davids experience and conclusion into the other 2018 engine overhaul issue, and then fix them together in one merge, so aircraft devs can adapt to a consistent single change to the engine model? |
That's been our point all along, i.e. let's look at all these issues together to see how they interact and then decide on the best way forward as opposed to being pressurized into a quick fix of "just take David's fix and incorporate it.". |
@seanmcleod wrote
I understand that this is the graph in this message. I don't know how you got this 200 hp value for power, but I checked several times in the simulator and found that the |
@dany93 here is my procedure and script that I used to generate the graph. So in broad strokes I used a script which placed the C172p on the ground, trimmed for ground, set the brakes on, started the engine with Then output a number of engine parameters after 10s and after 30s, in case there was some lag, and used the 30s figures as input for the graph. Here is a copy of my script: <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="http://jsbsim.sourceforge.net/JSBSimScript.xsl"?>
<runscript xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://jsbsim.sf.net/JSBSimScript.xsd"
name="C172p mixture test">
<description>This run is for testing the C172 mixture</description>
<use aircraft="c172p" initialize="groundreset"/>
<run start="0.0" end="500" dt="0.0083333">
<event name="Start engine">
<condition>
simulation/sim-time-sec ge 0.01
</condition>
<set name="fcs/throttle-cmd-norm" value="1.0" />
<set name="fcs/mixture-cmd-norm" value="1.0" />
<set name="propulsion/magneto_cmd" value="3"/>
<set name="propulsion/starter_cmd" value="1"/>
<set name="fcs/left-brake-cmd-norm" value="1.0" />
<set name="fcs/right-brake-cmd-norm" value="1.0" />
<notify/>
</event>
<event name="Trim">
<condition>
simulation/sim-time-sec gt 1.0
</condition>
<set name="simulation/do_simple_trim" value="2"/>
<notify>
<property> velocities/u-aero-fps </property>
<property> velocities/v-aero-fps </property>
<property> velocities/w-aero-fps </property>
<property> position/h-agl-ft </property>
<property> propulsion/engine/thrust-lbs </property>
<property> propulsion/engine/propeller-rpm </property>
<property> fcs/throttle-pos-norm[0] </property>
<property> fcs/throttle-cmd-norm[0] </property>
<property> velocities/vc-kts </property>
<property> fcs/mixture-pos-norm[0] </property>
<property> propulsion/engine/power-hp </property>
<property> propulsion/engine/AFR </property>
<property> propulsion/engine/egt-degF </property>
<property> propulsion/engine/engine-rpm </property>
<property> propulsion/engine/fuel-flow-rate-gph </property>
</notify>
</event>
<event name="Update">
<condition>
simulation/sim-time-sec gt 10.0
</condition>
<notify>
<property> velocities/u-aero-fps </property>
<property> velocities/v-aero-fps </property>
<property> velocities/w-aero-fps </property>
<property> position/h-agl-ft </property>
<property> propulsion/engine/thrust-lbs </property>
<property> propulsion/engine/propeller-rpm </property>
<property> fcs/throttle-pos-norm[0] </property>
<property> fcs/throttle-cmd-norm[0] </property>
<property> velocities/vc-kts </property>
<property> fcs/mixture-pos-norm[0] </property>
<property> propulsion/engine/power-hp </property>
<property> propulsion/engine/AFR </property>
<property> propulsion/engine/egt-degF </property>
<property> propulsion/engine/engine-rpm </property>
<property> propulsion/engine/fuel-flow-rate-gph </property>
</notify>
</event>
<event name="Update">
<condition>
simulation/sim-time-sec gt 30.0
</condition>
<notify>
<property> velocities/u-aero-fps </property>
<property> velocities/v-aero-fps </property>
<property> velocities/w-aero-fps </property>
<property> position/h-agl-ft </property>
<property> propulsion/engine/thrust-lbs </property>
<property> propulsion/engine/propeller-rpm </property>
<property> fcs/throttle-pos-norm[0] </property>
<property> fcs/throttle-cmd-norm[0] </property>
<property> velocities/vc-kts </property>
<property> fcs/mixture-pos-norm[0] </property>
<property> propulsion/engine/power-hp </property>
<property> propulsion/engine/AFR </property>
<property> propulsion/engine/egt-degF </property>
<property> propulsion/engine/engine-rpm </property>
<property> propulsion/engine/fuel-flow-rate-gph </property>
</notify>
</event>
</run>
</runscript> And here is the output for Update (Event 3) executed at time: 30.008213
velocities/u-aero-fps = 0.000002
velocities/v-aero-fps = -0.000010
velocities/w-aero-fps = -0.000002
position/h-agl-ft = 4.336028
propulsion/engine/thrust-lbs = 473.735175
propulsion/engine/propeller-rpm = 2538.157833
fcs/throttle-pos-norm[0] = 1.000000
fcs/throttle-cmd-norm[0] = 1.000000
velocities/vc-kts = 0.000000
fcs/mixture-pos-norm[0] = 1.000000
propulsion/engine/power-hp = 205.892919
propulsion/engine/AFR = 11.305920
propulsion/engine/egt-degF = 1427.738788
propulsion/engine/engine-rpm = 2538.157833
propulsion/engine/fuel-flow-rate-gph = 11.666088
End: Friday March 08 2024 11:08:25 (HH:MM:SS)
(base) C:\source\jsbsim> So for this case I see I've just double-checked the engine being used: <propulsion>
<engine file="eng_io320"> And from <piston_engine name="IO320">
<minmp unit="INHG"> 10.0 </minmp>
<maxmp unit="INHG"> 28.5 </maxmp>
<displacement unit="IN3"> 320.0 </displacement>
<maxhp> 160.0 </maxhp>
<bsfc> 0.32 </bsfc>
<cycles> 4.0 </cycles>
<idlerpm> 550.0 </idlerpm>
<maxrpm> 2700.0 </maxrpm>
<maxthrottle> 1.0 </maxthrottle>
<minthrottle> 0.1 </minthrottle>
<sparkfaildrop> 0.1 </sparkfaildrop>
</piston_engine> Just to be clear, I'm using just the JSBSim repo, not any C172p version that may be bundled with FlightGear. I haven't checked to see if there are any differences between the C172p in the JSBSim repo compared to FlightGear. |
With the c172p from the github rep, I find for the 160 hp engine |
Hmm, that's a massive difference. And if you run the script above what result do you get? |
I don't think it comes from your script. From the c172p version that you use? Out of my memory, I checked the power hp values vs the config file ones on several JSBSim aircraft. Anyway, testing on the ground is not the correct way to check the max power hp at max rpm. But this is another subject. |
I don't have FlightGear installed. It would be useful to know what output you get from the script on your system if you use the JSBSim version bundled with your FlightGear installation, and how those compare to the properties reported via FlightGear compared to the script outputs. |
Sorry, I don't have the time to try this. |
Came across the following diagram online, not sure of the provenance of it, but basically looks like the Lycoming O-360, but with actual FAR values for the x-axis. I've annotated it in red to add AFR values. Matches up fairly well with the Wikipedia diagram of power versus AFR. Max CHT occurring around ~14.7 AFR. Lastly another potentially useful graph for the IO-360. |
@bcoconni found one difference between the JSBSim repo and the repo used for the C172p for FlightGear. If jsbsim/src/models/propulsion/FGPiston.cpp Lines 278 to 285 in b9bfc23
So commenting out Update (Event 3) executed at time: 30.008213
velocities/u-aero-fps = 0.000002
velocities/v-aero-fps = -0.000007
velocities/w-aero-fps = -0.000001
position/h-agl-ft = 4.342310
propulsion/engine/thrust-lbs = 354.437263
propulsion/engine/propeller-rpm = 2195.434759
fcs/throttle-pos-norm[0] = 1.000000
fcs/throttle-cmd-norm[0] = 1.000000
velocities/vc-kts = 0.000000
fcs/mixture-pos-norm[0] = 1.000000
propulsion/engine/power-hp = 133.243817
propulsion/engine/AFR = 11.305918
propulsion/engine/egt-degF = 1427.738632
propulsion/engine/engine-rpm = 2195.434759
propulsion/engine/fuel-flow-rate-gph = 10.158791
propulsion/engine/map-inhg = 28.751743
End: Saturday March 09 2024 14:59:47 (HH:MM:SS) So a massive drop from 205.9hp to 133.2hp, a lot closer but not exactly the same figure that @dany93 reported. 133.2hp vs 136hp |
Hi, I find this a very interesting conversation. I worked at Rolls Royce Derby for a while as a Test Bed designer and I can assure everyone that a 'static engine test' is performed on EVERY engine. And is the only way to get accurate engine performance data. I use a static engine test bed in FG and test all my piston engines this way. So I take my engine to 7000ft and Full Throttle. AFR = 9,9 So I increase my AFR AFR = 10 So I decrease my AFR AFR = 9.8 So Max Power AFR is 9,9... So at 9.9 AFR fuel-flow-rate-gph =140.7 I'd simply like to be able to use an AFR of 9.9 at sea level. Simon |
Hi, jut wanted to know - what is the state of the dicussion? |
The problem lies at the heart of the piston engine calculations, which currently no one has solved. #96. The discussion continues there. I studied the engine calculations for a few days and was verifying the individual formulas used in the code, some of which came from the book "The Internal-Combustion Engine in Theory and Practice. Vol. I_ Thermodynamics, Fluid Flow, Performance". But I was not able to find a clear fault. The piston engine model appears to be custom made and a work-in-progress that was still evolving when the engine author stopped updating it. |
For a FlightGear user, the problem is further complicated by the fact that
some aircraft designers have added hacks to compensate for the
JSBPison-engine issues, while others haven't.
Again, a piston-engine power curve should look like the illustration
below. As you lean from full-rich mixture (from the right side of the
diagram, mixture=1.0, towards the left) the power produced initially
increases, then falls more steeply. A correct model will reproduce that
behaviour (which is universal), whatever is happening behind the scenes.
[image: image.png]
|
@davidmegginson it appears that Github doesn't handle embedded images in email comments so your illustration doesn't show up on Github. However, I'm pretty sure it's covered by the graph I included in an earlier comment above, see - #1037 (comment) |
Yes, that's the same power curve for a different engine -- thanks! I posted early in the morning, and mistakenly thought I was in a flightgear-devel mailing list thread rather than GitHub. :) tl;dr If the JSBSim piston-engine performance doesn't at least roughly follow the shape of those curves, then it's wrong, period. We're not talking about fine-tuning here — it's OK if it's off by a few degrees of CHT or EGT, or even a few horsepower, because no sim is perfect, and engines vary in real-life anyway because of wear-and-tear, carbon buildups, etc — but not following the general curves is like not having wings stall at some critical AoA. It's just blatantly unrealistic. |
Hi,
David Megginson found (and fixed) a bug in the mixture control.
See: https://forum.flightgear.org/viewtopic.php?f=49&t=42055
The text was updated successfully, but these errors were encountered: