I got my hands on a dead automotive Mass Air Flow sensor. Someone had already been curious so I got a disassembled part but I am even more curious because it’s a weird piece and I want to know why.
In Ye Olden Days, the MAF sensors were classic hot wires but since cars usually drive outside laboratories and controlled environments the wire would catch dirt and give false readings. One possible solution was to burn the dirt away by heating the wire but then the sensors failed because the wires degraded over time and even burned away. So the wire had to be moved somewhere they wouldn’t catch all the impurities in the air.
How Does This MAF Sensor Look Like
The whole MAF sensor assembly sits in the intake pipe with a connector at one side and reaches almost all the way through to the other side of the pipe. At the far side there is an orifice facing upstream flow. Small part of the flow enters the inlet orifice and exits at the side. Almost the entire flow passes through this channel. However, there’s another, secondary channel: an extra loop connects below the inlet. The channel begins with a sharp edge at one side and a fillet at the other. It goes down and around the primary outlet and exits at a separate, secondary outlet that is close to intake pipe wall.
The hot wire has been replaced by something that looks like an integrated circuit – might not even be a proper hot wire but a heater between two temperature sensors. I’m not getting into the mechanics of the measurement method as that’s an entirely different topic altogether. But I am indeed curious about a number of weird features – rounds, extra walls, sharp edges, different channel heights and whatnot – each one raising a question or an eyebrow. So let’s try to clear up as many of the questions as possible with:
A Simple Simulation
To do that I had to make up many unknowns. For instance, flow speed that doesn’t depend only on engine speed and volume but also on turbo compression, intake pipe diameter etc. I ran the same case with a couple of different velocities I thought would occur in real life. I drew the 3d model in FreeCAD as faithfully as I could using only calipers.
I used snappyHexMesh as I was on holidays (OK, I admit I still used classy_blocks for the background cylinder).
No particles, no compressible effects and whatnot! Just plain simpleFoam with air at standard conditions. For modeling turbulence I stuck with the good old k-Omega-SST. I refined the mesh through the channels so that I barely met a good-enough-ish y+. Since I’m only interested in the qualitative features of the flow, that’s just fine, I’d say.
And Some Pretty Pictures
One question was whether the secondary flow goes in or out the secondary outlet at the top because of the way the labyrinth is shaped at the bottom. Pretty colors say it indeed goes out.
There are two contracting sections. One at the inlet – serves as a flow accelerator, possibly also for particle separation. The other is before the secondary outlet – reduces pressure so that the secondary flow is pulled into the loop.
At the beginning of the loop there is a sharp edge around which the measured flow must turn. That causes a high acceleration which I believe is made in good will that the particles will not follow. The other end has a nice fillet which I think is supposed to deflect the non-following particles back out. We can confirm the former by calculating the acceleration field (see appendix at the bottom).
This also holds for different velocities that I simulated.
That wall next to the top outlet probably makes sure that the fillet acts as a contracting duct, lowering the pressure at the secondary outlet. It would work better if there was a wall at each side – probably one is missing because of technological reasons.
Moreover, the sharp edge at the end of the top fillet probably keeps dust particles out and seems like a smart move.
The Unanswered
The rest of the loop seems meticulously designed and as if there was some kind of parametric model involved that they used for optimization of… something.
If hot wire or hot film need nice, laminar or at least uniform approach flow, that certainly wasn’t the case. These streamlines seem terribly… crooked. The turbulence is suppressed judging by the k field alone (which is a terrible, terrible way of judging), how much, can’t tell (by this terrible, terrible way of judging).
I would indeed need to invest a lot more time into postprocessing and theoretical examination of the matter to obtain the relation between the bulk flow in the intake pipe and the measurement flow that actually meets the sensing area. One could assume it is linear but given how few phenomenona in fluid mechanics is actually linear… anything could happen!
I am pretty sure there’s a lot more to a sensor like this than I could find out using such a simple simulation. People have been working on that far more than I have had chance to. Regardless, I can’t shake off a feeling this was either whipped up very quickly under pressure of overzealous managers. Or it’s a result of a university assignment made by a confused student and a genius professor… Or even vice versa – in any case, it looks to me as if the theoretical shape was taken directly from a simulation of some sort and put into use with no further industrial-level refinement… But of course, I may be wrong.
Appendix: Acceleration Field
The velocity is a time-varying vector field so to obtain acceleration we must differentiate it with a material derivative. Since we’re in steady-state and incompressible fluid the whole nasty equation boils down to
\mathbf{a} = (\mathbf{u} \cdot \nabla) \mathbf{u}
The Gradient filter in Paraview just throws a new dataset with 9 components at you, those of a tensor
\nabla \mathbf{u} = \begin{bmatrix} \partial u_x/\partial x & \partial u_x/\partial y & \partial u_x/\partial z \\ \partial u_y/\partial x & \partial u_y/\partial y & \partial u_y/\partial z \\ \partial u_z/\partial x & \partial u_z/\partial y & \partial u_z/\partial z \\ \end{bmatrix}
We’ll have to calculate acceleration like that:
\mathbf{a} = \begin{bmatrix} U_X & U_Y & U_Z \end{bmatrix} \cdot \begin{bmatrix} \partial u_x/\partial x & \partial u_x/\partial y & \partial u_x/\partial z \\ \partial u_y/\partial x & \partial u_y/\partial y & \partial u_y/\partial z \\ \partial u_z/\partial x & \partial u_z/\partial y & \partial u_z/\partial z \\ \end{bmatrix}
Suppose the Gradient filter names the parts of the gradient tensor Gradient_<i>, the text to input to the calculator now reads
(
(U_X*Gradient_0 + U_Y*Gradient_1 + U_Z*Gradient_2)*iHat +
(U_X*Gradient_3 + U_Y*Gradient_4 + U_Z*Gradient_5)*jHat +
(U_X*Gradient_6 + U_Y*Gradient_7 + U_Z*Gradient_8)*kHat
)
Mind that larger particles will be less likely to follow paths with a higher acceleration but that is just a qualitative thumb rule. There are more factors in play. One could, for instance, calculate curvature and local centrifugal acceleration from that, compare with particle size, density, drag and fluid viscosity and so on. Or just use a particle tracking simulation or a similarly badass approach. But I had no time nor energy to be a badass. Takes out all the fun!
