From owner-diy_efi Thu Nov 10 03:48:14 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA24682; Thu, 10 Nov 94 03:48:14 GMT Received: from eigen.ee.ualberta.ca by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA24677; Wed, 9 Nov 94 22:48:10 -0500 Message-Id: <9411100348.AA24677@coulomb.eng.ohio-state.edu> Received: by eigen.ee.ualberta.ca (1.37.109.4/15.6) id AA20206; Wed, 9 Nov 94 20:48:07 -0700 From: Dale Ulan Subject: Re: EFI mapping ideas. To: DIY_EFI Date: Wed, 9 Nov 94 20:48:05 MST In-Reply-To: <199411100114.AA16364@shiva.trl.OZ.AU>; from "Craig Pugsley" at Nov 10, 94 12:14 (noon) Mailer: Elm [revision: 70.85] Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI > So, you are interpolating between 2 points on the RPM axis and 2 points > on the Load axis, making an overall interpolation between 4 points? > If it works properly it should be quite nice. In fact, that's exactly how it's done in OEM computers. >> Yup. I'm only guessing that a 17 x 17 map will be enough. What did you base >> your decision on using 32 load numbers on? Do you know something I don't? > > >From what I can determine, the load is much more important than the RPM. > (I did some measurements of an aftermarket computer, and the pulse time > the injector was on for did not vary with RPM (Well, when under engine > vacuum. When under boost it did) Depends a lot on the engine. The volumetric efficiency of the engine can vary from a 10% difference between the VE peak and a lower value (like at 1500 rpm or a fast idle) to a 60% difference or more... depending on the engine. Typically, in OEM computers, the RPM is quite important, as they are trying to fuel within a couple of percent (or even closer) as to what the engine needs. If I sound like I'm praising the OEM ECM's, it's because they have a lot more research invested into their algorithms than any of us... or pretty much any aftermarket company... can afford to put into the box. .... > If you're using interpolation 32 wouldn't matter, you might even get > away with something as low as 4 or 8. I'd say 17x17 w/interpolation > should be more than adaquate. 17x17 is good for most engine applications. It can even meet emissions to 1994 levels, so it'll do for most of our applications. The LT-5 engine is the only ECM I've seen with larger tables. These are about 30x17. I don't remember which value had the 30 or so values, but I have a hunch it's RPM. -Dale >>>I'm un-decided if an 8 bit injection time will have enough 'dynamic >>>range' from idle to full throttle, though it's probably easier to >deal with > > an 8 bit number. An 8-bit number is fine for a typical table, however, these values are multiplied and rounded, etc. so you want to keep as many bits as possible. Normally you have a Base Pulse Width, a Power Enrichment, and an Air Density Correction. Since these are multiplied out, I'd suggest the following: BASE_PW * AIR_DENS result: 16 bits * (POWER ENRICHMENT FACTOR + COLD START FACTOR) result: 24 bits. now round down to 16 bits * ADDITIONAL FACTOR result: 24 bits. round down to 16 bits. done. 16 bits is convenient as well, since it allows a lot of exta headroom to add acceleration enrichment and other additive factors. -Dale From owner-diy_efi Thu Nov 10 04:42:01 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA25062; Thu, 10 Nov 94 04:42:01 GMT Received: from shiva.trl.OZ.AU by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA25056; Wed, 9 Nov 94 23:41:49 -0500 Received: by shiva.trl.OZ.AU id AA26434 (5.65c/IDA-1.4.4 for DIY_EFI@coulomb.eng.ohio-state.edu); Thu, 10 Nov 1994 15:41:27 +1100 From: Craig Pugsley Message-Id: <199411100441.AA26434@shiva.trl.OZ.AU> Subject: Re: EFI mapping ideas. To: DIY_EFI Date: Thu, 10 Nov 1994 15:41:24 +1100 (EST) In-Reply-To: <9411100348.AA24677@coulomb.eng.ohio-state.edu> from "Dale Ulan" at Nov 9, 94 08:48:05 pm X-Mailer: ELM [version 2.4 PL20] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3161 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI > > >From what I can determine, the load is much more important than the RPM. > > (I did some measurements of an aftermarket computer, and the pulse time > > the injector was on for did not vary with RPM (Well, when under engine > > vacuum. When under boost it did) > > Depends a lot on the engine. The volumetric efficiency of the engine > can vary from a 10% difference between the VE peak and a lower value > (like at 1500 rpm or a fast idle) to a 60% difference or more... depending > on the engine. Typically, in OEM computers, the RPM is quite important, as > they are trying to fuel within a couple of percent (or even closer) as to > what the engine needs. As I said, the assumption that load was more important than RPM was based on: i/ measurements of a computer (a/market) ii/Haltech using 32 loadx16 rpm However, MoTeC uses: 11 load x 20 rpm on their entry level computer 21 load x 40 rpm on their advanced level computer Perhaps this means that RPM and LOAD are of similar importance. The odd number for load suggests that maybe only the load is interpolated in a MoTeC computer. (Hey, I'm speculating) Am I correct in assuming that this load setting is just the engine vacuum? (IE using a MAP sensor). Is this relative to the ambient pressure or to absolute zero (IE a single ported sensor)? > If I sound like I'm praising the OEM ECM's, it's because they have a lot > more research invested into their algorithms than any of us... or > pretty much any aftermarket company... can afford to put into the > box. No question. Now if only they had a nice ECU that would let me program it with my PC :-). Even detailed algorithms would be nice. > > If you're using interpolation 32 wouldn't matter, you might even get > > away with something as low as 4 or 8. I'd say 17x17 w/interpolation > > should be more than adaquate. > > 17x17 is good for most engine applications. It can even meet emissions > to 1994 levels, so it'll do for most of our applications. Really? I'm impressed/surprised that it is that straight forward. > >>>I'm un-decided if an 8 bit injection time will have enough 'dynamic > >>>range' from idle to full throttle, though it's probably easier to >deal with > > > an 8 bit number. > > An 8-bit number is fine for a typical table, however, these values are > multiplied and rounded, etc. so you want to keep as many bits as possible. > Normally you have a Base Pulse Width, a Power Enrichment, and an Air > Density Correction. Since these are multiplied out, I'd suggest the > following: > > BASE_PW * AIR_DENS > result: 16 bits Does BASE_PW come from the Load vs RPM table? Where does AIR_DENS come from? Would just an air temp sensor be OK? > * (POWER ENRICHMENT FACTOR + COLD START FACTOR) > result: 24 bits. I presume the power enrichment is an 'accelerator pump', and the cold start is determined from the coolant temp sensor. > * ADDITIONAL FACTOR > result: 24 bits. > round down to 16 bits. > What's this part? Basically what I would like to see is a (simplified) algorithm that shows where all of the parts come from (IE what sensors and if you add/multiply by the number). Craig. pugsley@trl.oz.au From owner-diy_efi Thu Nov 10 06:08:43 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA25318; Thu, 10 Nov 94 06:08:43 GMT Received: from sunrise.Stanford.EDU by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA25313; Thu, 10 Nov 94 01:08:37 -0500 Received: (from carryer@localhost) by sunrise.Stanford.EDU (8.6.8/8.6.6) id WAA03171; Wed, 9 Nov 1994 22:08:33 -0800 Date: Wed, 9 Nov 1994 22:08:33 -0800 From: Ed Carryer Message-Id: <199411100608.WAA03171@sunrise.Stanford.EDU> To: DIY_EFI Cc: DIY_EFI In-Reply-To: (message from James C Patterson on Wed, 9 Nov 1994 17:14:29 -0800 (PST)) Subject: Re: Carb adjustment using exhaust temp... Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI James, I did an engine controller for a 2-stroke drone aircraft engine, about 10 years ago now. (wow I'm getting old ;) it used exhaust gas temperature (EGT) feedback. the idea is to lean out the mixture and look for an inflection in the temperature vs mixture curve. This occurs roughly when you move through the stoichiometric mixture. Having said that though, I don't think you could do it in a car. An aircraft (the drone) runs at a constant power setting for most of the time, so changes in EGT can pretty well be tied to the changes you are making in AFR. In a car, the load is never relly constant, at least not for very long, and EGT is even more strongly influenced by load than it is by AFR at a given load. I should also note that manual EGT feedback (i.e. through the driver) is de rigeur for 2-stroke racing carts, but again, they spend a lot more time at a constant power setting (WOT) that you can expect to achieve on the road. after all this diatribe, I just re-read your message, and can answer your question much more simply: You can't look for an absolute temp, just the delta-T between cylinders to infer mixture balance. good luck, ed -- From owner-diy_efi Thu Nov 10 09:20:34 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA25560; Thu, 10 Nov 94 09:20:34 GMT Received: from coyote.rain.org by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA25555; Thu, 10 Nov 94 04:20:30 -0500 Received: from diginst.UUCP by coyote.rain.org(4.1/SMI-RAIN) with id AA13176 UUCP for DIY_EFI@coulomb.eng.ohio-state.edu on Thu, 10 Nov 94 01:16:58 PST Received: by di.com (UUPC/extended 1.11z); Thu, 10 Nov 1994 00:34:57 PST Date: Thu, 10 Nov 1994 00:34:56 PST From: "Todd Day" Message-Id: <2ec1db31.diginst@di.com> Organization: Digital Instruments, Santa Barbara, CA To: "DIY EFI"DIY_EFI Subject: OEM algorithms (DSM) Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI I'm dumping the ROM of the DSM triplets (Talon/Eclipse/Laser). I found a couple of interesting things and I thought I'd put 'em out there for some comment. 1) The ECU goes through all these fancy calculations for figuring out how much fuel it should be pumping out based on the MAF, barometer, and air temp. It then takes into account the oxygen sensor for final trim. At the very end, it intentionally enriches the mixture by 1.5%. I think it does this so that it can stay a bit rich on the A/F ratio for emmisions. That sound right? 2) In another part of the code, the ECU is trying to decide whether or not to even run oxy feedback at all. It takes a look at the amount of air and compares it against two tables that are indexed by RPM. It ends up with three bands of air flow vs. RPM (split by the two tables). In the low air band, it will run oxy feedback. In the mid air band, it will run oxy feedback for 20 secs before going open loop. In the high air band, it won't run oxy feedback at all. Now, I can under- stand what the ECU is trying to accomplish at low and high air amounts. But I can't see what it is trying to avoid in the mid air band. I was thinking it might be due to oxy sensor overheating or something, but my friend tells me they actually enjoy operating at high exhaust temps. 3) To add to both 1&2, the ECU will not do the 1.5% fattening in the mid or high bands. Any idea why? Thanks for your comments. -todd- P.S. After wading through 12k of OEM code for a few months (and this was code written in the late 80's on an 8bit micro), I just don't see how a handful of people in their spare time could even come close to the complex cases handled by a manufacturer with years of experience. I've also dumped an ECU (4k ROM) from the early 80's that was much much simpler, and I don't even think I'd ever think of every case covered by that simpler ECU. -- Todd Day todd@di.com From owner-diy_efi Thu Nov 10 15:30:47 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA26663; Thu, 10 Nov 94 15:30:47 GMT Received: from wotan.compaq.com by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA26658; Thu, 10 Nov 94 10:30:44 -0500 Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp (Smail3.1.28.1 #12) id m0r5azU-000vNwC; Thu, 10 Nov 94 09:00 CST Received: from bangate.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #10) id m0r5auy-000uGoC; Thu, 10 Nov 94 08:56 CST Message-Id: Received: by bangate.compaq.com with VINES ; Thu, 10 Nov 94 08:56:03 CST Date: Thu, 10 Nov 94 08:54:22 CST From: Steve=Ravet%Prj=Eng%PCPD=Hou@bangate.compaq.com Subject: re: OEM algorithms (DSM) To: diy_efi Cc: Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI "Todd Day" Wrote: | P.S. After wading through 12k of OEM code for a few months (and this was | code written in the late 80's on an 8bit micro), I just don't | see how a handful of people in their spare time could even | come close to the complex cases handled by a manufacturer | with years of experience. I've also dumped an ECU (4k ROM) from | the early 80's that was much much simpler, and I don't even think | I'd ever think of every case covered by that simpler ECU. | -- | Todd Day | todd@di.com Ok, so what were these special cases so we can think about them for our engines? --steve From owner-diy_efi Thu Nov 10 15:38:12 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA26683; Thu, 10 Nov 94 15:38:12 GMT Received: from eigen.ee.ualberta.ca by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA26678; Thu, 10 Nov 94 10:38:08 -0500 Message-Id: <9411101538.AA26678@coulomb.eng.ohio-state.edu> Received: by eigen.ee.ualberta.ca (1.37.109.4/15.6) id AA02594; Thu, 10 Nov 94 08:38:05 -0700 From: Dale Ulan Subject: Re: EFI mapping ideas. To: DIY_EFI Date: Thu, 10 Nov 94 8:38:02 MST In-Reply-To: <199411100441.AA26434@shiva.trl.OZ.AU>; from "Craig Pugsley" at Nov 10, 94 3:41 pm Mailer: Elm [revision: 70.85] Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI > Perhaps this means that RPM and LOAD are of similar importance. The odd > number for load suggests that maybe only the load is interpolated in a > MoTeC computer. (Hey, I'm speculating) Wierd. They should both be interpolated. It isn't that hard... > > Am I correct in assuming that this load setting is just the engine > vacuum? (IE using a MAP sensor). Is this relative to the ambient > pressure or to absolute zero (IE a single ported sensor)? Generally, absolute pressure is used, with a small correction factor for the change in exhaust backpressure when the barometric pressure changes. > Really? I'm impressed/surprised that it is that straight forward. There are a lot of other 'tweaks' that are added to make it work... > > BASE_PW * AIR_DENS > > result: 16 bits > > Does BASE_PW come from the Load vs RPM table? yes. > Where does AIR_DENS come from? Would just an air temp sensor be OK? yes. Dig out the ideal gas law... PV=nRT. It's a 1/x relationship, where x is in degrees Kelvin. > > * (POWER ENRICHMENT FACTOR + COLD START FACTOR) > > result: 24 bits. > > I presume the power enrichment is an 'accelerator pump', and the cold > start is determined from the coolant temp sensor. Cold Start is in part determined from coolant temperature, but also the change in coolant temperature since starting, time since start, and manifold vacuum: Coolant Temperature determines a 'COLD START' mixture, eg. 3.5:1 at -10 C. delta coolant will indicate that the temperature has gone up by, say, 5 C since starting, so add (for example) 1.0:1 engine vacuum is at 30 kPa, so add 1.5:1 The engine has been running for 20 seconds, so add 0.4:1 final ratio = 6.4:1 Typically, the 'timer' is an exponential lag filter. The power enrichment is like the metering rods in real carburetors (or the power valve in a Holley). In high load conditions, the EFI computer will add enrichment, and typically run the mixture at 13.0:1 or so. > > * ADDITIONAL FACTOR > > result: 24 bits. > > round down to 16 bits. > > > What's this part? Anything that I've missed in ony describing a small fraction of the tables. Things like correction factors based on fuel return line backpressure, fuel pump voltage drop, canister purge vapor compensation, EGR feed compensation, and a great deal of other things. The accelerator pump is an additive pulse width, after the steady-state fuelling has been calculated to open the injector 'X' us. This is typically calculated by using a filtered delta-MAP contribution table and temperature compensation table. This compensates for manifold dropout effects of TBI systems, where fuel will condense on the manifold walls when quick changes of MAP occur. In addition, to compensate for manifold filling effects and fuel evaporative rates, an additional AE is added, with its own dTPS table, a temperature-dependant decay rate, and another temperature dependant factor. AE = DMAP_CONTRIB[dmap/dt] * TFDMAP[man_temp] + TPS_CONTRIB[dtps/dt] * TFDTPS[man_temp] * TPS_ADJ[tps] * RPM_ADJ[rpm] BFP= BASE_PULSE[rpm,map] * ADFACT[air_temp] * (POWFACT[rpm] + POWFACT[map]) {* or +} (COLDENGFACT[ect] - TIMEOUT[engrunning]) PULSE_WIDTH = INJOPEN[battery] + AE + BFP These are *very* simplified... -Dale From owner-diy_efi Thu Nov 10 15:51:39 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA26764; Thu, 10 Nov 94 15:51:39 GMT Received: from pine.cse.nau.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA26759; Thu, 10 Nov 94 10:51:33 -0500 Received: (from met@localhost) by pine.cse.nau.edu (8.6.9/2.2-nau) id IAA22803 for DIY_EFI@coulomb.eng.ohio-state.edu; Thu, 10 Nov 1994 08:51:31 -0700 Message-Id: <199411101551.IAA22803@pine.cse.nau.edu> From: met@pine.cse.nau.edu (MTN-KAT) Date: Thu, 10 Nov 1994 08:51:30 -0700 In-Reply-To: Craig Pugsley "Re: FW: 67F687" (Nov 9, 2:48pm) X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: DIY_EFI Subject: Re: FW: 67F687 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Well Craig if you want to get in on a group purchase, I'll send you the chips without going through your customs and therefore without markup. Should be less than $25.00 for sure. Millam From owner-diy_efi Thu Nov 10 16:38:08 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA27222; Thu, 10 Nov 94 16:38:08 GMT Received: from tomcat.al.noaa.gov by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo-1.92/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI diy_efi-outgoing id AA27217; Thu, 10 Nov 94 11:38:04 -0500 Received: from aztec.al.noaa.gov by tomcat.al.noaa.gov with SMTP id AA01362 (5.65c/IDA-1.4.4 for ); Thu, 10 Nov 1994 09:44:56 -0700 Message-Id: <199411101644.AA01362@tomcat.al.noaa.gov> Date: 10 Nov 1994 09:32:39 -0700 From: "Ciciora Steve" Subject: 67F687 development system & silicon systems To: DIY_EFI Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Just finished talking w/ Tony Anderson at (714)731-7110. He dosn't mind being a contact person if anyone is interested in using the above chip. I was hoping he wouldn't mind if I gave out copies of the schamatic of the development system, and even the software. No luck. He said he didn't mind if I 'showed' the stuff to other people, but he did mind if I copied it in any way. It's not that hard to interface on the hardware end, so if anyone has any questions, I'm sure I could answer them. I have not looked at the software in detail, so I can't comment on that. Shouldn't be too much harder than writing a device driver for a video chip or something. Tony also has the data sheets digitized in some standard World Wide Webb format that can be freely distributed. Will some WWW expert help me figure out how to put it on the server? Thanks! -Steven Ciciora