element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Arduino
  • Products
  • More
Arduino
Documents Engine Management (part 1: basic principles)
  • Blog
  • Forum
  • Documents
  • Quiz
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Arduino requires membership for participation - click to join
Actions
  • Share
  • More
  • Cancel
Engagement
  • Author Author: jack.chaney56
  • Date Created: 28 Jan 2016 5:57 PM Date Created
  • Last Updated Last Updated: 6 Oct 2021 8:46 PM
  • Views 3922 views
  • Likes 6 likes
  • Comments 37 comments
Related
Recommended

Engine Management (part 1: basic principles)

Best place to start is at the beginning.  The problem is, which beginning.  There is a beginning to the platform, and a beginning to the process of engine management.  I guess the platform is something that can come later, so, I will begin with the process of engine management.

 

Engines (internal combustion type), have some basic principles. They need air, fuel, and spark to make them work. Engine diagnostics tell us, if you take any one of the three away, the motor doesn't run. We will start with the spark generation, and how to get it "just right".  Now, to make my train of thought a little more difficult to follow, a little bit about problem solving.  Dijkstra tells us, if a problem seems too big, solve the parts that you can solve, then work on filling in the parts that are left.  For a process problem, quite often, the "steady state" is the main part of the process, and the management of the exceptions is where things get troubled.  So for our engine management problem, we will start from the steady state condition (no changes due to acceleration, positive or negative).

 

Kind of a long winded introduction to get us to a point of where I want to start the discussion, which is about timing. I am going to work with four cycle motors in this series, so people interested in two cycle, or diesel, will have to wait until another series. Four cycle, means the crankshaft turns twice causing the piston to rise and fall twice, per each sequence (called a cam cycle). There is a compression sequence, and an exhaust sequence. The compression sequence is where the spark needs to happen. But when in that cycle should we make the spark happen? Still more background. For the energy event during the compression, we have an air:fuel mix that is put under pressure, and ignited by a spark. How to generate the spark in just a moment, first when exactly do we need to make the spark happen. The way the ignition occurs is interesting because it is not immediate. If you were to take a very high speed film of the ignition event, you would see that when the spark ignites the air:fuel mix, the burn extends from the ignition point in a plume. Because of the properties of the fuel, this rate is fairly constant. Keeping in mind different fuel types have a different burn rate (alcohol, very fast, diesel, very slow). The ideal timing for ignition, is so the plume reaches the top of top of the piston, just as it reaches its state of top dead center(TDC) (highest point in the cycle).  To make this happen, the ignition needs to happen a little before TDC, this is referred to as the advance. The advance changes as the motor changes speed, the faster the motor is turning the earlier the advance needs to be. Luckily for us, we are dealing with the steady state first, so adjustments to advance will come later.

 

Our next piece of the timing puzzle is about generating the spark, this is done in many different ways, but we will be starting with the conventional method first, the ignition coil. Coils work on an interesting electrical principle. By applying a direct current to the coil, for a brief period, it behaves like a resistor until it reaches its saturation point (can't absorb more current), then it behaves like a shorted wire (no resistance). When the current is removed from the coil quickly, an interesting phenomenon occurs, called field collapse. This drives a voltage at a high current spike through the circuit, which generates the spark at the plug. I over simplified because I don't want to get too hung up in coil design and efficiencies, again this leans toward exceptions. What I did want to cover was there was a period of time before the ignition, when we need to charge the coil. This time is called the dwell, and dwell is dependent on the type of coil, but some general cases can be used for now and we will just call it our dwell.

 

Now we have what we need for our basic system, at least for one cylinder. Oh, first diversion from general case engine model, the cylinder object. If we write all the code for a single cylinder, then make N number of instances, we can have any number of cylinders we want in our motor. Information we have about our cylinder is the angle of its TDC, the dwell time for the coil it is attached to (multiple coils are an exception to be discussed). So we need to determine some elements; current angle in cam cycle, and engine speed, which will help determine the value of the advance.  Sounds like we need some inputs, most engines with electronic ignition systems have a couple of signals that are helpful, called cam and crank. These signals are generated from the camshaft, and crankshaft. and have one, or a series of triggering elements mounted to produce a signal to identify position. Here is where I am going to diverge again. The thing we are interested in, is rotational speed, and current position. The cam and crank are a closed system, so the process is continually repeating, and once we have identified were we are in a cam cycle, as long as the speed remains consistent, we should know were we are at any time, and additional inputs, provide additional information.

 

Lets look at a common type of cam and crank configuration 4x crank and single pulse cam. The good thing for this part is the engine manufacturers go though a very large effort to make sure the active edge of the crank and cam signals are extremely precise. As a result each active edge of the crank is exactly 90 degrees from the previous signal. Also, the cam signal only occurs one time in a cam cycle. This gives us our prime reference.  How this works is, a value of TDC0 is set, based on the operation of the motor, which is the 0 degree reference point and synchronized with one of the crank signals (called teeth), and the cam signal is given as number of crank signals from cam to TDC.

 

So we have input signals, and can begin doing some determination. Starting our timer when we get a crank event, and stopping the timer when the next event occurs, we now know how fast the motor is running, because the time dT, to move 90 degrees is 1/4 the time for a full rotation. and if we convert the units of dT to one minute, then multiply by 4 to provide RPM. If we know which crank signal just passed, we also know our position, this is possible if we have had a cam signal, in which case we count the number of teeth for cam to TDC. Some clever calculation will let us know where we are, as soon as the cam signal is detected, because cam to TDC means the crank signal that just passed when the cam signal is detected is 2x number of teeth - cam to TDC number. Now that we have our information, we can get to work, since it is ridiculous to think that a motor doesn't change velocity we will need to provide continuous update to the dT value, so the stopwatch idea is not practical. Instead, we will use a free running timer, and get a trigger time when the crank event is recorded. Then, take previous recorded timer value, and current recorded timer value, and the difference is our dT that gives us our rotational speed.  Hopefully, you can begin to see now, that the number of events in a crank, provided they are equally spaced, is only significant to determine accuracy of rotational speed, and more quickly determine change.

 

The result also provides a means of predicting the precise moment when the next event will occur, as well as other, future events. This is important, because from our earlier discussion, the spark event needs to occur before the TDC event (which is usually synchronized with a crank event), and the start of dwell needs to occur before the spark event.  Also, remembering, starting the dwell too soon, can cause potential damage due to heat buildup from a shorted system, so the dwell cannot be started too soon.  I will finish off this first entry by establishing some formulas to use...

 

     t0 is the previous recorded event time (time of the previous crank event), in an arbitrary unit of "ticks"

     t1 is the current recorded event time (time of this crank event), again in the arbitrary unit of "ticks"

     dT is the delta time providing rotational speed (t0 - t1) in ticks

 

     teeth is the number of crank events in a single rotation

     TicsPerMin is the number of tick units in a single minute

     RPM is now calculated as: TicsPerMin / (dT * teeth)

  • Share
  • History
  • More
  • Cancel
  • Sign in to reply

Top Comments

  • phoenixcomm
    phoenixcomm over 9 years ago +2
    I have some help for you. I was/am (long story) building a digital fly-by-wire experimental aircraft working with my local EAA chapter. Anyway here is a page for the sensors; Phoenix2000 EFIS or Electronic…
  • jack.chaney56
    jack.chaney56 over 6 years ago in reply to phoenixcomm +2
    Thank you so much for your response. This is kind of why I backed out the first time. First, I have been doing embedded system programming since before it had a name (boot process development on PDP-12…
  • mcb1
    mcb1 over 9 years ago in reply to jack.chaney56 +1
    I never expect replies instantly ... we all have other lives. ...:) I have seen this applied to a ride-on lawn mower, which overcame the simple carburetor that caused headaches in the varying temperatures…
Parents
  • jack.chaney56
    jack.chaney56 over 9 years ago

    Also... To follow my pearls of wisdom. The Blog link is
    https://www.element14.com/community/people/jack.chaney56/blog

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • phoenixcomm
    phoenixcomm over 6 years ago in reply to jack.chaney56

    I too will add my 2 cents of wisdom? Now hold your breath. Im going to shock you.

    Frist Dah Rules.

    1. Since this concerns safety-of-flight. If you must use an Arduino please use Eclipse IDE, with ANSI C. Do Not use the Arduino IDE. as you will have more control over your program.

    2. Embrace JOINT STRIKE FIGHTER Coding Standards! (This is very ugly stuff, but you will need it. if you ever want to get past the FAA.)

    This was promulgated by France. Well anyway. Lots of rules. No, you still have your standard ruleset, just with lots of you can't do that here. and you must not ever do this or that.

    3. While you're at it take a look at TI Hercules CPU LAUNCHXL2-TMS57012 its, dual protected core designed for what you are doing. http://www.ti.com/lit/ml/spnu611/spnu611.pdf

    This contains C++ and Java.  I will post them both as .zip and .tar

    I have the whole thing and will post it on my web server.

    www.phoenixaerospace.us/downloads/JFS/JSF-CodingStandards.tar

    www.phoenixaerospace.us/downloads/JFS/MISRA toolkit

    www.phoenixaerospace.us/downloads/JFS/LIN LLVM-Clang pluginT.tar

    www.phoenixaerospace.us/downloads/JFS/meyers-linux.zip

    www.phoenixaerospace.us/downloads/JFS/misra-complete.zip

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • jack.chaney56
    jack.chaney56 over 6 years ago in reply to phoenixcomm

    Thank you so much for your response. This is kind of why I backed out the first time.

    First, I have been doing embedded system programming since before it had a name (boot process development on PDP-12, System level assembler coding of IBM360, 1802, 6800, 6502, 8088, 80286,386... C from K&R days (Still have my first edition) C++ Stroustrup (still have my first edition), I can go on.

    Second, I am familiar with all the pitfalls of coding for vehicle systems, as I was in vehicle diagnostics for 20+ years, and sat on SAE task forces for J1850/ISO9141, J1978, J1979, J1962, J2012 (16 bit P codes was my idea), again, I can go on.

    The intent of creating a controller for operating an engine is two fold:

    1. It provides a great exercise for presenting embedded coding principles.

    2. To present theory of operation of engine controllers.

     

    You were providing information related to FAA and JPL systems, and having to keep the French happy?  My Engine, here, is for ground based systems, primarily cars, and non-military application (besides, they're primarily jet fuel diesel or turbine operation, so... why would I start off talking about ignition?).  This is the second time I started presenting information and had someone jump to the end and tell me I forgot something... I haven't even started yet, so how do you know that I have left something out.  Thanks for the help, but I got this.

     

    This system is not intended to be used as a primary controller in a new OEM vehicle with AutoSAR communications, and full OBDII diagnostic information. It is intended to be enough so someone with an old beat up Corvair or VW, and even some crate engine packages to have a tuneable system to play with.

     

    I am going to use Eclipse IDE and the AVR plugin. The development workstation is going to be a Raspberry Pi ($35 USD), and will load the AVR components (only 4 are needed). I will be using either a AVR-USB programmer ($5 USD on line), or a JTAGICE-3 ('cause I have one) to program the Arduino. I am going to show the code on both the Nano ($7-$10 USD), and Mega2560 ($10-$15 USD) to provide an example of problem solving when resources get thin.

     

    I have a ton of content, that I plan to present in a form that doesn't require a PhD, or an understanding of grid coding design to follow along. This is intended to be a fun learning experience, so sit back and enjoy the ride. If I cover a topic that is not understood, I am more than happy to provide explanation from many different angles until I hit on the right one. The "buy in" for this is also being kept low, so there won't be a need to go into debt if anyone wants to play along at home.

     

    Please don't be angry. But, it is polite, in intellectual discussions, to hear the full argument before trying to attack credibility.

     

    Jack

    • Cancel
    • Vote Up +2 Vote Down
    • Sign in to reply
    • More
    • Cancel
  • mcb1
    mcb1 over 6 years ago in reply to jack.chaney56

    I think you've added the bit that either I missed, or wasn't there.

    It is intended to be enough so someone with an old beat up Corvair or VW, and even some crate engine packages to have a tuneable system to play with.

     

    It's certainly an impressive background, and I applaude the intent, but I do wonder if the Arduino (great that it is) has the speed necessary to keep up with the timing aspects of a whole motor controller.

    There are some 'Hot Rod' versions by Chipkit that run at 80Mhz https://chipkit.net/wiki/index.php?title=Boards  which might make life easy and still be in the same price range.

     

    With many of the modern engines, there are tools to be able to tweak various aspects, so hopefully in amongst your posts, they might be able to be translated into a 'tuners' guide.

    As we old Hot Rodders know it's really easy to tweak this and that, but sometimes it's not the best for a motor.

     

    Mark

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
Comment
  • mcb1
    mcb1 over 6 years ago in reply to jack.chaney56

    I think you've added the bit that either I missed, or wasn't there.

    It is intended to be enough so someone with an old beat up Corvair or VW, and even some crate engine packages to have a tuneable system to play with.

     

    It's certainly an impressive background, and I applaude the intent, but I do wonder if the Arduino (great that it is) has the speed necessary to keep up with the timing aspects of a whole motor controller.

    There are some 'Hot Rod' versions by Chipkit that run at 80Mhz https://chipkit.net/wiki/index.php?title=Boards  which might make life easy and still be in the same price range.

     

    With many of the modern engines, there are tools to be able to tweak various aspects, so hopefully in amongst your posts, they might be able to be translated into a 'tuners' guide.

    As we old Hot Rodders know it's really easy to tweak this and that, but sometimes it's not the best for a motor.

     

    Mark

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • More
    • Cancel
Children
  • jack.chaney56
    jack.chaney56 over 6 years ago in reply to mcb1

    In response, it all comes down to code.

     

    My background with code had me, for a while, writing video games. I am a software person first, that learned about electronics out of necessity, not an Electrical or Mechanical Engineer that learned how to code so the job could get done.  As a general statement, Electrical Engineers do not make the best coders, though they will argue otherwise. My video gaming background (in the days before turbo video processors) when you had to count raster lines and make all your updates during the retrace, I learned a few tricks with interrupts.

     

    If you work out the timing of the primary events (CAM and CRANK signals), on an 8 cylinder motor with a (worst case) 60-2 tooth wheel. the timing involved for a motor running at 10000RPM provides a window of 0.1 mS to get the work done. With a 16MHz chip, that means I have 1600 cycles worth of instructions. Again, reaching into my bag of tricks, and looking at the puzzle, carefully... First, not all the tooth events are critical (particularly at the higher RPM), in fact many controllers switch over to using the CAM only at higher RPM. Second, throw away all the work that can be done at any time, and doesn't change significantly, like updates that occur during a timed event (periodic timer interrupt for real time reference). Last using the hardware available and not repeating the work in software, and what results is, the only processing needed in the interrupt is to read the timer, subtract from the previous timer value, and save the difference. On significant tooth operations, trigger the external process, then get out.  I think I have enough time to not get into an interrupt starvation state. Oh, please note, the conditions for the example are usually found on top end drag racers, not an old beat up VW or Corvair engine which is my original target group.

     

    Most cases for hobby builders (motor heads), is to use something like a 4x crank wheel, and a half moon cam, but provision will be made for other configurations.  Also, for street applications, it is a rare case when the engine will exceed 7200RPM. I just wish to point out, most code written for engine controllers does not manage interrupts efficiently. Most EEs aren't comfortable with significant power of interrupt processing, and as a result avoid it and treat it as a bad thing. Repeating the calculation with a 4x crank wheel, and running at 6000RPM, the time window now becomes 40000 cycles... wow, I could drive a truck through that (pun intended).

     

    So, for any doubters out there I say... Challenge accepted.

     

    Jack

    • Cancel
    • Vote Up +1 Vote Down
    • Sign in to reply
    • More
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2025 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube