DIY_EFI Digest Friday, April 7 2000 Volume 05 : Number 139 In this issue: Re: C/L WB/WOT OEM ECUs... See the end of the digest for information on subscribing to the DIY_EFI or DIY_EFI-Digest mailing lists. ---------------------------------------------------------------------- Date: Fri, 07 Apr 2000 02:47:34 PDT From: "mike mager" Subject: Re: C/L WB/WOT OEM ECUs... 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@xxx.com (Garfield Willis) >Reply-To: diy_efi@xxx.org >To: diy_efi@xxx.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" 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@xxx.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@xxx.org ------------------------------ End of DIY_EFI Digest V5 #139 ***************************** To subscribe to DIY_EFI-Digest, send the command: subscribe diy_efi-digest in the body of a message to "Majordomo@xxx. A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace "diy_efi-digest" in the command above with "diy_efi".