C/L WB/WOT OEM ECUs...

[mike mager]

Greetings!

This C/L WB WOT _OEM_ ECM project seems to be quite the (huge!) undertaking! 
  I can't help but wonder, what is the possibility of hacking an OEM ECU - 
from a blank EPROM?  Has anyone tried writing an engine-management program 
from scratch for an OEM ECU?

Thanks,
Mike
(I just woke up in the middle of night [0.2:45, local] to reboot windows)


>From: garwillis at msn.com (Garfield Willis)
>Reply-To: diy_efi at diy-efi.org
>To: diy_efi at diy-efi.org
>Subject: Re: C/L WB/WOT OEM ECUs...
>Date: Fri, 07 Apr 2000 00:29:00 -0700
>
>On Fri, 7 Apr 2000 01:12:31 -0400, "nacelp" <nacelp at bright.net> wrote:
>
> >I got several ideas, the basic question is to kludge or not to kludge.
>
>OK, to K or not to K, that is the question. (Sorry, I couldn't
>resist...)
>
> >... tps interception ...
>
>or...
>
> >  ...getting into the calibration file, and setting the PE
> >enable to 99%. and that should prevent the PE mode.
>
>I take it we could refer to this as "major PE-enable/disable tweaks"?
>
>So we have two mechanisms on the table so far. (1) is to intercept the
>TPS signal, which is almost always used to flag/force PE modes, and then
>we attempt to prevent them, by faking a false TPS input, and/or (2) to
>systematically disable PE as much as the cal tables will allow.
>
>OK, wellNgood, I understand the overall concept, but...What I'd like to
>understand further is, for say an example OEM/GM ECM, is there a bit
>that says "past this parametric point/level (TPS or MAP or whatever),
>enable PE (aka go to O/L)"? The real question to me seems to be how MUCH
>authority can we get over O/L vrs. C/L; not so much whether we can force
>it without exception. That's why I'm asking cases-by-cases.
>
>For example, we don't really care if there's no way to prevent the
>coolant temps, below a certain value, forcing O/L and major enrichment.
>On the contrary, we want that! We therefore don't need to worry about
>intercepting these temp sensor inputs. Just let them be, and if they
>force the ECU into O/L, no harm done; since actually we WANT them to go
>to major O/L enrichments in these cold regimes.
>
>But what we MUST accomplish for this concept to work (i.e., taking OEM
>ECUs into WOT C/L), is to be able to thwart the normal excursion of the
>ECU into O/L when either the TPS or MAP/MAF suggests we should
>'normally' go to tables. I can readily see how interception of TPS could
>be accomplished, BUTTTTTTT how about the ECU's normal transition to O/L
>when the load/MAP/MAF exceeds a certain level? Can we/should we
>intervene there? Reason I fear this is more problematic, is that we may
>not be able to just FAKE or fudge the load inputs, otherwise we lose
>needful accel and other transient enrichments that ARE really needed,
>because relying on the AFR feedback alone, may be too slow/sloppy (given
>that all we are getting is bang-bang controller response times; hey,
>even WITH tightly servo'd C/L O2 sensing, FelPro still allows O/L
>enrichment during major load/TPS excursions). What would be IDEAL (I'm
>dreamin here, so bear with me), is that we could control via cal table
>settings, the parametric limits of each of these inputs (or their
>derivatives/rates-of-change), be they TPS or MAP/MAF, so that we could
>say, beyond a certain level/rateOchange, GO to O/L and apply enrichment
>table values, but whenever these inputs settle below these extreme
>transient levels, then return to C/L and follow the "commanded AFR" (aka
>the stoich-crossing setpoint we fake/program using WB sensing).
>
>If we can do this across the board with most all key inputs in a
>table-driven manner, we CAN control when we KEEP to C/L and follow the
>WB O2 sensor, and at all the other times, we not only LET, nay...but
>DESIRE the ECU to use it's enrichment tables to control O/L the mix. For
>example, we WANT to ignore the WB O2 sensing when we're in
>cold-crank/start and during warm-up. We also WANT to ignore the WB O2
>sensing when someone transitions from 0 TPS to F/S TPS in a
>quarter-second, and use the table-driven enrichments. Same goes with
>rapid load excursions. If we can control via cal tables just WHEN we
>want to go to C/L, then we'll have cracked this cookie, and ushered in a
>new age of WB AFR control, where it counts most.
>
>It's good (or at least OK) to have O/L PE dumping safety-measures of
>fuel during a major power-up, during the first few fractions of a
>second; but if after those transients, we can accomplish forcing the ECU
>to lock on to a nice tight C/L 12.5AFR lets say, during the longer
>period of major acceleration, then we will have accomplished something
>quite useful. Because once we can control the AFR precisely during major
>power phases, we'll be able to test just EXACTLY what AFR is indeed
>optimum for acceleration/load, and then lock that in via C/L AFR
>feedback/programming. No more FelPro or Motec envy. :)
>
>If this can be accomplished within OEM ECUs, via cal table changes and
>sensor intercepts alone, where needed, without resorting to 'custom' ECM
>code changes, we've really met a horizon.
>
>Thanks Bruce for the spark; I'd say as an mere EE, that sensor
>intercepts should/can be viewed as very minor irritations easily
>accomplished. What we need to determine next is how much authority can
>be accomplished via PE-mode programming/disabling, and whether a combo
>of your two suggestions could possibly accomplish the whole end game. If
>so, methinks it's possibly fairly major doo-doo. :)  Anyone else have
>further suggestions/comments/caveats? Speak up, pulleze.
>
>Gar
>
>
>----------------------------------------------------------------------------
>To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the 
>quotes)
>in the body of a message (not the subject) to majordomo at lists.diy-efi.org
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

----------------------------------------------------------------------------
To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes)
in the body of a message (not the subject) to majordomo at lists.diy-efi.org