model carburettor heat + possibly carburettor icing

[tigert]

Now, I don't know how the flight modelling handles carburettor icing, or is it up to the aircraft modeller to do some "tricks" on the systems to model it?

Some food for our thoughts:

• http://www.skybrary.aero/bookshelf/books/823.pdf - INDUCTION SYSTEM ICING ON PISTON ENGINES AS FITTED TO AEROPLANES, HELICOPTERS AND AIRSHIPS
• http://www.skybrary.aero/bookshelf/books/659.pdf - Aircraft Icing Handbook

(these were linked from http://www.skybrary.aero/index.php/Piston_Engine_Induction_Icing)

Additional fun if we want to get a bit crazy is to model wing leading surface icing and such, but that might be a task for another issue :-)

[tigert]

Thanks for labeling

[wlbragg]

Leading edge wing icing sounds like a really good idea. Do they install any de-icing device on a Cessna?

[wezzer]

Thumbs up for this! Carburetor icing would be very nice to model in Flightgear. Actually, I have been sketching this feature for a while, but I'm still stuck in research phase: what is the actual icing rate of Lycoming O-320 and how much does applying of carb heat cause performance damage? So far the best technical document I've found is the carburetor icing graph, shown in the Skybrary PDF.

Leading edge icing would be cool also. I don't believe that Cessna 172's have much anti-icing devices installed... Maybe TKS (ref https://en.wikipedia.org/wiki/Ice_protection_system#TKS_Ice_Protection) in some luxury-models? But I would just model the icing and the surface temperature of the leading edge wing, so only anti-icing method would be to exit the icing conditions and see if the ice melts :-)

[gilbertohasnofb]

I don't believe that Cessna 172's have much anti-icing devices

I don't believe it has that at all! Particularly our Model P, which is a fairly old and humble model :smile:

[tigert]

I guess "icing" is two things.

• carburettor icing that is not the same as airframe ice, even though both of course can happen at the same time
• airframe ice which forms by moisture in air freezing to the aircraft surfaces. This can also cause engine trouble if the air intake freezes up. Then you can use carb heat as well, since you bypass the air filter in the front cowling and feed air to the engine in from over the exhaust pipes where it is warm, but also non-filtered. A compromise of a sort, but side effect is the escape from a blocked air filter.

C172 has a heated pitot tube which is required for night flying at least in Finland, and it is an anti-ice device of sorts of course.

The static port could maybe freeze up as well I guess, though it is on the fuselage side. It could freeze also if the static line has water after a wash for example and you fly in freezing weather, for example. There is the alternate static port to the rescue if that happens, I have been told that instruments work normally in that situation, but there is a delay in reaction as the static reference is inside the aircraft.

[gilbertohasnofb]

I am closing two older issues one older issue which is related to this one: #48 and #41

Also, we must implement a RPM drop if the Carb Heat lever is pulled.

[gilbertohasnofb]

Okay, so I started to play around with this. I wanted to find a function that would output a value between 0.0 and 1.0 that will control the icing factor (0.0 being no ice formation, 1.0 being very fast icing formation). Here is a carburettor icing graph for the 172:

As you see, it's not a simple graph to recreate with a elegant function, but I tried my best for it. First of all, I managed to create two functions for the what to expect at very low RPM and very high RPM, respectively:

They are made of two Gaussian functions (one for each axis) and then rotated a bit, and I think are reasonably enough close to the first graph.

So now instead of having two hard coded functions for RPM values above and below a threshold, I wanted to make the RPM to dynamically "shrink" those graphs. There are two "shrinking" factors in the graph above, one for each axis. For instance, for the x axis, the values of this factor should be 18.0 at low RPM and 9.0 at high RPM. This can be achieved with an arc tangent function:

I did the same for the y axis, and it works very well I think.

For those with GNU Plot, you can replicate the graphs above by using:

set xrange[0:110]
set yrange[0:90]
set ticslevel 0
set isosamples 50
set view map
set xtics 10
set ytics 10
set grid ytics lt 0 lw 1 lc rgb "#bbbbbb"
set grid xtics lt 0 lw 1 lc rgb "#bbbbbb"
set terminal wxt;set terminal wxt size 800,800

then set a RPM value and plot using:

RPM = 2300
RPMfactorX = 13.2 - 3.2 * atan ( (RPM - 2000) * 0.008)
RPMfactorY = 7.0 - 2.0 * atan ( (RPM - 2000) * 0.008)
f(x,y)=exp((0.8*x + 0.2*y - 45)**2/(-2*RPMfactorX**2)) * exp((0.2*x - 0.8*y + 28)**2/(-2*RPMfactorY**2))
splot f(x,y) with pm3d

I am using x as temperature in degrees Celsius and y as dew point temperature in degrees Celsius. Note that every time you change the variable RPM, RPMfactorX, RPMfactorY and f(x,y) also must be recreated. Basically you want to play with the RPM value in the block above and then paste the whole thing again.

In Nasal, it would be something like this:

var carb_icing = func {
  var rpm = getprop("/engines/active-engine/rpm");
  var dewpointC = getprop("/environment/dewpoint-degc");
  var airtempC = getprop("/environment/temperature-degc");
  var factorX = 13.2 - 3.2 * math.atan2 ( (rpm - 2000) * 0.008);
  var factorY = 7.0 - 2.0 * math.atan2 ( (rpm - 2000) * 0.008);  
  var carb_icing_rate = math.exp( (0.8*airtempC + 0.2*dewpointC - 45)**2 / (-2*factorX**2) ) * math.exp( (0.2*airtempC - 0.8*dewpointC + 28)**2 / (-2*factorY**2) );
};

This above is just an untested sketch, so don't take it too seriously.

[gilbertohasnofb]

Any opinions on this approach? Else I will go ahead and give this a go. Also, I am thinking about mapping this function into values from -1 and 1, so positive values will result in accumulation of ice in the carburettor (the higher the value, the faster it will happen) while negative values will result in melting of ice.

[onox]

@gilbertohasnofb Why do you use an arc function instead of simply blending the two 2D functions (according to RPM)?

Can you do this in JSBSim in Systems/c172p-engine.xml? Look in the other files like Systems/c172p-heat.xml for inspiration. See this for a list of elements you can use in math expressions.

Have you thought about directly modeling the carburetor like:

1. Take the air temperature
2. Reduce it according to RPM and throttle
3. Reduce it according to temperature of fuel (evaporation costs energy)
4. Compute freezing point of water according to air pressure
5. Difference between final air temperature and freezing point of water controls ice form rate. Combine it with humidity of the air (I think computing the dew point of the outside air temperature is maybe better, because dew point is absolute amount of moisture) (See Systems/c172p-engine.xml for computing the dew point)
6. Depending on amount of ice formed and air temperature you control the air-intake-impedance-factor. (So with carb heat you get less or no ice, but higher air temperature, thus a reduced RPM)

If pilot uses carb heat, you simply add extra heat (depending on EGT) to the final air temperature.

This is a different approach and yours is maybe easier.

[onox]

See this how to create an integrator that stays between 0 and 1.

[gilbertohasnofb]

This is a different approach and yours is maybe easier.

Yeah, I think what I propose is easier but also more predictable. Basically I am simply trying to model a function around a specific result, while you are trying to achieve this result using variables of the environment and hoping the system will output something similar to that graph. The problem is, as you wrote, that the latter approach is much more complicated, but also may lead to funny results. For instance, we can see at that graph that below 10 Fahrenheit you won't have icing regardless of the humidity but what you describe above does not take that into consideration I believe.

The advantage of using a function is that the result is tailor made to imitate the POH graph, while the later will have to be tweaked ad infinitum to come close to the graph. Both approaches are valid IMO, but personally I think what you propose is a bit too complicated -- at least for me. But hey, if anyone wants to take this issue from me and implement in such a way, that's absolutely cool!

[gilbertohasnofb]

That said, I obviously see the elegance of using environment variables instead of a hard-coded arbitrary function.

[onox]

we can see at that graph that below 10 Fahrenheit you won't have icing regardless of the humidity but what you describe above does not take that into consideration I believe.

At 10 deg F at 100 % RH, the dew point is 10 deg F as well, which means that there is very little moisture in the air (because the air is very thin due to the low temperature), thus you can get little to no ice.

[gilbertohasnofb]

But at 50 F and also at 100 % RH, dew point is 50 F, and on the other hand the icing is extremely severe. I don't see where this is being considered in the algorithm you proposed.

[onox]

Combine it with humidity of the air

[gilbertohasnofb]

I thought that the humidity of the air is 100% in both cases, as temp = dew temp.

[onox]

Yes, so I think if you want to model the physical process correctly, you would have to use the absolute humidity (amount of moisture in the air), not the relative humidity (RH).

Higher dew point is more moisture that can turn into ice.

[onox]

But if you want to use your approach that's fine too. Although I'm not completely sure about the arc tangent function.

[gilbertohasnofb]

I see, that makes sense. But I think what you propose is beyond my capacities to implement, and I also still think that there is no guarantee the results will come close to the POH graph as I wrote above.

But if you want to use your approach that's fine too. Although I'm not completely sure about the arc function.

What do you mean exactly? I think how the function spread in the plane looks fine, so the question is rather about the slope of the function in the z-axis, do you think it's raising too fast?

Anyway, I will give this all some thought...

[onox]

In that graph the drop is between 1600 and 2400. Shouldn't it rather start at something like at something like 1000?

[gilbertohasnofb]

Oh, I see what you mean. Well, the POH only speaks about RPM above 1700 and below 1700, but I think you are right, maybe that arctan function should be smoother. Anyway, I also got tempted to give what you wrote a go and see if I manage it.

[onox]

I also still think that there is no guarantee the results will come close to the POH graph as I wrote above

That's true. But the colored graph you show above is not very precise. The meaning of "serious" is not defined.

[onox]

Well, the POH only speaks about RPM above 1700 and below 1700

Maybe it's more like the center of the arc tangent drop they meant (which is at 2000 RPM in your graph). As I understand it, the air temperature is decreased by the drop in air pressure (and because the evaporation of the fuel takes energy (heat)), which is controlled via the engine RPM and throttle. I think such a thing would be a bit smoother than what your current graph shows. But that's an educated guess.

[onox]

Btw, at full throttle, carb heat should reduce RPM by 75 to 150 according to POH (page 7-19).

[gilbertohasnofb]

Okay @onox, I will give this all some thought and then I see what I can come up with,

Btw, at full throttle, carb heat should reduce RPM by 75 to 150 according to POH (page 7-19).

You are right, the drop we have is too small. I will open an issue for it and create a PR to fix it still today or at most tomorrow, okay? Because if we wait to fix it together with this issue here it will take a while. Is that good?

[onox]

Another thing: when you have ice built up, and then turn on carb heat, the mixture gets richer. See http://flighttraining.aopa.org/students/presolo/skills/carbicing.html

[gilbertohasnofb]

See: https://github.com/Juanvvc/c172p-detailed/issues/609

[gilbertohasnofb]

when you have ice built up, and then turn on carb heat, the mixture gets richer

:+1:

[onox]

Just fix it as part of your carb heat/icing feature implementation?

[onox]

Or you can fix it in #609, whatever is easier for you :smile:

[gilbertohasnofb]

Well, this here will take some time, so I was thinking about fixing the other issue faster. That's something I wanted to ask you, what is better? 1) create a large PR (but of course within a single subject) or 2) create several small PR when the issues are small (even if somehow related)?

[onox]

How many PR's do you want to create? :stuck_out_tongue_winking_eye: You can do the 75-150 RPM drop in #609 and then implement the whole carb icing in this issue?

[gilbertohasnofb]

I meant in general, from the organization point of view. For this issue here obviously a single PR will be enough, and the RPM drop in another one. But consider the case following case: yesterday I created the PR for Horacio's textures. Then I also opened this issue https://github.com/Juanvvc/c172p-detailed/issues/604 related to texture improvements, but nothing to do with Horacio's. What would have been better, have a single PR under "texture improvements" or to do what I did and have two smaller PR's?

[onox]

I think it really depends, usually you want to keep things modular so you can easily focus and test a single particular feature. (Especially bugs should be separate).

But sometimes, like with all these texture improvements, I don't mind if you do them in one PR. But in that case you should also have just one issue, not multiple. (I'm guilty of violating this rule too sometimes)

Also if you just fix one feature/bug, you can give the branch a name like bug-123, and when you merge it, you get a commit message like Merge pull request #124 from Juanvvc/bug-123. So if you later look at your git graph (in some GUI app, I use tig which uses ncurses) you can see which bug got fixed when you look at the commit message.

[gilbertohasnofb]

All sounds good, @onox :smile:

But in that case you should also have just one issue, not multiple.

Yeah, I think we all have been violating this. But often several issues are so related that it makes sense to have a single PR for them (such as was the case with securing the aircraft, instead of a PR for tie-downs, then for the chcoks, then for the pitot tube cover).

[onox]

Yes, but in that case you should have a single issue for adding all these objects to secure the aircraft after flight. Call the issue "Add securing thingies" if you will :laughing:

[onox]

Another link with discussions about carburetor icing: http://www.pilotsofamerica.com/forum/showthread.php?t=67594

If you pull carb heat and your mixture is too rich, engine starts running rougher. If your mixture was too lean, it starts running smoother.

[onox]

@gilbertohasnofb If I have a list of 3-tuples (x,y,z) (by printing 3 values to the console repeatedly), how can I create a colored picture like in https://github.com/Juanvvc/c172p-detailed/issues/360#issuecomment-162232764? With splot f(x,y) with pm3d in gnuplot?

[gilbertohasnofb]

I used:

set xrange[0:110]
set yrange[0:90]
set isosamples 50
set view map
splot f(x,y) with pm3d

The first two define the range, the next the resolution of the map, the next forces the view from the top (so even though this is a 3D map, it will look like 2D with the other dimension being only colour and not colour and z-axis)

[onox]

And how should f(x,y) be defined? I will probably have something like:

data = [(x1,y1,z1), (x2,y2,z2), ...]

I rarely use gnuplot.

[gilbertohasnofb]

I would probably save the values in a file such as test.dat, without commas or anything in between them:

1.3 4.5 7.0
1.8 9.9 3.2

Then I would use: splot "test.dat" using 1:2:3 with pm3d

You might need to use before set dgrid3d <value>,<value>, such as set dgrid3d 30,30. This will give the resolution for the 3D map (the higher the value of the grid, the higher the resolution)

[onox]

@gilbertohasnofb Could you work on implementing your solution? I don't think there's enough time to properly model the carburetor like I described in https://github.com/Juanvvc/c172p-detailed/issues/360#issuecomment-163194042

[gilbertohasnofb]

This is interesting: https://www.youtube.com/watch?v=f4lwLffGEkA