From owner-diy_efi Thu Nov 10 16:45:30 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA27258; Thu, 10 Nov 94 16:45:30 GMT Received: from us.dynix.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 AA27253; Thu, 10 Nov 94 11:45:25 -0500 Received: from cpu.us.dynix.com by dnxjcit.us.dynix.com with SMTP id AA18446 (5.65c/IDA-1.4.4 for ); Thu, 10 Nov 1994 09:51:54 -0700 Received: by cpu.us.dynix.com (AIX 3.2/UCB 5.64/4.03) id AA99533; Thu, 10 Nov 1994 09:44:33 -0700 Date: Thu, 10 Nov 1994 09:26:22 -700 (MST) From: Jim Conforti Subject: re: OEM algorithms (DSM) To: DIY_EFI In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI On Thu, 10 Nov 1994, it was written: > Ok, so what were these special cases so we can think about them for our > engines? Ok .. let me try to get a few 0.01 in here ;) First let me define my "speak" ... RPM is well .. rpm LOAD, however ... think MAP for the speed-density guys, and think MAF/RPM (airflow per rev or stroke) for the measured air guys .. Here's just a few of the "special" tweeks in the Bosch stuff .. Spark .. retard on accel, adv. on decel main spark f(rpm, load) adapted by f(engt) and f(airt) [charge temp. for the turbo guys] Fuel .. = LOAD * Kbpw * VE(rpm, load) adapted by Decel Fuel cutoff Post Start Enrichment f(engt)*f(speed,load) Warmup enrichement f(engt)*F(speed,load) Accel enrich f(rpm)*f(engt) The TRICK come in how you handle the nultitude of binary possibilities that arise from the diff. conditions of engt, accel, decel, load, rpm and airt that affect both driveability and emissions ... Jim From owner-diy_efi Thu Nov 10 17:32:42 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA27428; Thu, 10 Nov 94 17:32:42 GMT Received: from JULIET.WX.LL.MIT.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 AA27423; Thu, 10 Nov 94 12:32:39 -0500 Received: from fuelrod ([129.55.57.2]) by juliet.ll.mit.edu id AA07736g; Thu, 10 Nov 94 12:29:26 EST Received: from isotope.reactor by fuelrod (4.1/SMI-4.1) id AA03001; Thu, 10 Nov 94 10:32:03 MST Date: Thu, 10 Nov 94 10:32:03 MST From: jvp%fuelrod@juliet.ll.mit.edu ( Jim Pieronek) Message-Id: <9411101732.AA03001@fuelrod> Received: by isotope.reactor (4.1/SMI-4.1) id AA07161; Thu, 10 Nov 94 10:34:28 MST To: DIY_EFI In-Reply-To: <2ec1db31.diginst@di.com> Subject: OEM algorithms (DSM) Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI "Todd Day" writes: [snip a bunch of interesting algorithm stuff] > > 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. > -- > When I was at GM in the mid-80's we had two guys working on the ECM code for the Quad 4 engine. The methods that we used were identical to what I've heard people describe in this group: instrument your system; repeat { drive it around for a while; take a stab at a better way; } until (out-of-time) The nice thing about do-it-yourselfers is that out-of-time is never true! We had pretty crummy instrumentation, the most interesting of which was a box mounted on top of the dash that could show four user-selectable engine parameters. There was no recording capability. Those boxes were the cause of many rear-end collisions! It was relatively easy to get an engine up and running. It took a little more effort to get good performance. But what took up most of our time was getting the thing to have both good performance and to be able to pass the EPA dyno emissions test. In that test, a dyno is programmed to simulate some EPA employee's drive to work in California. I think it was 17 miles of highway and mountainous roads. The other thing that we spent a great deal of time on was starting. We had to be able to do a no-pedal start from -40F to 120F. This was quite tricky. So I imagine that a lot of what you are seeing in that code are tweeks to make it pass the dyno emissions test. In a diy job, all you need to do is pass the simple idle emissions test. The other thing that you need to do is keep your mix right so you don't roast your converter, if you use one. I think it's well within reason to expect diy'ers to be able to do a pretty good job on a controller. - Jim =================================================================== J. V. Pieronek Phone: (505) 243-5822 M.I.T. Lincoln Laboratory FAX: (505) 243-5823 Terminal Radar Development Facility Internet: jvp@ll.mit.edu Albuquerque, New Mexico From owner-diy_efi Thu Nov 10 17:38:31 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA27446; Thu, 10 Nov 94 17:38:31 GMT Received: from us.dynix.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 AA27441; Thu, 10 Nov 94 12:38:25 -0500 Received: from cpu.us.dynix.com by dnxjcit.us.dynix.com with SMTP id AA18771 (5.65c/IDA-1.4.4 for ); Thu, 10 Nov 1994 10:44:56 -0700 Received: by cpu.us.dynix.com (AIX 3.2/UCB 5.64/4.03) id AA109002; Thu, 10 Nov 1994 10:37:35 -0700 Date: Thu, 10 Nov 1994 10:37:14 -700 (MST) From: Jim Conforti Subject: Re: OEM algorithms (DSM) To: DIY_EFI Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI On Thu, 10 Nov 1994, Todd Day wrote: Todd, this is Jim C. ... from BMW/Bosch land .. long time no talk .. Saw your talon stuff, here's what I can figure out > 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. I has to do with the FTP (Federal Test Procedure) for EPA emissions testing and the CARB tests ... While in the tests, the car is mostly operating in region #1 .. under certain parts of the test, probably during accel, we make brief forays into region #2 ... hence, if we're there for less than 20 sec and return to #1, the EGO control is never disturbed and we meet the emissions spec ... Region #2 is probably not run in very much under constant throttle but if it is, you lose EGO contol and go towards max power ... Of course, Region #3 is the "full bore" non-emissions region .. BMW/Bosch handle it slightly differently ... As an example ... (E30 M3) .. There is a region of speed/load that EGO is active .. if you are under the magic load number and 4800 rpms, the EGO is active .. If you venture out of the "emissions" region, for longer than 3 sec. the EGO goes inactive .. the 3 sec delay is for brief forays into the "non-emissions" region during the official tests ... Jim Conforti From owner-diy_efi Thu Nov 10 18:03:03 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA27524; Thu, 10 Nov 94 18:03:03 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 AA27511; Thu, 10 Nov 94 13:02:58 -0500 Received: (from carryer@localhost) by sunrise.Stanford.EDU (8.6.8/8.6.6) id KAA04200; Thu, 10 Nov 1994 10:02:53 -0800 Date: Thu, 10 Nov 1994 10:02:53 -0800 From: Ed Carryer Message-Id: <199411101802.KAA04200@sunrise.Stanford.EDU> To: DIY_EFI Cc: DIY_EFI@sunrise.Stanford.EDU In-Reply-To: <2ec1db31.diginst@di.com> (todd@di.com) Subject: Re: OEM algorithms (DSM) Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI 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. I can't say for certain why, but it is probably emissions related. The range of speed load combinations encountered on an emission cycle is fairly well known. (easily determined for a given vehicle/inertia class) It involves a lot of relativly light loads with a few excursions (the 'hills' you may hear referred to). These excursions are short, so if you know that the load is high enough so as to only be occuring during one of the hills, you also now you won't be there for very long. If you find yourself there for too long, you know you are not running an emission test, and can choose to optimize a bit for drivability rather than just emissions. Hence three ranges: 1 surely to be encountered for long periods 2 only to be encountered for short periods 3 should never be encountered on an emissions test 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. It's really not all that hard to get something that will run an engine better than a carb. which, after all, is the alternative. You can get probably 70-80% of the way to an oem controller with just the info that I've seen posted here in the past week or two (I'm fairly new to the list) The remainder are probably things you are not incredibly interested in: optimum emissions cold start from -40 reduced shift harshness real-time diagnostics egr control... the list goes on and on. so don't be discouraged by the complexity in a production controller, you don't need most of it. Unless you are dieing to know how *their* controller works, you would be better off studying the info posted here and working on your own implementation, or adding some data aquisition circuitry to your car and watching *what* they do, rather than trying to figure out *how & why*, since without inside info we'll never know why. (the exception to this is fishing for neat programming hacks ;) ed -- From owner-diy_efi Thu Nov 10 20:02:47 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA28049; Thu, 10 Nov 94 20:02:47 GMT Received: by coulomb.eng.ohio-state.edu (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 AA28044; Thu, 10 Nov 94 15:02:44 -0500 Date: Thu, 10 Nov 94 15:02:44 -0500 From: jsg (John S Gwynne) Message-Id: <9411102002.AA28044@coulomb.eng.ohio-state.edu> Apparently-To: DIY_EFI Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI (Message jsg:354) Date: Thu, 10 Nov 94 16:44:56 GMT To: owner-diy_efi From: owner-diy_efi Subject: BOUNCE diy_efi@coulomb.eng.ohio-state.edu: Admin request >From cmcalstr@hpcvts.cv.hp.com Thu Nov 10 11:44:53 1994 Received: from hp-cv.cv.hp.com by coulomb.eng.ohio-state.edu via SMTP (920330.S GI/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_E FI diy_efi-outgoing id AA27235; Thu, 10 Nov 94 11:44:53 -0500 Received: from hp-pcd.cv.hp.com by hp-cv.cv.hp.com with SMTP (1.36.108.7/15.5+IOS 3.22+CV 1.0ext) id AA20515; Thu, 10 Nov 1994 08:44 :51 -0800 Received: from hpcvts.cv.hp.com by hp-pcd.cv.hp.com with SMTP (1.37.109.8/15.5+IOS 3.22+OM+CV 1.0) id AA13862; Thu, 10 Nov 1994 08:44 :51 -0800 Received: by hpcvts.cv.hp.com (15.11/15.5+IOS 3.22[SMTP-rly]+CV 1.0leaf) id AA16949; Thu, 10 Nov 94 0 8:47:00 pst From: Cary McCallister Message-Id: <9411101647.AA16949@hpcvts.cv.hp.com> Subject: Re: 67F687 development system & silicon systems To: DIY_EFI Date: Thu, 10 Nov 94 8:46:59 PST In-Reply-To: <199411101644.AA01362@tomcat.al.noaa.gov>; from "Ciciora Steve" at Nov 10, 94 9:32 am Mailer: Elm [revision: 64.9] > 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 ou t >how to put it on the server? Do you have the URL ? Cary McCallister From owner-diy_efi Thu Nov 10 23:13:57 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA00064; Thu, 10 Nov 94 23:13:57 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 AA00059; Thu, 10 Nov 94 18:13:55 -0500 Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp (Smail3.1.28.1 #12) id m0r5idH-000vK6C; Thu, 10 Nov 94 17:10 CST Received: from bangate.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #10) id m0r5iat-000uGoC; Thu, 10 Nov 94 17:07 CST Message-Id: Received: by bangate.compaq.com with VINES ; Thu, 10 Nov 94 17:07:49 CST Date: Thu, 10 Nov 94 17:01:14 CST From: Steve=Ravet%Prj=Eng%PCPD=Hou@bangate.compaq.com Subject: ALDL pinout and data stream on corvette? To: diy_efi, hotrod@dsea.com Cc: Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Howdy I'd like some information on the ALDL connector for the Corvette. The ALDL is the diagnostic connector on computer controlled GM cars that provides diagnostic information to a computer. Info such as rpm, injector duty cycle, EGO, timing, etc. I know it's possible to hook a PC up to this and collect info, because there is a company that sells just such a product (in addition to GM, of course). I'd like to write my own software to run on a laptop to do this. What I don't know is the pin out of this connector, and the format of the data stream. If anyone can tell me this, or point me in the right direction, I'd be most appreciative. thanks --steve From owner-diy_efi Fri Nov 11 00:20:36 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA00280; Fri, 11 Nov 94 00:20:36 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 AA00274; Thu, 10 Nov 94 19:20:31 -0500 Received: from diginst.UUCP by coyote.rain.org(4.1/SMI-RAIN) with id AA18959 UUCP for DIY_EFI@coulomb.eng.ohio-state.edu on Thu, 10 Nov 94 16:16:57 PST Received: by di.com (UUPC/extended 1.11z); Thu, 10 Nov 1994 15:25:02 PST Date: Thu, 10 Nov 1994 15:25:01 PST From: "Todd Day" Message-Id: <2ec2abce.diginst@di.com> Organization: Digital Instruments, Santa Barbara, CA To: "DIY EFI"DIY_EFI Subject: OEM algorithms (source) Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI I got a couple of person email questions asking me about all these special cases the OEM ECU takes care of. Instead of talking about all of them and possibly screwing something up in translation, I have a suggestion for you guys who are interested in how the ECU works in the DSM triplets (Talon, Eclipse, Laser). There is this awesome Technical Information Manual you can get for the DSMs that pretty much describes most of the modes that the ECU covers. It also talks about the rest of the car, if you are interested in the AWD system, etc. Anyway, it is really the bargain of the century at only $2. Not a misprint. That's TWO DOLLARS! Call 1-800-626-1523 and ask for the 1990 Laser/Talon Tech Info Manual part number 81-699-9039. Shipping will probably be more than the cost of this ~200 page book. They take plastic. Please note that there are no code segments or any such great detail in this book... but they do talk about all the sensors and how they are used. Even has a blurb about sequential/synchronous injection (it's a pretty bitchin' ECU). -todd- -- Todd Day todd@di.com From owner-diy_efi Fri Nov 11 02:05:18 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA01112; Fri, 11 Nov 94 02:05:18 GMT Received: from knuth.mtsu.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 AA01107; Thu, 10 Nov 94 21:05:13 -0500 Received: by knuth.mtsu.edu (Smail3.1.28.1 #21) id m0r5lLQ-000CuzC; Thu, 10 Nov 94 20:04 CST Message-Id: From: lusky@knuth.mtsu.edu (Jonathan R. Lusky) Subject: Re: OEM algorithms (DSM) To: DIY_EFI Date: Thu, 10 Nov 1994 20:04:04 -0600 (CST) In-Reply-To: <9411101732.AA03001@fuelrod> from "Jim Pieronek" at Nov 10, 94 10:32:03 am X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2599 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Jim Pieronek writes: > When I was at GM in the mid-80's we had two guys working on the ECM > code for the Quad 4 engine. The methods that we used were identical > to what I've heard people describe in this group: > > instrument your system; > repeat { > drive it around for a while; > take a stab at a better way; > } until (out-of-time) Been there, done that. Although our algorithm was slightly different, we got it driving OK, tune the ranges we'd see on the FTP on a road-load chassis dyno, then fine tuned the rest on the road and didn't touch the ranges we had tuned for the FTP (we werent very concerned with driveability, we were VERY concerned with emissions). > The nice thing about do-it-yourselfers is that out-of-time is never > true! We had pretty crummy instrumentation, the most interesting of > which was a box mounted on top of the dash that could show four > user-selectable engine parameters. There was no recording capability. > Those boxes were the cause of many rear-end collisions! How did yall tune EFI before UEGO's??? I know the box you are talking about, we had one too. Never did figure out what the thumbwheels did or how to make the prom burner work, and GM wouldn't give us any docs. > It was relatively easy to get an engine up and running. It took a > little more effort to get good performance. But what took up most of > our time was getting the thing to have both good performance and to be > able to pass the EPA dyno emissions test. In that test, a dyno is > programmed to simulate some EPA employee's drive to work in > California. I think it was 17 miles of highway and mountainous roads. City driving too... spent a lot of time idling on the FTP. Also cold start and hot starts. > So I imagine that a lot of what you are seeing in that code are tweeks > to make it pass the dyno emissions test. In a diy job, all you need > to do is pass the simple idle emissions test. The other thing that > you need to do is keep your mix right so you don't roast your > converter, if you use one. I think it's well within reason to expect > diy'ers to be able to do a pretty good job on a controller. I agree... most existing aftermarket boxes are very simple compared to OEM controller--too simple IMHO, which is why this project has such great potential :) -- Jonathan R. Lusky lusky@knuth.mtsu.edu http://frank.mtsu.edu:8001/~lusky/ (615) 726-8700 ------------------------------------- ------------------------------ 68 Camaro Convertible - 350 / TH350 \_/ 80 Toyota Celica - 20R / 5spd