Thread: Open Hardware COP controller

Once I had the bcd output, I needed to translate this to cylinder position. Using a 4028 bcd to decimal decoder I could output 1-2-3-4-(5) (sequence). To add redundancy to the design I added a second reset signal. IF the reset circuit failed to reset the sequencer, the output of (5) from the bcd to decimal decoder was used to reset the sequencer. The intent is that IF the 360 trigger drops out, for any reason whatsoever, then the position trigger can still run the engine. Now most people dont know that the ecu operates like this too. Once the engine is running, you can remove the 360 degree trigger signal wire from the harness and the engine will still run. Does it run well? No but still very drive-able. But you cannot start the car with this signal removed since it is needed to set the sync for the ecu to fire the injectors.

http://www.nxp.com/documents/data_sheet/HEF4028B.pdf

The final piece to the puzzle is the drive circuit. Now most "smart coils" have a high power transistor built in, this is why they are call smart coils. These are either IGBT transistors or MOSFET. They produce the same result just in a different manner. MOSFETS are voltage controlled transistors and IGBTs are like npn/pnp transistors in that they are current controlled transistors. What this means is that depending on the coil you use, you can have different current requirements. So in order to match the BCD output to the ignition signal from the ECU I needed an AND gate controller high current driver. The TC4468 High speed, High amp ignition driver was the perfect choice. It can withstand inductive kick back from firing a coil directly. This was the best choice for the ignition driver since it was designed to drive ignition coils.

http://www.mouser.com/ds/2/268/21425b-23977.pdf

For the uninitiated this is whats called discrete logic. There was no coding involved at all. This is was using tech that was available back in the 60's. Ive seen some patents using nearly the same technique. But I have made a version based on the PIC16F84 and PIC16F88. They are untested though but I will be getting a few boards made up for testing soon. By being able to code the logic I have been able to reduce the design down to 2 integrated circuit. The PIC MCU and the Ignition Driver.

The programs I used to design everything are as follows:

Multisim: Circuit design and simulation. Has thousands of name brand components that allow for seamless integration to pcb design, also has a pcb design tool. What makes Multisim very useful is the MCU simulator. The student version only supports the PIC 16F84, but it allows you to upload the hex file to Multisim and run the program. VERY useful for MCU programming.

MicroStudio: PICBasic Pro 2.6. This is the coding environment that I used to develop the code for the DISSR. PICBasic Pro is a simplified coding language that is specific to the PIC.

Eagle CAD: Eagle is by far my favorite PCB design suite due to the massive amount of vendors providing component libraries for Eagle, for free. Hundred's of thousands of different components available for design. The free version of eagle is good for 2 layer pcb.

AutoCAD: I think everyone know what Autocad is. It's good stuff, but seems to be showing its age in comparison to the new enterprise level CAD programs.

All of these can be found for free, pm me if you want to know how to get them.

Its crude, I know.

Eagle Cad files.

https://drive.google.com/open?id=0B53t_ZvnBllXeUxkenItdVFVd28

https://drive.google.com/open?id=0B53t_ZvnBllXTTlzd3R2UE5YLW8

Outstanding work. This takes me back to college courses for sure.

I don't have time at the moment to wrap my brain around what's going on here, but I do have a bit of electronics background and I can see what's going on. It does sound like a bit of a brute force way of doing it, and there may well be room for improvement, but if it works, that's more than half the battle.

You mentioned syncing to the ECU, what signal there exactly are you syncing to? Different ECUs will have different pinouts, so it would be good to know the exact line used and what that's normally doing to better understand the circuit.

I happened to be doing some unrelated reading on vacation and the Coil On Plug technology was covered briefly. One thing that was mentioned was that since this technology creates a better spark faster, a COP system could actually fire twice during a cycle where a distributor system would only fire once. I never really thought much about this, but apparently an inline 4 engine will have two downward piston strokes per spark, I found a cool animation showing this:



Since the COP system can produce a spark faster without the delay recharging, it can provide a 2nd spark on the 2nd downward stroke and help burn any combustible gasses still present, which is basically free power and improved emissions.

So, question is, is your programming set up to allow for this 2nd spark? Seems like an easy thing to switch on or off if needed to see how it performs.

@jimbo_se-r The sync I refer to is simply putting the controller sequencer in sync with the engines firing order based on the cam sensor. If you take a look at the timing tables i posted you can see how the "sync" is worked out. This actually makes the design adaptable to other models, and one day different makes too.

The newest code I have written is bare bones at the moment but functions exactly like the discrete version posted above. Now my controller is kinda like a window switch where as it opens a window for the ignition signal from the ecu to fire the windowed COP. Yeah I suppose a pretty simple double tap could be done. Without doing a RPM/load calulation in MCU I wouldn't be able to make it dynamic, but yeah it can be based off of the cam sensor 360 degree window. It can put the second spark within a 2 degree window.

Very slick! A bright future is ahead of you.