Computerized ignition (DIY ECU)

[Tesla]

It is a 1981. Not sure whether or not it has a mechanical advance. How is that usually implemented?

Regardless I love my electronics projects so I'm going to go on with it anyway. Has anybody found a really good way to model an ignitor circuit (coil and plug) in spice?
Thats what I am looking at right now. I am looking at purchasing some extremely high power mosfets that can simply handle voltages as high as 400V or so. While this is currently an option they are kind of pricey for FETs. I was also looking at simply adding flyback diodes on the circuit although I am not sure how much this will effect the ignition ability. I will need to simulate and test this and I will get back.

As for the arduino, I plan to go with the pro mini. I only really need two interrupts (one for each coil) and if I want more I can write a handler and mux some of them together. It should provide more then enough speed to spark at the correct time. Even at 10k rpm (may be off by a factor of two here) we need to fire at 10kHz (once again may be 5k). I expect the interrupt for each ignition to be around 150 clock cycles (could be down to around 30 or so without using arduino libraries). Even if it were to take 500 clock cycles (would be really slow) I would still have about 500 clock cycles (underestimating again) to do everything else I need. Let me know if anything seems off here, but I believe the pro mini should be more then enough to run the whole thing.

[posplayr]

There are off the shelf ignition drivers which I personally would choose if doing anything like this, unless you want lots of reliability problems and other headaches. Of course if you are going into analog circuit design, go read up on the commercial solutions before trying to "one up" them. There are plenty of Ap notes on ignition circuits and MOSFET and IGBT applications.

1 degree at 10K RPM is 16 usec. You have plenty of clock resolution with most chips running 20 Mhz+(50 nsec), Bigger issues are noise and the calculated timing (brute force algorithms) that will corrupt the inherent resolution available;

Since you are an EE do a basic noise analysis; If you measure RPM as a straight time difference between edges then that is a differentiator (i.e. delta edge time) and it has intrinsic noise amplification proportional to frequency. Any ideas on how to combat the issue?

If they still teach communications theory, lookup phase noise in PM/FM systems.

To be plain, clock resolution is not the challenge here you have plenty. You will be facing the same issue that most RPM tacho meters have in avoiding bouncing RPM displays but in the case of ignition you have can't just average it out and expect to fire the engine at the correct time.

[Tesla]

Thanks posplayr those are some great points. I will keep them in mind and work on solutions. Do you have any experiences or recommendations for off the shelf drivers?

They do still teach communications theory, but it is taught as a masters class and mostly deals with digital error correction from what I have heard.

I will keep reading some of the papers out there and think through possible solutions. I am currently working mostly on fixing a bent valve thats been giving me issues, so I should be focused on this more full time in a few weeks.

Thanks a ton again for all of the help and ideas

[bobgroger]

It is definitely more for the fun of it then anything. I have a lot of experience with electronics and coding and would to put them to a fun use. The ignition will be interrupt based. Hopefully everything else fits in between interrupt calls. If not I have some faster arm controllers I could use, they just take more time to fully set up. Thanks for the tip on the R/R and stator, I will definitely give those a look. As for the analog part, there will definitely be some experimenting to not blow everything up when turning on those coils. I guess we'll see how it goes! Thanks for the input

It's turning them OFF that causes the fireworks...

[posplayr]

Thanks posplayr those are some great points. I will keep them in mind and work on solutions. Do you have any experiences or recommendations for off the shelf drivers?

They do still teach communications theory, but it is taught as a masters class and mostly deals with digital error correction from what I have heard.

I will keep reading some of the papers out there and think through possible solutions. I am currently working mostly on fixing a bent valve thats been giving me issues, so I should be focused on this more full time in a few weeks.

Thanks a ton again for all of the help and ideas

A while back I was going to design an ignition product to include an IoT backend. I'm still working on IoT but in areas where there would be larger markets.

These are some of the parts in my folder that I had collected. You should do your own research as I'm not prepared to share pros and cons but just provided this as representations of what is available.

VB526SP-E
MC33153
IR4426

More and more I can see that you should be doing your own PCB layout. I've been using KiCAD so there is no reason to not be using surface mount parts. My last design has 0.5mm pitch parts which are a bit of a challenge for hand soldering but using plenty of flux, stencils and hot air station you can at least cobble together a prototype.


As far as communications my gut is telling me that it is going to be real easy to get a noisy firing circuit if you do a brute force implementation. Noise RPM meters and tachs are direct indications of brute force methods.

I understand the world is much more complicated than when I when to school, so there are plenty of classes to take other than random signals analysis. However, this ignition is to my mind a mingling of the basics of random signal analysis, communications detection theory and simple control systems. In a single topic: "Phase Locked Loop" (PLL).

Rather than focus on the drive circuit, focus on experimentation using a simulation. Use matlab/simulink as opposed to SPICE. How your software processes the noisy edge data to project forward the firetime as the RPM is varying is the problem you are dealing with.

The forward projection in time requires the addition of an integration to break the high frequency noise characteristics(previously mentioned). Two would be better. There are also "delay Lock loops" but ignition timing is done in terms of engine phase so PLL is a natural.

https://en.wikipedia.org/wiki/Phase-locked_loop

You indicated you are just completing your undergraduate work, but I'm not sure if that would include a class in Control systems. You would probably want to keep the PLL implementation simple and you could use the link above as a good starting point.

To reiterate why this is an PLL type applications is becuase the edge detection from the engine pickoff is equivalent to a phase detection attempting to measure relative phase with respect to a independent reference (in this case the NCO). The faster the RPM the more phase noise. In a fast acceleration you have to project the current fire time relative to the last measurement but also in terms of the estimated acceleration of the engine ( rate of change of RPM).

The NCO gives the projected phase (i.e. engine crank angle) at any time into the future. The NCO instantaneous phase is adjusted based on the measured phase errors at each zero crossing. Noise reduction on the zero crossing is detection theory.

The reason control systems is important is that the PLL provides both a filter and an estimate to project into the future. A PLL with even a simple PI (Proportional + integral) gives you type 2 response to phase error with the noise rejection of double integrations.

You need to be able to run some code like this so you can see how the variables interact.

[Tesla]

Great thanks! I will look into that and let get back in a few weeks and give an update on how its going!