Engine Management

clean up is done... time for fun.

Sharp eyed folks out there might recognize, that most all the parts are in place for performing ignition management. The tach event array tkEv[] holds the TDC for each cylinder. By subtracting a value for total advance from each of the TDCs a coil event (coEv[]) angle is obtained. This is done simply in a short loop in the 1mS ignition process while the engine is running, similar to the loop to set the tkEv[] values during engine off. The value of total advance is calculated once, then applied to the tkEv in the loop. The other part of the operation is the start of dwell for each event, the dwell is a value that provides sufficient time to charge the coil, but not too much beyond fully charging the coil. This value is also captured as an angle, and the start of event (cost[]) is calculated by subtracting the dwell angle from the coil event angle. This is also done in the loop. The calculation of dwell angle is also a one time operation, and then applied in the loop.

That wordy explanation, works out to just a few lines of code.

UWord coEv[8];
UWord coSt[8];

void rtUpdateIgn(void) {
...
    updateTotAdv();
    updateDwlAng();
...
    if (tmOut > 0) {
...
        for (c = 0; c < cylCt; c++) {
            coEv[c] = tkEv[c] - getTotAdv();
            coSt[c] = coEv[c] - getDwlAng();
        }
...

The two functions getTotAdv() and getDwlAng() return the angle of advance, and the angle of dwell calculated the one time.

The last part is to include the operation in the scheduler, in the same way as the tach. The difference being, coil operation passes the cylinder number for cases where the operation is coil on plug, so the call to setCoil() has the coil number as well as the state.

            if ((min < coSt[c]) && (coSt[c] <= max)) { ft = (SLong)(coSt[c] - pa) * bs / PART2; ignCoHi(c, ft, tm); }
            if ((min < coEv[c]) && (coEv[c] <= max)) { ft = (SLong)(coEv[c] - pa) * bs / PART2; ignCoLo(c, ft, tm); }

and the same for the other range of min/max

            if ((min < coSt[c]) || (coSt[c] <= max)) { ft = (SLong)(coSt[c] - pa) * bs / PART2; ignCoHi(c, ft, tm); }
            if ((min < coEv[c]) || (coEv[c] <= max)) { ft = (SLong)(coEv[c] - pa) * bs / PART2; ignCoLo(c, ft, tm); }

The coil process takes over the fast timer operation, and the tach is moved to the slow operation.

You might ask what values should go in total advance and dwell angle, and you are right to ask. For now, something like 20 degrees (1820) for dwell and 8 degrees (728) for dwell should be fine. To run some preliminary testing, the routines updateTotAdv() and updateDwlAng() can be stubbed out, and the getTotAdv() and getDwlAng() just return the constant values.

Now it's getting fun.

Jack

Coming to the end of phase 1 of the project. I am attaching a zip file with the source to this stage. The next stuff starts getting into engine theory and why timing of certain events is more critical than others.... Oh dear, I have a nice zip file, and can't find how to attach it here. I will do some searching, then attach it as soon as I figure it out.  On to engine theory stuff...

When the ignition event occurs (piston ignition), there is a downward force on the piston which is converted into a rotational force by the piston rod and crankshaft. When this happens, there is a similar force in the opposite direction which produces a wobble of the motor. Because things are generally bolted down, the motor doesn't jump out of the compartment, however the force still is there. The goal is to reduce the effect caused by this rocking motion. The solution implemented is to have the pistons fire in a sequence to balance out the forces. This is why engines implement a firing sequence Chevy uses 18436572 for an 8 cylinder motor. It is possible to keep this sequence stored someplace in an array, and just read the array value based on the sequence number in the coil firing sequence, and for many, many operations, this is the method used.  But I looked at the problem, and said, how do I make this easier for the controller. The solution became simple, just save the angle in the array properly.  For the Chevy 8 cylinder example; cylinder 1 is zero degrees, cylinder 8 is at the first position past 0, or 90 degrees. cylinder 4 is in the second positon, or 180 degrees, cylinder 3 is next at 270, etc.  When the exercise is over, the array of positions is (using our radians and the tkEv array).

tkEv[0] = 0;

tkEv[1] = 57344;

tkEv[2] = 24576;

tkEv[3] = 16384;

tkEv[4] = 40960;

tkEv[5] = 32768;

tkEv[6] = 49152;

tkEv[7] = 8192;

Which is how it gets stored in the calibration section, along with the cylinder count (8). The calisthenics can be performed in the user interface for the calibration program. Returning to the program, the window is compared to each cell of the array and when the value is within the window, the event is scheduled. it can be seen that the counter for doing the comparison, now holds the proper cylinder number.

Next thing to look at is the issue of "advance". For those that don't know already, in a cylinder, fuel and air are mixed to produce a flammable mixture, then under pressure, the mixture is ignited by a spark. The ignition of the fuel mixture is not instantaneous. In super slow motion, it is interesting to see the burning of the mixture occurs in a traveling wave. The goal is to maximize the impact of the wave at the point of TDC, so the greatest amount of energy is transferred to the down stroke of the power cycle. Because the rate of burn changes based on pressure and does not happen instantaneously, the command to ignite fuel happens before the cylinder reaches TDC. This is called the advance, and is measured as an angle. As the speed of the motor increases, the angle of advance also increases to compensate for the burn rate remaining generally the same. However, the rate of burn is somewhat dependent on pressure as well, so there is also a pressure compensation that needs to be factored in. Earlier in the compression cycle means the pressure value is lower, also, if the intake volume, measured by manifold air pressure (MAP), is lower or higher, the compression value changes as well. The good news is, the change in compression based on cylinder position sort of balances out because it generally increases to a stable amount and the RMS value (this is sort of based on a sinusoidal curve), stays pretty static, the MAP is the governing factor and the lower the MAP the more time is needed, so the advance increases. We have identified two components that influence the value of advance, the RPM and the MAP. The ignition is actually a chemical reaction called oxidation. Because it is a chemical reaction, the ambient temperature of the container (cylinder) also factors into rate of reaction. This means that temperature will also need to be factored into the value of total advance.

Sounds a little like this is getting into some complex math during runtime. The rule in embedded systems is a table is always faster. So, how to use a table in this case. Quite simply, if the table is a two dimensional array, with one axis as the RPM and the other as MAP, the table can be constructed so the value of advance resides at the array cell based on the RPM and MAP coordinates. However, for a reasonable range of MAP values and RPM speeds, the array would tend to become very large. In order to keep the table size reasonable, some math is necessary. The technique is called planar interpolation. You may be familiar with linear interpolation where one value X₀ and another value X₁ and the f(x) values Y₀ and Y₁ that equate. Any point Y_n along the line segment, can be calculated based on the X_n point. The equation is:

                  X_n x (Y₁ - Y₀)

Y_n = X₀ + ---------------------

                      (X₁ - X₀)

Similarly this operation can be done in two dimensions. The difference is, instead of using two end points, the operation uses the four corner points of a plane. The corner points are Z₀, Z₁, Z₂, and Z₃ and relate to X₀, X₁, Y₀, and Y₁ where Z₀ is the value at (X₀,Y₀), Z₁ is at (X₁,Y₀), Z₂ at (X₀,Y₁), and Z₃ at (X₁,Y₁). The formula resolves to:

Z₀(X₁-X_n)(Y₁-Y_n) + Z₁(X_n-X₀)(Y₁-Y_n) + Z₂(X₁-X_n)(Y_n-Y₀) + Z₃(X_n-X₀)(Y_n-Y₀)

----------------------------------------------------------------------------------------------

                                       (X₁-X₀)(Y₁-Y₀)

Thats the formula, I'll add it to code in a little while. I want to save this so it isn't lost (lots of editing)

Jack

I found out how to attach a zip file... I had to go over to the advanced editor

So here is the zip with the source so far.

...as expected, I checked my work after my panic of loosing all my work and noticed the linear interpolation was a little wrong. The X₀ + should be a Y₀ +

sorry again

Jack

Jack.

Yes, please. Pay attention to what your wife says. It will make the results better for you, everyone. :-)

Checking back to make sure I am covering things the way I said, and so far I haven't strayed too far. The only thing I skipped was the part about injectors. This is was because the only thing different about injectors is the schedule. There are different strategies with injectors, they are; throttle body injection (TBI), batch, staggered batch, sequential, and staged.

TBI is the simplest, and is quite similar to normal aspiration. Normal aspiration is when the fuel is drawn into the carburettor by the intake vacuum, and controlled by a needle valve. With throttle body injection, the injector shoots the fuel into the intake chamber.  With normal aspiration, the flow is continuous, with TBI, it is pulsed to control the volume of fuel, and with TBI it is pulsed four times per cam cycle. Batch is when the injectors are mounted along the intake manifold, closer to the cylinder intake, and usually an injector for each cylinder. Batch means all the injectors open at the same time, twice per cam cycle. Staggered fire, is the same as batch, except the injectors are divided into two groups, and each group fires together, twice per cam cycle, but out of phase so half then the other half then the first again, etc.

The last two are for performance systems, again with injectors close to the cylinder intake (or inside the cylinder). Sequential means the fuel is supplied during the intake fueling stroke of the cylinder and needs to be timed accordingly. Since it is sequential, each injector operates independently, and only fires once per cam cycle. Staged fueling is again, for high performance systems when the demand for fuel exceeds what can be supplied by a single injector. In these cases, a second bank of injectors is used to increase the volume. The timing follows the pattern of sequential injection.

Without getting into volume of fuel (yet), it is possible to see the scheduling of fuel injections becomes just another event pair to open and close the injectors, either individually or as a group. The timing can be associated again with an angle of event.  There is lots more to fueling, which will be covered, but I hope this provides how much of the work is already in place from the ignition timing operation.

Jack

Still trying to catch up with all the details but I'm enjoying reading thru it all.  I  want to encourage your postings.  I'm not in the automotive industry but chemical industry. It's all kind of the same and all a bit different.

I don't know if it has been said but there is an open source project called speeduino. Its been running engines for a while now, actually my daily runs on it. It started on the ATMEGA 2560 but its been ported to the teensy 3.6? ARM32. You could use the well developed hardware for testing purposes with your code.

Hi again,

Back to your first statement, about volume of work for a single programmer.  I guess it might be... but I am an old, retired, programmer. This is a good exercise to see if it really can be done.

My problem is, I do need help with the hardware stuff (circuit design and layout). My stuff is all using breadboard, LEDs, and some Rube Goldberg mechanical devices.  I think I have the software working, but would really appreciate some partnership assistance from time to time

Jack

Hi,

No I had not seen that (yet), if you could post the link here, I can chase things down and see if it will give me some help with the hardware aspects of this project. My source is primarily for 328, but I also have a version that runs on 2560 that uses all shared code with the exception of 4 files.

Thank you for the shout out,

Jack