jsbsim
jsbsim copied to clipboard
JSBSim-Team
Fixing the mixture for JSBSim piston aircraft
Hi, David Megginson found (and fixed) a bug in the mixture control.
See: https://forum.flightgear.org/viewtopic.php?f=49&t=42055
Over on the flightgear-devel mailing list, I've been discussing a patch to fix the mixture input for JSBSim piston-engine aircraft.
Right now, the mixture control in src/FDM/JSBSim/models/propulsion/FGPiston.cpp is incorrectly clamped so that 1.0 (full rich) sets the mixture to peak power efficiency. In real life, the mixture control continues a ways rich of peak power to avoid predetonation at high power/low density altitude, which is why you have to lean a little for takeoff above 3,000 ft DA (or so). Anyone who's flown a simple trainer like a Cessna 172 or Piper PA-28 also knows how the RPM will initially increase as you start leaning, before it decreases again, which doesn't happen with our current JSBSim piston aircraft.
diff --git a/src/FDM/JSBSim/models/propulsion/FGPiston.cpp b/src/FDM/JSBSim/models/propulsion/FGPiston.cpp
index 1e73a503d..c1c75bd57 100644
--- a/src/FDM/JSBSim/models/propulsion/FGPiston.cpp
+++ b/src/FDM/JSBSim/models/propulsion/FGPiston.cpp
@@ -752,7 +752,8 @@ void FGPiston::doAirFlow(void)
void FGPiston::doFuelFlow(void)
{
- double thi_sea_level = 1.3 * in.MixturePos[EngineNumber]; // Allows an AFR of infinity:1 to 11.3075:1
+ // use square root to increase sensitivity in the higher end
+ double thi_sea_level = 1.65 * sqrt(in.MixturePos[EngineNumber]); // Allows an AFR of infinity:1 to (no longer accurate) 11.3075:1
equivalence_ratio = thi_sea_level * 101325.0 / p_amb;
m_dot_fuel = (m_dot_air * equivalence_ratio) / 14.7;
FuelFlowRate = m_dot_fuel * 2.2046; // kg to lb
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 thi_sea_level from f2 to f1 below? As @bcoconni asked, where is this equation coming from?
Yep, in addition I don't see the point in modifying the C++ code as the same result could be achieved using a <channel> in the aircraft FCS.
<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>
The same result could be achieved using a
<channel>in the aircraft FCS.
I'm not inventing anything here as this is done in a number of our aircraft. See the 6 examples below: https://github.com/JSBSim-Team/jsbsim/blob/92daf8953c32a0a602ab0f48240a07c4a04aadb9/aircraft/c310/c310.xml#L521-L551 https://github.com/JSBSim-Team/jsbsim/blob/92daf8953c32a0a602ab0f48240a07c4a04aadb9/aircraft/Camel/Systems/automixture.xml#L7-L67 https://github.com/JSBSim-Team/jsbsim/blob/92daf8953c32a0a602ab0f48240a07c4a04aadb9/aircraft/p51d/Systems/mixture-control.xml#L27-L61 https://github.com/JSBSim-Team/jsbsim/blob/92daf8953c32a0a602ab0f48240a07c4a04aadb9/aircraft/Short_S23/Systems/engines.xml#L145-L170 https://github.com/JSBSim-Team/jsbsim/blob/92daf8953c32a0a602ab0f48240a07c4a04aadb9/aircraft/ZLT-NT/Systems/engine-control.xml#L263-L278 https://github.com/JSBSim-Team/jsbsim/blob/92daf8953c32a0a602ab0f48240a07c4a04aadb9/check_cases/piston_takeoff/aircraft/c172x/c172x.xml#L237-L257
I did post this back to the discussion on the forums: https://forum.flightgear.org/viewtopic.php?p=419011#p419011 Please note, I'm just the messenger here; David Megginson is the original source for this issue. I think he just has no access to github or so.
I have some experience on ultralights only, I fully trust David Megginson on the mixture subject.
However, I notice: @bcoconni wrote
Are the new values applicable to all piston engines under the sun ?
Yep, in addition I don't see the point in modifying the C++ code as the same result could be achieved using a <channel> in the aircraft FCS.
I would rather agree with @bcoconni. Modifying the C++ code can have negative effects on current aircraft. Using the FCS and adding some explanations in the wiki might be sufficient and less risky. With a piece of code as an example. Moreover, it is more flexible.
The issue with the current c++ code is, you cant go richer than the current 1.0 setting. Thus, you cant fix it using a channel ☝️
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.
The issue with the current c++ code is, you cant go richer than the current 1.0 setting.
Not sure what you mean by that. But the properties fcs/mixture-cmd-norm and fcs/mixture-pos-norm can be set to any real value, including higher than 1 or even lower than 0. AFAICS there is no code in JSBSim that caps the mixture properties to the [0;1] range.
I've checked by modifying the script scripts/c1721.xml as below. After having run the script, the properties fcs/mixture-pos-norm and fcs/mixture-cmd-norm return whatever value that they have been set to (-15.3 in the example below but 10.0 or 1.5345 work just as well).
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:
event name (Event 0) executed at time: 0.258323
fcs/mixture-cmd-norm = -15.300000
fcs/mixture-pos-norm = 0.000000
event name (Event 1) executed at time: 0.508313
fcs/mixture-cmd-norm = -15.300000
fcs/mixture-pos-norm = -15.300000
Okay, understood. Thank you for elaborating - but more info on the wiki would be good. Just tested this on the 172p, works as described.
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.
(It mus be done to mixture-cmd-norm, because the priming code currently already occupies the pos-norm property)
From the Forums:
You should need to lean to get max power at sea level — that's what I think confused whoever wrote that JSBSim code, who just assumed, wrongly but understandably, that you'd want the most-efficient fuel-air mixture when the lever/knob is at its maximum setting.
Aircraft piston engines have long been set up so that full-rich mixture is inefficient — you're burning more fuel than you should for the power you're producing, or, to put it another way, you're producing less power than you should for the amount of air being sucked into the engine. It's most obvious with a fixed-pitch propeller at full throttle, because you can see it on the tachometer. As you start to lean, the RPM will initially increase, then it will start to fall again as you keep pulling the mixture back.
That must seem confusing to a physicist, but there's a sound engineering reason behind it. Above about 75% power, you need to operate the engine inefficiently (excessively rich fuel/air mixture) to keep internal pressures from getting high enough to cause predetonation, where the fuel/air mixture ignites before the spark, throws off the engine timing, and can eventually tear the engine apart (or at least cause tens of thousands of dollars in premature wear).
So nearly all aircraft piston engines over the past century are designed in such a way that if the pilot simply pushes the throttle and mixture all the way in, they will get that inefficient mixture that keeps the pressure below limits when the engine is producing > 75% power for takeoff and initial climb (the exception would be the very few aircraft piston engines that have FADEC or some other kind of automated mixture control). I have hear that many Lycomings and Continentals also have an "enrichment" circuit that adds even more to that when the throttle is right at the stop, but I don't know about that.
There is no instrumentation for internal pressure, but CHT moves in lockstep with it, which is why many engine manuals use CHT as a limit (it's not the heat itself, though, but the pressure that's the main danger).
Once you're above 3,000 ft density altitude, a normally-aspirated piston engine can't produce a lot more than 75% power anyway, and peak CHT/pressure is a little lean of that point, which is why they recommend leaning for max RPM at that DA or higher.
D
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:
- its a bug, affecting all piston aicraft
- thus it should be fixed in jsbsim rather each individual Aircraft
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. Unfortunately, it will be an issue for (I hope a weak number of) current aircraft, but it is the best for the long term.
I have a question: David wrote
(...) 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
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. For me, the pressure increase always happen. Whatever the mixture is rich or lean.
Does your explanation means that the self-detonation (predetonation) will not happen when the mixture is inefficient, too rich here? Or is it due to the (relatively) lower cylinder temperature, resulting from the previous detonations with this mixture value?
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 https://github.com/JSBSim-Team/jsbsim/issues/1037#issuecomment-1948858148, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQ44XHSTGIES3EINBKNMBTYT6EFFAVCNFSM6AAAAABDDRWNE6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBYHA2TQMJUHA. You are receiving this because you are subscribed to this thread.
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).
I think generic fundamentals like leaning behaviour should be simulated at the generic piston simulation level (jsbsim). That simulation also should provide great flexibility so advanced stuff like spark plug fouling (or using other plugs, or other oil types, etc) can be implemented at the aircraft level.
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!
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. https://github.com/JSBSim-Team/jsbsim/issues/96 (also posted to https://github.com/c172p-team/c172p/issues/1128). In this other comment, Sean graphed the power output https://github.com/JSBSim-Team/jsbsim/issues/116#issuecomment-421064741:
I decided to compare the engine power output versus AFR.
I used the C172p aircraft model at sea-level with the engine running and brakes on and
fcs\throttle-cmd-norm = 1and then ramped thefcs/mixture-cmd-norm from 1.3 down to 0.7.To compare against the Wikipedia graph:
Just wondering whether the power peak appearing so far left around an AFR of 10 is related to this issue - https://github.com/JSBSim-Team/jsbsim/issues/96 ?
/
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. https://github.com/JSBSim-Team/jsbsim/blob/32d2c3b8831d932a4b2e83e6ae4d4082c3ffe1b8/src/models/propulsion/FGPiston.cpp#L333-L350
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 1.3 * mixture math come from and where does the 1.65 * sqrt(mixture) solution come from?
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. It is sufficient for me. Just curiosity, in case you would have known... :-)
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.
Thanks @gallonmate for reminding me I'd generated a graph showing the power output versus AFR a couple of years ago.
So in that vein, here is a repeat of the Lycoming example that @davidmegginson posted earlier, repeated in this reply to make it easier to compare to the updated graphs I generated for the C172p in the JSBSim repo.
JSBSim C172p
Unfortunately not as well laid out as the Lycoming graphs, but it should give you a good idea of the default setup in JSBSim at the moment and how it compares to the Lycoming 0-360.
In terms of the TSFC don't read too much into the particular values, unit wise I've divided gallons per hour by thrust-lbs, but rather the general shape compared to the Lycoming.
Is it just me, or doesn‘t the power courve looks „reversed“?
And should the „wontfix“ label be removed?
Is it just me, or doesn‘t the power curve looks "reversed“?
I don't think so. Maybe what's confusing is the massive drop-off in power after a MixturePos > 1.3?
And looking at the graphs I generated would you not get the effect David is looking for by mapping MixtureCmd [0, 1] to MixturePos [0.7, 1.3]?
I don't think so. Maybe what's confusing is the massive drop-off in power after a MixturePos > 1.3?
Ok, i see.
And looking at the graphs I generated would you not get the effect David is looking for by mapping…
I would, but the proposal to change the default range from David is based on the valid assumption that all piston engines currently have that wrong. Hence it should be fixed here in jsbsim and not in each individual Aircraft. This if course is backwards incompatible, but David proposed a way to deal with that; and its a bug, not a feature request. All Aircraft using this fdm have it wrong without manual intervention!
So in my opinion it would be good to merge this, and I make an heads up at the fgfs mailing list and newsletter. If you do decide that this wont happen, I can understand, but then please close this issue here, so we at least have an official closed case and I can start to file issues with the aircraft i know of. And also, please amnend the documentation with the knowledge here, so users reading the manual are knowing they need to something with their mixture coding to get a realistic mixture control.
In my mind it's too early to jump in and change it. I'm trying to get a better understanding of how JSBSim's engine model works the range of mixture inputs and how that compares to the Lycoming example for example.
So currently what happens with a MixtureCmd in the range of say [0.1, 0,.7] and how realistic is that compared to the Lycoming example?
Plus, what do the graphs look like that I produced above when David's suggested formula of double thi_sea_level = 1.65 * sqrt(in.MixturePos[EngineNumber]); is used?
the proposal to change the default range from David is based on the valid assumption that all piston engines currently have that wrong.
I haven't seen any evidence of this statement. All we got is one single piston engine mapping with a vague mixture scale i.e. Too lean, Lean, Rich, Full rich. How could one tell 1.65 is the correct scale from that ? All we got was:
it's based on trial-and-error. So far, aircraft designers and pilots in the forum have reported that the behaviour seems reasonable.
hence pretending this trial-and-error applies to all piston engines is a bit of a stretch.
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.
The latter statement seems more reasonable. One has to keep in mind that the whole point of using XML definition files is to let aircraft developers do the fine tuning and this is including that kind of things.
This of course is backwards incompatible, but David proposed a way to deal with that
Added to the fact that you can't properly substantiate the value you are submitting, backward incompatibility is a definitive showstopper. No matter what David suggested, JSBSim usage isn't limited to FlightGear and I don't want to deal with tickets here on JSBSim about "it used to work but it's no longer working" for the sole reason that you requested to change a number by another number that you couldn't properly substantiate.
All in all, this ticket is a perfect example of why magic numbers are evil. The initial author thought their number looked right, then someone comes to tell that a new number feels right, then someone else thinks that another number sounds right, etc. What will be the next ticket ? Replace 1.65 by 1.78 ? Then 1.78 by 1.57 ? And break backward compatibility several times in the process ? If we have no criteria other than the new number seems more right than the previous one, how could we make the decision ?
Magic numbers are evil and replacing a magic number by another magic number is even more evil.
please amnend the documentation with the knowledge here, so users reading the manual are knowing they need to something with their mixture coding to get a realistic mixture control.
The docs are indeed misleading in that they are telling that mixture should be in the [0.0 - 1.0] range and this needs to be clarified.
So granted that the current situation with the misleading statement that mixture should be in the [0.0 - 1.0] range does not give the global behavior that one should be expecting from real piston engines. However we'll have to live with this situation with an amended documentation because:
- The change would break backward compatibility.
- No one can give a new value built on solid foundations.
In addition, the proper way to address this issue is more likely to modify the scale of the table Mixture_Efficiency_Correlation so that the piston engine behaves correctly over the full mixture range [0.0 - 1.0]. I understand that is what @seanmcleod is currently investigating.
Hence it should be fixed here in jsbsim and not in each individual Aircraft.
In order to close this ticket with a suggestion that I hope will fit all parties, I'd suggest modifying the JSBSim glue code in FlightGear C++ code. More specifically the 2 following lines of code in src/FDM/JSBSim/JSBSim.cxx:
globals->get_controls()->set_mixture(i, FCS->GetMixtureCmd(i));
FCS->SetMixtureCmd(i, globals->get_controls()->get_mixture(i));
There you can convert the mixture value from JSBSim to any value that fits FlightGear. With that suggestion, you could change the conversion factor as often as you need and deal with backward incompatibility at your level.
then please close this issue here
Granted.