DIM Electronic Advance Ignition

-
I should have said silly in my mind. Since timing is derived from a reference point, moving it with mechanical advance creates uncertainty. My electronic advance reads out the degrees of advance as real time information. To do that would require distributor mechanical advance that is repeatable, and curve entered. It has been my experience in evaluation, that mechanical advance is less than ideal. I see it more as chop it off with an ax, and measure it with a micrometer, cut with a laser. For me it makes sense to eliminate the ax. The ax adds to uncertainty.

Please do not let me change your plans. I am obsessed with this project. It is all about a fixed timing reference, and electronic advance from that.

I made initial on-car tests, and have just completed a small change in hardware, and a few in software.

The weather was nice so I went to a couple car shows. I will do more testing this week.
 
An elegant approach. Since you have a plenty of processing capacity, you might think about adding knock detection to the unit. Hard to find a new car without a knock sensor.

Here is some info on DSP and knock detection. They cover the signal conditioning and implementation of knock control:

[ame="http://www.ti.com/lit/an/spra039/spra039.pdf"]http://www.ti.com/lit/an/spra039/spra039.pdf[/ame]

With the kind of timing accuracy you are aiming at, might as well make it do a cylinder by cylinder knock control too.

Good luck with your project.

B.
 
bohica2xo said:
Here is some info on DSP and knock detection. They cover the signal conditioning and implementation of knock control:
B.
Click to expand...

Kit might have the gumption to tackle home-made knock sensing, but most don't since it requires research engineer knowledge. While I have done similar in my day job, for my cars I took a knock sensor and module off junkyard GM trucks (85-95). The sensor screws in a block drain (slants need a 3/8 to 1/4 NPT bushing). 1 wire from sensor to module and 1 TTL signal out for knock. Should work on any pushrod engine.
 
Thank you both for the information. About knock detection. The knock signals have a frequency, based on engine dynamics. Things like, block, heads, and materials. The senors are typically specified for a particular engine. The ignition signal needs to be used as a reference to window the signal to reject unwanted mechanical noise. I might go ion sensing, and eliminate the knock sensor.

I am off on a different tangent at the moment. I have the ignition working well open loop, on my stock 273 application.

I am now working on a wireless interface, for Android devices, for use with the ignition system. I have tested my hardware interface, and developing the Android application. I am new to Android development, but my progress has been better than I expected. Most of the planning work is already done, it is a matter to porting the existing Windows application, to a different OS and compiler.
 
Kit:

Most of the formulas are in that paper, as well as the frequency parameter / priority strategies that TI worked out to sell that part to GM.

Worth a read even if you go another direction.

Keep us posted on the progress with the ignition.

B.
 
I will read it further. I did notice the use of DFT. I am familiar with that. I am good at employing real-time math with simple methods. I also have experience with TMS320F2800 series DSP. I favor fixed point, over floating point units suggested.

By going ion sensing, I can completely eliminate the mechanical sensor issues. No need to worry about multiple sensors on a V8 and their location. Or the differences in iron vs aluminum heads and engines. The ion sense will check each cylinder and provide many other parameters beyond a knock sensing.

Before all that, I will go crank fire direct ignition.
 
Here are a couple screen shots of my Android user interface for the Ignition Management System (IMS).

Please ignore the data, it is fictitious and for test purposes only.

The top is the real-time display, the bottom is the data logger. Both are just a start, and need additional details added.
 

Attachments

  • ProgBar.jpg
    6.5 KB · Views: 365
  • ChartScrn.jpg
    29.2 KB · Views: 362
I got sidetracked. When testing the ignition I noticed the transmission was starting to slip so I rebuilt it. Then I went after oil leaks while things were apart. It is hard for me to stop. It is going back together after changing engine gaskets, and working on powersteering seals.

I did purchase Hall sensors for crank fire ignition. I am disappointed with the standard mopar electronic distributor. There are timing errors, they are related most to the small reluctor diameter, stray magnetism of the reluctor teeth, run out, and slop in shaft. By using the large diameter of the ring gear timing errors will be minimal.

I also purchased a tablet, and have the Bluetooth hardware and test communications working bidirectionaly.
 
KitCarlson said:
I noticed the transmission was starting to slip so I rebuilt it. Then I went after oil leaks while things were apart. It is hard for me to stop.
Click to expand...
Sounds like the work on my Dart to date. At least I will have most parts like new when I start driving it. My mistake was working around parts that I ended up taking off later to repaint or rebuild.

KitCarlson said:
I did purchase Hall sensors for crank fire ignition.
Click to expand...
I put a custom 26-1 wheel on my 273 crank pulley with a pickup mounted off the top water pump bolts (behind pulley). I made a bracket for both a Ford (VR) and Mopar (Hall) crank sensor, currently former installed. Not using yet, just wanted future option. I might try a Ford EDIS ECU first, if my Holley Commander 950 can control it. Maybe someday AND that with a cam signal (Magnum distributor) to fire individual GM LS-2 coils. I have all the parts, but little time.
 
I plan to look at the flex plate, and ring gear with a couple sensors. I will rig up a a micro controller and do some data logging before investing much time.

I plan to use coil near plug. I do not think coil on plug will work due to the angle of the plugs. A waste fire system with two quad coils will be messy, with spark plug cables crossing over the engine.
 
KitCarlson said:
A waste fire system with two quad coils will be messy, with spark plug cables crossing over the engine.
Click to expand...
Good point, Kit. I was kind of assuming a coil pack on each side with short wires. I didn't consider the firing order. If I try that, would probably use 2 Mopar 2.4L coil packs since have one and nicer looking than Ford EDIS coils. The LS coils I have are "coil near plug" w/ built-in ignitor so requires only a 5 V TTL trigger. However, I recall that signal must also include dwell, so maybe not simple.
 
Bill,

I have experience with the Mopar coil packs and they work well. They are rated at 6A and a nominal dwell of 4.5 mS, if I remember correctly. Dwell control with a uC is a predictive thing, it gets more complicated when dwells overlap at high RPM. It either takes more timer channels, and or juggling acts in firmware. There is also a voltage component, since coil charge time is voltage dependent. I doubt the 950 can drive the coils with universal firmware. I merely create new flash code for each special engine application, and boot load the code in less than 10 seconds. 95% of my code stays the same, it is just a few timer interrupt routines that interpret timing signal inputs, and timer compare outputs that require change. That 5% is not always easy, and is time critical. It is connected to the rest of the system in an optimal way, to provide and get the numeric resources.

It is my opinion that the LS coil with internal IGBT puts the control signal in harms way from an EMC perspective, and the IGBT in a hot spot. It has the advantage that the coil and IGBT are replaced together. That is good because in theory if either fail, they take each other out. That is because IGBTs likely fail shorted, and burn up the coil, and a shorted coil does not limit current, and fails the IGBT.
 
We had a rainy day so did some android programming. I am getting bits and pieces of it going but far from complete. I need to do much work in the visual presentation. It is a learn as I go, and try the many options of colors, and techniques. This is first picture load using my tablet.
 

Attachments

  • Screenshot_2013-01-10-19-47-49.jpg
    13.5 KB · Views: 286
More rain, more work. I added real-time gauge bars, for tuning. While the screen is small, they are essential. My screen is 7.0". The resolution is much better than shown below.
 

Attachments

  • Screenshot_2013-01-12-10-39-10.jpg
    15 KB · Views: 277
Del,

Thank you for the comments. I have been working with electronics for about 50 years and programming for almost 40 years. I am not an expert, but have much varied experience. Computers are very honest to work with, and consistent. I have programmed in many languages, they are similar in their basic structure.

Going from wired RS232 to bluetooth prompted me to consider adding more protocol for the data interchanges. The protocol will take care of missed or faulty communications, if that happens.

To speed development, I am writing software on the PC using VB to simulate the IMS. It it has visual debug screen, so I know everything about the communications and data that gets changed. It removes me from the IMS hardware, so all is on a single PC and tablet. The tablet is programmed from the PC, and only takes a few seconds to load the new program. A bluetooth USB dongle provides the wireless interface.

The android is programmed with B4A (Basic for Android) it is much like Visual Basic. Screen components are added in a drag and drop way for buttons, text and other visual components. Then code is written for the required activities. There are libraries that do most of the fancy work, data just needs to be passed to fill the necessary parameters. It is like filling in the blanks in a form. The plot at the bottom, progress bars and buttons are examples.

I hope that someday we can test my unit on your distributor machine. I think it might be spring before I am ready.
 
More rain here, so more time to program. Most of the prior was testing screen options. I now have functioning code with communications to my test system. I found making it work for portrait and landscape took only a few minutes.

The editing part for spark tables and plot works well. The table line is touched, then the green cursor keys select item in red, and + - are used to change values. The plot follows changes. I need to work the aesthetics of, color, sizes and text styles. Any comments are appreciated.
 

Attachments

  • Screenshot_2013-01-30-17-33-00.jpg
    15 KB · Views: 248
  • Screenshot_2013-01-30-17-37-08.jpg
    27 KB · Views: 243
Kit,

Can you explain how the user edits the tables? Most engine controllers I have seen require one to enter values in a 2-D table ("engine map") where fuel flow is a function of 2 variables - rpm and manifold pressure. Ditto for spark timing. This seems tedious and error prone to me, since there are many cells in the map and most people can't emulate a dyno while driving their car. I would prefer dealing with smooth functions (curves), say a 2-D plot where one pulls it up or pushes it down in regions and the whole surface follows, kind of like sculpting a car body on the computer with curves. However, I am just going by what I have seen in manuals and have yet to play with my Holley Commander 950 which uses the old map method. I can see why people love the new "self-tuning" controllers.
 
Hi Bill,
I can elaborate some on the tuning. I am an inventor, so there are things I desire to patent, I may be sketchy. There is also a time limit to file. The 2D Fuel map you are thinking about is 3D. There are 3 dimension: RPM, MAP, and Fuel. Plotting values, results in a surface, perhaps looking like a pile of sand.

To complicate things, there are WBO2 tables, TPS, time, temperatures, knock, sensor trends, learn tables and more. Some controls are done with fuzzy logic, where modes of operation are identified. An example is when to go into closed loop operation, certain criteria must be met. Much of what I am saying related to speed density systems. My systems are synchronous and inject fuel and control ignition for each combustion event.

So for simplicity on some aftermarket systems, some controls are ignored. The Pro-Jection system Del was working on did not have MAP. And from reading posts it did work well. I cannot imagine a system working without MAP.

My first injection controls were multiple 2D tables. Rpm and Timing. TPS and Fuel; MAP and Fuel; MAP and Timing; Cyl Head Temp. and Fuel, Charge Air Temp. and Fuel: and TPS derivatives and Fuel. There were also crank fuel and just started fuel controls. These simple controls could be tuned to get acceptable performance and economy, slightly better than carb and distributor w/RPM and vac advance. I drove about 9 months with a Ferret 5 gas portable analyzer. From the Ferret and data logs, I decided to go to 3D fuel tables. Then when I moved on to Turbo injection I added WBO2 3D mixture controls and associated fuzzy logic. I am a simple person by nature, yet a perfectionist, I add only that required in the most basic way.

Back to your original question. In the "simple" ignition system, there are 3 2D tables. I will talk about the 2D RPM and MAP (ported Vac). This is like mechanical advance, and vacuum advance. To set there are X values (10) for example that can be changed for each. Simply tap on the curve heading, RPM then use <, > keys to select value to change, it turns to red text, then use +, - keys to change values. Save is used to save changes in non volatile memory. This can be done with a running engine. Two people are always used, one to drive, one to tune. Real time displays, and data logging are also operating, along with human senses. Do acceleration runs and other driving, go back home use Excel or other spread sheet to look at data. Repeat. I can write for days about the mathematics involved in to use the data, but will spare the innocent.

The plots change with the curve selected. I am also adding other helpful features.

There are limitations in the "historic" mechanical distributors. Past posts cover this. The electronic advance ignition system provides significant improvements.

I will elaborate more as time permits. Progress has been good on the Android programming. I have been learning graphics programming needed, generate data recorder plots.
 
Here is some more BS.

Engines are forgiving in fuel and ignition timing, for them to just run. Run correctly no. If one or the other is correct, then either can be off more. An engine tuned correctly to 1 to 2% for all operating conditions is near perfect.
An engine will sometimes run 10 to 20% off on fuel, and timing off by as 20 or more degrees.

Many think about tuning as a one point adjustment. An example is base timing by rotating the distributor, or adjusting idle mixture screws. Those that tune, mechanical and vacuum advance get better performance. Those that change jets and accelerator pump settings gain too.

Some use locked timing at 32 degrees (like on a simple 1 cyl lawnmower engine). Works at WOT, but not as good as it could.

Others use mechanical advance, and think vacuum advance is evil. Time is spent adding cooling fans and radiators to control overheating at cruise conditions. Fuel economy not so good, poor throttle response at light load. Many will argue it works for them...

Then the mechanical and vacuum advance distributor. To get what is needed for some conditions results in too much for others, it is a compromise. Even changing vacuum cans is not the solution. Vacuum advances are crude, even with the adjustment screw.

Engine management systems have more controls that are adjusted in non mechanical ways based on numbers, the controller uses accurate time measurements to control fuel delivered, dwell ignition timing.

In the electronic world much more is available. An example is timing can be retarded at high RPM to serve at rev limit. The only thing close to that is a rev limiting rotor on some Bosch distributors.

A 3D system enables settings that are not possible with independent RPM, and vacuum advance systems. The table is a matrix. The interplay of what happens, for the combination of RPM and MAP, is controlled. The problem as Bill has alluded, to many is a mystery. Too many cells to adjust, some are non germane (may not happen in normal driving conditions). One has to understand the limitations of the typical 2 2D systems that our cars were born with. Only a few have done enough tuning work, to find and understand the deficiencies.

All of this is about open loop, or the fall back position from WBO2 and knock feedback systems.
 
Kit,

You have a good understanding of the complexities. Some variables have a fairly minor effect and/or a simple algebraic equation can manage them, with no input from the User. The effect of IAT on required fuel flow is an example. The Megasquirt manual shows how they use a fixed equation to account for IAT (I recall). Users need more simplicity, which is why self-tuning controllers are so popular.

I have designed controls in engineering for decades. Open-loop control is termed "feed-forward". Ideally, the equations (predictors) adjust the outputs (fuel flow, spark timing) so the desired setpoints are hit directly (desired O/F ratio, max spark lead w/o pinging). Of course, that is never perfect, due to unmeasured variables (camshaft & valves, exact displacement, gasoline quality, fuel pressure & temperature), so one uses feedback (O2 sensor, knock sensor) to move exactly to the setpoint.

In our cars the factory designed only crude mechanical feedforward controls - accelerator pump, vacuum secondaries or air valve (4bbl carbs), centrifugal and vacuum spark advance. The only feedback is very slow - owner adjusts distributor to the ping limit, changes jets and rod distances, and such. Electronics are much better, but not simple or cheap. It does seem they could be cheaper though. We saw a promise of that in the RabidGator spark controller, but I have yet to see an actual product. Megasquirt had the promise of cheap, but reality is ~$500 and much installation effort.
 
Bill,
You are correct, l have used IAT, or CAT by adding fuel per air density based on temperature. I is simple ratio with temp in Kelvin. There are also setting on the upper end to enrich for air cooled, or saturation. Without those there can be potential overheating, thermal run away due to going lean.

My system does more than the rapidgator brochure. It is also packaged in a way that works for EMC. There are obvious faults in the rg implementation, and if used with a non locked distributor would be a disaster.

I am also going to improve the method of timing sensors. I am disappointed with the mopar VR. The precision in my timing far exceeds the reference signals. The OEM timing scatter is not much better than points. The GM style VR used in the rtr HEI CHINA dist could work, but the guts in those are a mess. You might want to see how far you get taking one apart. I take every thing apart, but stopped with it.

I think I can change to a better reluctor design on the mopar dist and go Hall sensing. I have also considered crank or CAM sensing and have some work going in that area.

I am working on the Android application. It will be much better in the car, note book hinges take a beating.
 
You must log in or register to reply here.
-

Back
Top