openecu.org

Hey guys, I've been reading up on what everyone here has been working on and I think that what you guys have accomplished is great.

My team and I have been working on a piece of hardware for driving injectors and coils. I'm thinking about taking the software/UI side of it open source. What do you guys think about working on a project like this? Instead of reverse engineering an ECU, you could start from the ground up.

At first, it sounds like a piggy-back, but it is actually a post-processor. Instead of tricking the ECU by modifying incoming sensor signals. We let the ECU terminate the outbound signal and then drive the coils and injectors any which way they are programmed. So, this unit can be universal for most any application. And, so long as OEs still use coil-based controllers like coils and fuel injectors, it shouldn't get outdated.

I'm interested.

What kind of micro are you using? Do you have working samples yet?

Were using a Microchip PIC that is dedicated to processing, driving and firing each winding. So, at this time, 1 PIC per ignition coil, and 1 pic per fuel injector. The algorithms are down. From a hardware perspective, I would actually like to know what you guys would want.

Do we need a separate processor and memory chip for what you guys think would be ideal? Or is there an integrated processor/memory unit that you guys prefer.

We have 1 processor per chip right now because the code is dynamically measuring and outputing the current each winding needs. That's kind of where the innovation is. Any injector, any resistance, any current, we're only limited by the time between cylinder events. Any coil, the circuitry self calibrates for the current that coil can take.

Have you also got a way to measure the crankshaft position, so that the fuel and spark timing can be wholly controlled by your hardware? Or do you base your own timing on the original ECU's fuel and spark signals?

NSFW wrote:Have you also got a way to measure the crankshaft position, so that the fuel and spark timing can be wholly controlled by your hardware? Or do you base your own timing on the original ECU's fuel and spark signals?

Crankshaft position by means of any sensor can definitely be used as a triggering event. But the problem with triggering off of any type of rotation sensor then becomes the issue of universality. You now have to have in the code or hardware a count for the type of trigger, magnetic, hall, etc. Then how many teeth are there in the system that you are putting the controller into?

It really starts to deviate away from the scope of this particular piece of hardware. There are many good standalones out there that can already do this.

By triggering off the factory injector signal, there are already many knowns. Especially when it comes to cranking. You can basically take this box and put it into any application that needs to richen/lean the mixture or advance/retard the ignition timing. The goal for this hardware is to give the average Joe something easy to use. Especially for those guys that may be in the middle of nowhere with a 6 hour drive to the nearest dyno/tuner. They can basically take an air/fuel ratio meter, and simply add/subtract fuel to meet their needs.

Also, for the sake of robustness, triggering off of the injector/coil signal eliminates the need to have access to the primary code within the driving processor. So that no matter what, the car will still drive OEM, if anything gets corrupted on the EEPROM that has the settings.

Although its a PRE-processor not a POST-processor, maybe it would be easier to use an XEDE. The software to tune it with is here:
http://www.xede.com.au/files/XMap3%20V3_0_3_8.zip
or peruse the site
http://www.xede.com.au
The post processor idea has plenty of merit but then you need to deal with various Injector and Igniter/Ignition types and currents as well including multi-spark which is becoming very common on late model applications.
Just my 2c worth.

Cheers
Lachlan Riddel
ChipTorque

Thanks Lachlan, I'm going to dig through those.

The post processor idea has plenty of merit but then you need to deal with various Injector and Igniter/Ignition types and currents as well including multi-spark which is becoming very common on late model applications.

Here's where the innovation is for our hardware. We've finalized the code so that you don't have to worry about what injector or ignition coil it is. At the end of the day, it is just a winding. Our code and circuitry dynamically reads the current required by each injector and coil and drives it accordingly, so that any injector that you can mechanically fit is plug and play.

And then regarding multi-spark, I really don't know how many OEM systems use multi-spark, since they aren't very good for emissions. At least multi-spark CD systems are pretty bad for emissions because the initial charge kernel isn't as hot as an inductive system. Although the peak current is higher (amplitude), the overall wavelength and subsequent spark energy is lower. We're sticking with the inductive side of things so that if a kit maker decides to go and CARB a kit with this hardware on it, that it can pass emissions easier. We also have full dynamic control over dwell, so we're able to drive as much current into the ignition coil as it can take. The code reads the amount of dwell that the coil can take and feeds it that max current without burning it out.

Nice work.

synchronic wrote:And then regarding multi-spark, I really don't know how many OEM systems use multi-spark, since they aren't very good for emissions. At least multi-spark CD systems are pretty bad for emissions because the initial charge kernel isn't as hot as an inductive system.

Ford just to start with and, as far as I know, it's precisely for emissions that it is used. I must research that a bit more.
Cheers
Lachlan