element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • About Us
  • 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
Ben Heck Featured Content
  • Challenges & Projects
  • element14 presents
  • element14's The Ben Heck Show
  • Ben Heck Featured Content
  • More
  • Cancel
Ben Heck Featured Content
Forum More Engine Management
  • Blog
  • Forum
  • Documents
  • Events
  • Polls
  • Files
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Ben Heck Featured Content to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • Replies 6 replies
  • Subscribers 39 subscribers
  • Views 866 views
  • Users 0 members are here
  • gasoline_engine_management
  • arduino
Related

More Engine Management

jack.chaney56
jack.chaney56 over 6 years ago

In the previous discussion, I presented a base system for engine management. The problem with what was created is, it only runs in steady state. Steady state for an engine is constant rpm and load, no acceleration, and no change to demand. The software components of the system have been intentionally designed to be independent of hardware processor. The specific platform is the Arduino Nano and the 328p processor. The choice was as an exercise to see if it could be done, and to force a level of discipline for the programming model. The other item of note from the previous discussion is, I am a software person primarily, with a working knowledge of electronic hardware. I am happy to admit to shortcomings in any circuits that I present, and encourage correction.

 

This second section will deal with making improvements to the basic software to manage the asynchronous events. Some items will make reference to the previous discussion, so please review for a full description. If something was left out, I am happy to fill in the detail. Jumping in to the first item which is a one time event. The engine start. When the engine is cranking, before ignition timing is captured, fuel is being input, and not burned. To correct the state, once the engine starts, the acceleration is raised temporarily to "burn off" the excess fuel. This is done by adjusting the advance, first increasing, then reducing back to steady state.  Also, during crank (before ignition capture), the advance is reduced to almost zero. Because the advance goes from near zero to a large angle, a measured transition is needed. This is called the ramp in rate. Also, the recovery from the large angle to the steady state angle, is again a measured value. This is called the decay. The startup sequence then becomes a small state operation. Crank > Ramp to max > Decay to steady > Steady State. In each of the states a value is combined as part of the total advance.

 

The ramp in and decay are governed by the RPM of the motor, so a counter tied to the cam signal is implemented. The four states are monitored with a simple switch operation. The values for ramp in and decay are defined in calibration, as well as the values for max and minimum advance. The other part is to implement a counter of some sort that is updated during the cam signal detect (same place as setting cam detected flag). The sequence works sort of like this:

  • Engine off - Retrieve from calibration values for min, max, ramp, and decay.
  • Crank to start - Set advance to minimum until ignition is detected, also set counter to ramp in value when ignition is detected change state.
  • Ramp in - Adjust advance from minimum to maximum with a slope = counter / ramp until max is reached then set counter to decay and change state
  • Decay out - Adjust advance from max to steady state with a slope = counter / decay until steady state is reached then change state
  • Steady State - watch for engine stop

 

SWord updateStartupTrim(SWord t) {
 static SWord ramp;
 static SWord min = 0;
 static SWord max = 0;
 static UByte stState = 0;
 switch(stState) {
 case 0:  // engine off, crank to start
  min = getIgnStartupAdjustment() - t; ramp = getIgnStartupRampIn(); if (ramp == 0) { ramp = 1; }
  ignStTrim = getRpm() > 0 ? min : 0;
  if (getRpm() > getIgnRpmMinRun()) { camTrimCt = ramp; stState = 1; }
  break;
 case 1:  // ramp in
  max = getIgnStartupTrim();
  if (camTrimCt > 0) { ignStTrim = max - (SWord)((SLong)camTrimCt * (SLong)(max - min) / (SLong)ramp); }
  else { ignStTrim = max; ramp = getIgnStartupDecay(); if (ramp == 0) { ramp = 1; } camTrimCt = ramp; stState = 2; }
  break;
 case 2:  // decay
  if (camTrimCt > 0) { ignStTrim = (SWord)((SLong)max * (SLong)camTrimCt / (SLong)ramp); }
  else { ignStTrim = 0; stState = 3; }
  break;
 default: // running
  ignStTrim = 0;
  if (isEngStopped()) { stState = 0; }
  break;
 }
 return ignStTrim;
}

 

The variable camTrimCt is the counter which gets decremented on each cam.

 

Good news is, there are lots of exception and asynchronous activities to manage, so there will be lots offered here

 

Jack

  • Sign in to reply
  • Cancel

Top Replies

  • jack.chaney56
    jack.chaney56 over 6 years ago +2
    Here is where I get some people upset. I generally have great respect for electrical engineers, and their capabilities to develop really good hardware solutions. I am by training a software development…
  • jack.chaney56
    jack.chaney56 over 6 years ago +1
    Should add the link to the previous discussion as well. Engine Management
Parents
  • jack.chaney56
    jack.chaney56 over 6 years ago

    Time for a review...

     

    Control processes for A/D, EEPROM, Serial I/O, Timers, and input triggers.

    Table processing for linear and planar interpolation.

    The 16bit solution

    Basic scheduler for timed events.

    Synchronization of crank and cam signals.

    Steady state fuel calculation.

    Basic principles for ignition timing.

     

    Communication of values is a good discussion. My observation is, if you count up the number of engineers in a room (n) and pose a problem, you will get at least n+1 solutions. There are a significant number of communication protocols to choose from, and by protocol, I mean what gets sent, not the medium or transfer mechanism. Serial communication being the available data transfer mechanism, and using something simple to start (19200,n,8,1). In case it is not known, that is 19200 bits per second, no parity, 8 data bits, and 1 stop bit. Not going to go into any kind of detail about how serial shift registers work, or any more about the communication hardware than I already presented. The input and output sections are buffered with a put/get interface and background interrupt processing. This leaves only the messages being transferred.

     

    I have done many different forms of messaging protocols, with varied levels of success. Each implementation has had strengths and weaknesses. I had thought of implementing a full 488.2 SCPI protocol, but decided it was a bit excessive for what I wanted. I had even created a small operation version that I used for testing at an earlier implementation. Looking at the needs of the system, there aren't many messages that need to be sent.

    1. Read calibration data from EEPROM

    2. Write calibration data to EEPROM

    3. Configure monitor list

    4. Read list of monitor values

     

    The example I like to use for messaging protocols, so I can remember to include everything is the letter (snail mail). Examining the letter, there is a stamp, which represents size and priority. Next there is an address of the receiver, and a return address of the sender. The envelope provides the container for the data, and the letter is the content BLOB (binary logical object block). Going super cheap, and limiting development, the messages should be maintained as human readable strings, or should have a human readable instruction set. This way a standard serial communication terminal program can provide the general interface.  I'll fill in more tomorrow, but for now simple, simple, simple.  No size component, and no priority. Messages will end with either a newline or a semi-colon. Read messages are upper case, write messages are lower case. Messages for calibration start with C or c, and messages for monitor start with M or m. Numeric values only, no labels, and all numeric values are separated by comma.

     

    This should suffice for the short term, and a more robust protocol can be developed after an interface is constructed. I will provide the code in the course of the next installment. I will also leave it as an exercise to try at home.

     

    Jack

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

    Time for a review...

     

    Control processes for A/D, EEPROM, Serial I/O, Timers, and input triggers.

    Table processing for linear and planar interpolation.

    The 16bit solution

    Basic scheduler for timed events.

    Synchronization of crank and cam signals.

    Steady state fuel calculation.

    Basic principles for ignition timing.

     

    Communication of values is a good discussion. My observation is, if you count up the number of engineers in a room (n) and pose a problem, you will get at least n+1 solutions. There are a significant number of communication protocols to choose from, and by protocol, I mean what gets sent, not the medium or transfer mechanism. Serial communication being the available data transfer mechanism, and using something simple to start (19200,n,8,1). In case it is not known, that is 19200 bits per second, no parity, 8 data bits, and 1 stop bit. Not going to go into any kind of detail about how serial shift registers work, or any more about the communication hardware than I already presented. The input and output sections are buffered with a put/get interface and background interrupt processing. This leaves only the messages being transferred.

     

    I have done many different forms of messaging protocols, with varied levels of success. Each implementation has had strengths and weaknesses. I had thought of implementing a full 488.2 SCPI protocol, but decided it was a bit excessive for what I wanted. I had even created a small operation version that I used for testing at an earlier implementation. Looking at the needs of the system, there aren't many messages that need to be sent.

    1. Read calibration data from EEPROM

    2. Write calibration data to EEPROM

    3. Configure monitor list

    4. Read list of monitor values

     

    The example I like to use for messaging protocols, so I can remember to include everything is the letter (snail mail). Examining the letter, there is a stamp, which represents size and priority. Next there is an address of the receiver, and a return address of the sender. The envelope provides the container for the data, and the letter is the content BLOB (binary logical object block). Going super cheap, and limiting development, the messages should be maintained as human readable strings, or should have a human readable instruction set. This way a standard serial communication terminal program can provide the general interface.  I'll fill in more tomorrow, but for now simple, simple, simple.  No size component, and no priority. Messages will end with either a newline or a semi-colon. Read messages are upper case, write messages are lower case. Messages for calibration start with C or c, and messages for monitor start with M or m. Numeric values only, no labels, and all numeric values are separated by comma.

     

    This should suffice for the short term, and a more robust protocol can be developed after an interface is constructed. I will provide the code in the course of the next installment. I will also leave it as an exercise to try at home.

     

    Jack

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Cancel
Children
No Data
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