GenBoard/VerThree is relatively easy to apply to any fuel injection gasoline engine. However, why not try to make it even easier?
There is also the possibility to cooperate with a factory ECM (which usually makes the setup more complex and problematic). Read below.
Piggyback related terminology
- plug-and-play (eg. PlugAndPlayJetronic): an ECM applied to a specific connector and set of sensors to provide plug-and-play install for a given unmodified harness (or rather plug-and-tune, since tuning still often needed unless someone has done it already and published results). One can use existing tables (no need to retune). Usually some extra wires are used for WBO2 (the dumped ECM rarely features WBO2).
- runtime piggyback: cooperating with an alien ECU (design compromise to try to save on some hassle) to provide engine control. There are several ways to achieve this:
- intercepting ignition and injection signals: this is very problematic and complex: the piggyback ECM has all the signals that is enough to control the engine, and it has some extra signals that are not really needed (injection/ignition outputs from the original ECM). These just add to the weight/uncertainty/problem sources/costs/wire jungle. NOTE that this works, but is an awkward way for this task. See MAP/MAF substitute below, or see plug-and-play above for better options.
- MAP or MAF substitute (fooling). If one want's to keep the original ECM (instead of going plug-and-play, see above), this is the best option. By fooling the ECM (makes original ECM think it is running at lower MAP/MAF, except where the extra fuel is needed, of course) it allows swapping in significantly larger injectors (+30..100% vs. +10..20% that is upper limit with original ECM if MAP/MAF fooling is not applied), also nice closed-loop lambda control (using WBO2).
- tunetime piggyback: watching inputs and intercepting or just watching outputs of an alien ECU for diagnostics (detect faults) and logging the control tables (maps). This makes a lot of sense, when used as a tuning aid (vs. runtime piggyback that is used all the time, for driving). The tuned maps are executed with a normal ECM ( native or plug-and-play style install) during production-runtime (without interception).
- goals are simple(r) to meet without piggyback solution
- layout specifies a piggyback, which can be done with GenBoard existing hardware (read below); however, a similar, optimized "tunetime piggyback" hardware would make sense to develop for a specific segment of the market (if 200..500 can be sold )
I want to develop an open source engine piggy-back controller. The idea is very similar to your project here, except I want to minimize initial tuning by taking inputs from the stock ECU.
Many hours went into their testing and I want to preserve much of that. However, I want flexibility to tune my engine based on my modifications.
People try this from time to time and almost always come to the conclusion that runtime piggyback with intercepting injection signals is nothing but a pain: More wires, more connectors, more things to fail and even when nothing fails, control is just worse (unless you have a tuningprogram that can cope with both ECMs at the same time: which you don't).
With a friendly ECM, no tuning is lost, you have all the config and tables that you tuned. With a foo-ECM (that is tuned without knowing what is tuned (?!); or rather tuned by others with no direct access to maps) ignition and injection can be logged (even on the table, without driving), see OnlineCourse/AlienIgnitionLogging.
My target application is the Dodge SRT-4. We already have 4 different very well tuned ECUs. The engine is tuned, not the ECU. The ECU is just a way to execute the tables tuned for the engine. The same tables can be imported to any ECU, so the installed ECU can execute them.
Runtime piggyback is not needed to save tuning work. In fact, to carry existing tuned maps is a software issue to help users converting tables from different formats to the format required by the installed ECM (this is often done manually). On the other hand, piggyback - if done right - is useful to reduce install-wiring work (plug-and-play is another way to reduce install-wiring work).
So, the plan is to have inputs for the fuel injector and ignition drives from the stock ECU and modify them slightly as needed.
Runtime Piggyback only makes sense to make an install possible with reduced wiring (5..6 wires). This is possible and feasible, but it does not involve taking the fuel injectors from the stock ECU. It involves MAP/MAF substitute (fooling) instead.
For example, adjusting fuel injector pulse widths to trim out excess fuel at WOT when using W/I (W/I ?).
I don't know if maybe I'm re-inventing the wheel and there already is such a project underway, or what... Perhaps a modified GenBoard could perform this task?
Anyway, if you really interested in details, check out my long-winded thread at srtforums.
http://www.srtforums.com/forums/showthread.php?p=2033955
The first page summarizes most of the project.
Is there a summary of the current state of the project somewhere? Or everyone interested needs to read the forum and neglect 95% and build the picture himself ?
The first post. I will update it with the current status as I make progress. Right now I'm just trying to figure what it is I need to design...
Doing that as a piggy pack controller seems both very cool and overly complex
I wonder if you'd be better off
- making a plug'n'play loom set to run a native VEMS ECU
- or using a simple input (eg, MAP/MAF) interceptor to adjust fueling. Eg, [here] and [here].
Richard just hit the nail on the head with this.
Conclusions
- There are better ways than piggyback to carry on existing tables (fuel/ignition/lambda maps)
GenBoard/VerThree can meet the SRTforum goals with the existing hardware
Re-layout the GenBoard is not necessary to measure output of existing ECM.
OnlineCourse/AlienIgnitionLogging handles 2 inputs (ignition or injection channel of alien ECM) already.
GenBoard already has 16 analog inputs, several are free that can also be used to precisely log outputs of an alien ECM with
- a very simple RC low-pass filter (of the right cut-off freq that matches sampling rate of the mcp3208)
- and some code: not too hard to reach appr 20 usec precision or better with averaging (that is always used for LogAnalysis anyway.
How to join
If you're interested in more serious related developments (either the technology or the fun or the business side), and you want to make something useful/working efficiently, you can leverage the significant experience of VEMS developers and join development (either at VemsExecutives/Firmware or VemsExecutives/HardwareDesign or VemsExecutives/TuningSoftware). You will be surprised that this takes appr. 50% tuningsoftware, 30% firmware and just about 20% hardware.
However, it only makes sense if project goals are established. Development makes no sense unless >200 (rather 500) units can be sold: design is "general" enough (without arbitrary restrictions) and it is .
It
GenBoard/VerThree has 16 analog inputs, that can be used to measure the injection/ignition signal of alien ECM with just firmware changes (no hardware changes).
See GenBoard/UnderDevelopment/StagedInjectors
Why not add control for 2 or more fuel injectors per cylinder.
This would allow for the accurate dosing at idle, but also give the capacity for a large enough dose to be administered while the inlet valve is open during the induction phase, thus enabling sequential injection right up to maximum rpm.
Combine this with an O2 sensor for each cylinder in the exhaust manifold, and we can potentially obtain close to perfect stiochemetric combustion on a cylinder by cylinder basis (and could also allow for better detection of misfires/burning oil etc).
This combination could also be able to detect and cope with injector failure and fouling problems, providing fault tolerance in the fuel injection system.
This is nice, but only feasible with a set of networked ECM (instead of adding 8 WBO2 sensors and 8 more injector drivers to GenBoard/VerThree). It is under development, see VemsFrontier/ArmEfi