Computerized ignition (DIY ECU)

[Tesla]

Hey guys. Just recently picked up an old gs650 has some mechanical and aesthetic problems that I'm currently learning about and working on. There were also some issues with the ignitor and R/R. The R/R I plan on simply replacing(let me know if you know a good place) but for both cost and fun I plan on replacing the whole ignition system with one I plan to code and construct. I also plan to use this system to control other systems(lights, turn signals, etc). Solution for the sake of time, I plan on using an arduino along with some fairly simple perf board circuits. Anyone have any tips or tricks before I get really going on the project?

 

[posplayr]

Draw a 1 wire diagram and a schematic along with your software design document

 

[dantodd]

For the R/R get an SH775 or a compufire. The oem were shunt based systems and killed many a stator. Also, check your stator health before getting too far along as a bad/weak stator can give you the fits.

 

[roeme]

Not sure if an arduino programmed above assembler is fast enough for an ignition.

but for both cost and fun I plan on replacing the whole ignition system with one I plan to code and construct.

I don't think it'll be cheaper than a points ignition. More fun, possibly.

Re. R/R; as said, definitively get a non-shunt. Sooner or later you have to anyway.

 

[posplayr]

Not sure if an arduino programmed above assembler is fast enough for an ignition.



I don't think it'll be cheaper than a points ignition. More fun, possibly.

The UNO/ATMega328 using floating point is pretty slow, despite the relatively high clock rate (due to software floating point emulation). Regardless with some care and using a interrupt based Timer Input and PWM output and fixed point calculations it is very doable to do the Ignition timing assuming he does not figure out a way to chew up a lot of clock cycles controlling lights.

The bigger issue is making sure he gets the driver circuits correct with sufficient voltage range tolerance to not now the blow the drivers from the inductive loads. Then again if this is just an experiment, then he can get something that is very robust albeit not very small (GM HEI modules) and be up and running with little fuss on analog electronics design.

 

[Tesla]

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

 

[posplayr]

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

Not that you need it , but I was at a seminar on STM32Cube two weeks ago. They are making it Soooooooooooooooo eazy now.

Figure on at least 250V ratings for the drivers.


EDIT:
After reading this thread you might think twice but, going bare metal is definitely more painful than having something to start with.

http://www.eevblog.com/forum/microc...ware-ecosystem-is-terrible-how-can-we-fix-it/

 

[JTGS850GL]

The Nano would have all the UNO capabilities in a much more compact design. Agreed that the ATMega328 should be fast enough to support ignition timing needs as long as the code is kept compact. No need for floating point math that I can see. A simple lookup table for timing curve should be all that's needed. There are two interrupts that can be utilized.

 

[posplayr]

The Nano would have all the UNO capabilities in a much more compact design. Agreed that the ATMega328 should be fast enough to support ignition timing needs as long as the code is kept compact. No need for floating point math that I can see. A simple lookup table for timing curve should be all that's needed. There are two interrupts that can be utilized.

Yea I was thinking Nano not Uno or there are some smaller but OP says he is doing perfboard.

 

[JTGS850GL]

I think he's doing perfboard for the peripheral components and using the pre-canned micro controller to drive it. Kind of similar to prototyping projects I've done in the past.

I like the Nano since it has all of the hardware capability of the UNO but so much smaller. Many of the smaller micro controllers don't have all the IO or interrupts that the Nano has. Adafruit also has the Trinket PRO in both 3.3V and 5V versions but are a little priceyer. I just picked up 10 of the Nano's from China for under $2 each on a "Make Offer". May take a month to get them but it's worth it if you're not in a hurry.

 

[dantodd]

I like the NANO too but if it's your first time with the Chinese cheap ones you will need a special driver. For the Macs it can be difficult to set up.

 

[Guest]

What year is your 650? Do you have a mechanical advance? I was having some ignition issues, or so I thought. The test on my ignitor didn't match up with how the manual said it should function, so I just replaced it with a Dyna DS3-2 since I still had the mechanical advance. For $133, it was a nobrainer for me to eliminate possible headaches.

And yes, SH775 R/R with a wiring kit from Eastern Beaver (or maybe I got the connectors off of Ebay, I can't remember).

I started playing around with building a tachometer using a Nano. Pretty basic, but I only tested it using a signal generator as input. Ended up buying a Trail Tech so I said screw it and scrapped the project.

 

[posplayr]

I like the NANO too but if it's your first time with the Chinese cheap ones you will need a special driver. For the Macs it can be difficult to set up.

USB hell............ I have some RS485 to USB convertors I bought from ebay and they seem to work except........ They drop a bunch of bytes at 115K baud and the FTDI chip is apparently grey market as it is not programmable using the FTDI utilities. I'm going to probably buy some replacement FTDI parts and just swap them out. FT232RL. The Ebay nanos I bought a while back seemed to connect with the IDE, but you have to be careful with it; just because it works at 9600 doesn't mean it will work at 115K and above.

With real FTDI chips and latest drivers I have gotten up to the limits (clock limits) of my ARM processor at 230K baud under Win7. It will probably go all the way to 960K (windows drivers) but I have not been able to push them that far.

I have had a lot of problems with Prolific driver mainly running on grey market USB devices. If you want to run above 9600 without headaches, but authentic USB parts/products.

 

[JTGS850GL]

Unusual I don't go above 9600 since I typically only use the USB port for sketch uploads and debugging slower events. With that said, I've had no issues with the Chinese grey market units do date. No special driver needed for the ones I've purchased. All have worked fine with the Arduino IDE. The only thing I've noticed is the USB port number assigned is different on the Chinese units. I don't use a MAC so can't say on that topic. I will say that I've been in the habit of using the same vendors for components. Once I've purchased from them and all works I will reuse them for future purchases.

 

[posplayr]

Unusual I don't go above 9600 since I typically only use the USB port for sketch uploads and debugging slower events. With that said, I've had no issues with the Chinese grey market units do date. No special driver needed for the ones I've purchased. All have worked fine with the Arduino IDE. The only thing I've noticed is the USB port number assigned is different on the Chinese units. I don't use a MAC so can't say on that topic. I will say that I've been in the habit of using the same vendors for components. Once I've purchased from them and all works I will reuse them for future purchases.

I have been consolidating all low speed serial communications in my UAV system including RS232/USB/RS485 and bluetooth into a full C++ stack mirroring the OSI standard. I have been able to push data at close to 95% baud utilization of a master slave- cmd response link over USB at 230 baud and would surely work at double that if I would get the ARM processor there.

9600 is so slow that virtually anything works. Depending on what you have the stuff will start to fail at 38K or have other really funny "features". USB three stuff runs at much faster speeds so I'm taking primarily about Virtual Comm port USB.

 

[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.