@xxx.edu Fri Jan 6 12:25:51 1995 Date: Fri, 6 Jan 95 09:18:05 GMT @xxx.edu @xxx.za Subject: Majordomo file: list 'diy_efi' file 'archive_num_3' -- >From Diy_Efi-Owner Thu May 5 20:12:36 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA05271; Thu, 5 May 94 20:12:36 GMT Received: from localhost.eng.ohio-state.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) @xxx.edu diy_efi-outgoing id AA05265; Thu, 5 May 94 16:12:35 -0400 @xxx.edu> To: DIY_EFI Cc: jsg Subject: Re: Intro In-Reply-To: Your message of "Thu, 05 May 94 13:57:05 EDT." @xxx.GOV> Date: Thu, 05 May 94 16:12:34 -0400 From: John S Gwynne Sender: Diy_Efi-Owner Precedence: bulk @xxx.edu -------- @xxx.GOV> , you write: | A while ago I worked with a company called CUbit - they made, among other | things, an 80186 based, STD Bus board. What I particularly enjoyed about | their set-up is that the on board ROMs would communicate with Borland's C | Remote debugger. That means you write the code on a PC (all Borland), | compile and link it, and then down load it to the board - and you can step | through the code running on the remote CPU. A breeze to debug. Then you | link the code with a provided library and you can burn that code directly Yea, this can also be done with GNU's gcc and the GNU debugger gdb; a remote serial interfaced debugger. That's why I've chosen to work with the 68000 and a C cross-compiler. It would be nice if we all used the same CPU but I don't think it's going to happen. A more reasonable goal would be to stick with an ANSI-C language (available for PC's, 68HC11's, and about everything else)(avoiding calls to the standard library functions) and have a common interface bus that would let us share sensory interface designs. This way you could use the 80186, I could use a 68HC000, and ???? could use his 68HC11. We could all still share the software (with vary minor changes) and sensor interface designs. John S Gwynne @xxx.edu _______________________________________________________________________________ T h e O h i o - S t a t e U n i v e r s i t y ElectroScience Laboratory, 1320 Kinnear Road, Columbus, Ohio 43212, USA Telephone: (614) 292-7981 * Fax: (614) 292-7292 ------------------------------------------------------------------------------- >From Diy_Efi-Owner Thu May 5 20:22:46 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA05400; Thu, 5 May 94 20:22:46 GMT Received: from cs.utexas.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) @xxx.edu diy_efi-outgoing id AA05394; Thu, 5 May 94 16:22:44 -0400 @xxx.edu>; Thu, 5 May 1994 15:21:58 -0500 Received: by needmore.cs.utexas.edu (5.64/Client-v1.4) id AA12998; Thu, 5 May 94 15:21:40 -0500 Date: Thu, 5 May 1994 15:21:37 -0500 (CDT) @xxx.edu> Subject: Re: jai To: DIY_EFI @xxx.com> @xxx.edu> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Diy_Efi-Owner Precedence: bulk @xxx.edu @xxx.com wrote: > I would like to make a suggestion: I think the topic of electronically > controlled ignitions fits in well with efi, and would like to see that topic > covered here as well (mostly because that's the first thing I would like to > add to my car). Please no flames, but perhaps a yea or nay response to see > what the general consensus is. Sounds fine to me. @xxx.com writes: > >[The EFI system is pretty simple. A dallas semi DS5000 hybrid supplies > >all the smarts. This is a pretty amazing part. It contains an > >8052-like processor, ram, "rom" (battery-backed ram), timers, watchdog > >timer and some other goodies in a double height 40 pin dip. It has > >3 8 bit I/O ports and a serial port. Best of all, you program it > >records into the serial port. when the END record is received, > >the chip reboots and starts running the program as if it were in > >ROM. > > The main advantage I see here is that no eprom programmer is required. In > fact, if you have a laptop of some sort, you can compile/reprogram without > ever leaving the car. The built-in I/O ports are nice too. And there are > plenty of 8052 compilers/assemblers out there. That sounds good-- the part about no eprom programmer. Many of us don't have access to all kind of fancy electrical stuff, and the cheaper we can keep the whole thing the better. I like the idea of being able to change the program on the fly without having to burn chips and such. I would like to do some data analysis with a laptop, though, and I think that whatever hardware we chose should allow for easy transfer of collected data via serial port. I don't know a whole lot about the hardware side of this, but is that a genuine concern? The main reason that I mentioned a laptop in an earlier post is because 1) they are readily available 2) parts are cheap 3) used laptops are cheap 4) it's very easy to find an modify software on a laptop Of course, using a laptop to control the EFI would not be desireable once the system is completely set up and everything is running good. Telling the passenger to be careful of the box under his feet isn't too practical. :) -Brian >From Diy_Efi-Owner Thu May 5 21:01:13 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA05682; Thu, 5 May 94 21:01:13 GMT Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) @xxx.edu diy_efi-outgoing id AA05676; Thu, 5 May 94 17:01:11 -0400 Date: Thu, 5 May 94 17:01:11 -0400 From: jsg (John S Gwynne) @xxx.edu> Apparently-To: DIY_EFI Sender: Diy_Efi-Owner Precedence: bulk @xxx.edu (Message jsg:105) Received: from [192.105.104.3] by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/lib/mh/slocal -user jsg id AA05611; Thu, 5 May 94 16:52:31 -0400 Received: from by system3.lcs.gov.bc.ca with SMTP (1.37.109.6/16.2) id AA12110; Thu, 5 May 94 13:54:03 -0700 @xxx.ca X-Openmail-Hops: 1 Date: Thu, 5 May 94 13:53:45 -0700 Message-Id: Subject: Re: Which CPU? To: Diy_Efi-Owner, jsg I should say that although I have started with a 68HC11 I would be happy to change to a different CPU if it was easier to program. I just picked the 68HC11 because that what we used in school and I could buy EVB cheap. I don't really keep up with what other MCU's are available and presumably the newer ones are easier to program so maybe someone would like to make a recommendation. Wes Evernden ---------- From: Diy.Efi-Owner; jsg To: DIY.EFI Cc: jsg Subject: Re: Intro Date: Thursday, May 05, 1994 1:12PM <> -------- @xxx.GOV> , you write: | A while ago I worked with a company called CUbit - they made, among other | things, an 80186 based, STD Bus board. What I particularly enjoyed about | their set-up is that the on board ROMs would communicate with Borland's C | Remote debugger. That means you write the code on a PC (all Borland), | compile and link it, and then down load it to the board - and you can step | through the code running on the remote CPU. A breeze to debug. Then you | link the code with a provided library and you can burn that code directly Yea, this can also be done with GNU's gcc and the GNU debugger gdb; a remote serial interfaced debugger. That's why I've chosen to work with the 68000 and a C cross-compiler. It would be nice if we all used the same CPU but I don't think it's going to happen. A more reasonable goal would be to stick with an ANSI-C language (available for PC's, 68HC11's, and about everything else)(avoiding calls to the standard library functions) and have a common interface bus that would let us share sensory interface designs. This way you could use the 80186, I could use a 68HC000, and ???? could use his 68HC11. We could all still share the software (with vary minor changes) and sensor interface designs. John S Gwynne @xxx.edu _______________________________________________________________________________ T h e O h i o - S t a t e U n i v e r s i t y ElectroScience Laboratory, 1320 Kinnear Road, Columbus, Ohio 43212, USA Telephone: (614) 292-7981 * Fax: (614) 292-7292 ------------------------------------------------------------------------------- >From Diy_Efi-Owner Thu May 5 21:15:23 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA05768; Thu, 5 May 94 21:15:23 GMT Received: from nic.hookup.net by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) @xxx.edu diy_efi-outgoing id AA05753; Thu, 5 May 94 17:15:14 -0400 @xxx.155) with UUCP id RAA08542; Thu, 5 May 1994 17:14:28 -0400 Received: by ndigital.com (1.64/waf) via UUCP; Thu, 05 May 94 16:58:24 EDT @xxx.edu @xxx.com (Mike Palmer) @xxx.com> Date: Thu, 5 May 94 16:58:22 EDT Organization: Northern Digital Inc. Waterloo, Ontario, Canada To: DIY_EFI Subject: Thots cont'd Sender: Diy_Efi-Owner Precedence: bulk @xxx.edu Somebody wrote :-)... >> 02 sensors react relatively slow - maybe 10 readings a sec? >> TPS - sensors - at least 10 readings a second if not more >> Temp sensors - 1 reading a second >> RPM sensor - at 10,000rpm (why not?) - that 600,000 degrees per second. 4 >> bumps on the crank shaft (ie - crank triggered ignition) would mean less >> than 1000 per second... >> MAP or MAF sensor - 1 per second - maybe more... 10? > >For temp, intake air temp would also be good. For rates-of-computation, I think the P4 in my Z24 does portions of it's fuel calcs once every 12mS (80+ times per second). BTW, it's 60,000 degrees per second, not 600,000 :-) For speed/density systems MAT is not "good" it's mandatory. Air temp is an important player in the S/D equation. >> The system would have to work at: >> Startup >> Idle >> part throotle cruise >> WOT >> anything else? > >How about deceleration fuel cut. It may be necessary to also consider wall-wetting constants to prevent lean-out and flat-spots on post-decel tip-ins. >One thing I have noticed that has been missed so far is battery voltage. >You need to measure this to correct the pulse width sent to the injector. >Perhaps there are some new injector driver circuits out there that do this? > >I have been using the MC 3334 form Motorola. Yep. It will be necessary also to scale battery volts into the fuel delivery. One way to establish a crude correction table would be to have an injector fire into a measuring crucible for a specified number of pulses at a constant fuel pressure and pulse-width. For various battery volts from 6.0 to 17.0, measure the quantity delivered and then apply a scale factor to the applied pulse width based on the battery voltage to achieve constant deliveries. Don't forget too that injector operation takes time (i.e. for the solenoid to actually pull the injector open). At higher engine speeds this may become a factor as far as timing goes. This is why I like PFI systems conceptually over SFI systems - they are less timing sensitive. (Some of the injectors on my 2.8 fire onto the backs of closed intake valves...). >My experiments so far are probably a little crude to what I have read. I >have been using a PC parallel port connected to a A/D converter and then >used a lookup table to calculate the pulse width. To date the system has >idled the car, but fails to accelerate properly ( engine stumbles and dies >). Crude? Not at all! Actually sounds cool! I know nothing of your system, but can I suggest a few ideas? 1) Filter your TPS and MAP readings using a first order low pass algorithm. It's a little esoteric but it will make the system less susceptible to transients. 2) You'll need to have a process that monitors the delta-MAP and delta-TPS values (i.e. delta = filt(value_now) - filt(value_last_loop)). You can use these delta's to adjust the value of an asynchronous fuel accumulator (AFA). The AFA would be used to adjust injector on-time to mimic an accelerator pump. Your system probably already increases fuel-pressure automatically as a function of manifold vacuum so a look-up table may be necessary to scale the delta contributions accordingly. The AFA would normally add 0mS to the injector on-time when del-MAP and del-TPS are low or zero but when the AFA is adjusted by higher deltas, it would add *or subtract* on-time accordingly. Subtract? Yes, to account for lift-throttle conditions. Pretty complicated no doubt. -- - Mike >From Diy_Efi-Owner Thu May 5 21:16:41 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA05787; Thu, 5 May 94 21:16:41 GMT Received: from localhost.eng.ohio-state.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) @xxx.edu diy_efi-outgoing id AA05781; Thu, 5 May 94 17:16:40 -0400 @xxx.edu> To: DIY_EFI Cc: jsg Subject: Re: Some thoughts and questions on EFI In-Reply-To: Your message of "Thu, 05 May 94 15:11:36 CDT." @xxx.edu> Date: Thu, 05 May 94 17:16:39 -0400 From: John S Gwynne Sender: Diy_Efi-Owner Precedence: bulk @xxx.edu -------- @xxx.edu> , you write: | In case anyone hasn't seen it before (i've seen it posted to r.a.t), | this is the basic equation GM uses for its speed density systems: | | OT = (BPC * F/A * VE * BLC * DFCO * DE)/2 + AE | where OT = Injector On Time | BPC = Base pulse constant | F/A = 1/(desired AF ratio) | VE = Volumetric efficiency | BLC = Block learn multiplier/128 | DFCO = Deceleration fuel cutoff | DE = Deceleration enleanment | AE = Acceleration enrichment Can we get a good description of these terms and qualities such as how much enrichment etc... John S Gwynne @xxx.edu _______________________________________________________________________________ T h e O h i o - S t a t e U n i v e r s i t y ElectroScience Laboratory, 1320 Kinnear Road, Columbus, Ohio 43212, USA Telephone: (614) 292-7981 * Fax: (614) 292-7292 ------------------------------------------------------------------------------- >From Diy_Efi-Owner Thu May 5 22:25:06 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA06275; Thu, 5 May 94 22:25:06 GMT Received: from Rosie.UH.EDU by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) @xxx.edu diy_efi-outgoing id AA06269; Thu, 5 May 94 18:25:03 -0400 Received: from Jetson.UH.EDU by Jetson.UH.EDU (PMDF V4.2-11 #5185) id @xxx.EDU>; Thu, 5 May 1994 17:23:42 CDT Date: Thu, 05 May 1994 17:23:40 -0500 (CDT) @xxx.EDU Subject: Work from START - - - - - > FINISH To: DIY_EFI @xxx.EDU> @xxx.edu" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Sender: Diy_Efi-Owner Precedence: bulk @xxx.edu Before we hammer out software and control algorithyms we really need to figure out what kind of hardware setup we are going to use. Is it 8048, 8051, 8086, 80186, 6800, 6500, 68000, or what? It would be a good idea to keep the price down! Considering a 8048 costs 75 cents and a 68000 will be less than $5, its hard to justify a specialized microprocessor that costs $700 (even thought it comes with RAM, ROM, etc.) Just like John said, lets keep this streamlined. If we all use different setups, we won't accomplish anything except piss each other off while lobbying for "our" setup. And to those out there who hate EPROMs. Don't worry- just buy an EPROM emulator. Or if we really want to be high tech, lets use flash ROM (RAM). Then we won't need anything but a parallel interface to our computer, (DOS computer that is). We really need a parallel interface anyway while we optimize the setup by logging data and making modifications. Later, Jeff >From Diy_Efi-Owner Fri May 6 01:44:19 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA08042; Fri, 6 May 94 01:44:19 GMT Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) @xxx.edu diy_efi-outgoing id AA08036; Thu, 5 May 94 21:44:17 -0400 Date: Thu, 5 May 94 21:44:17 -0400 From: jsg (John S Gwynne) @xxx.edu> Apparently-To: DIY_EFI Sender: Diy_Efi-Owner Precedence: bulk @xxx.edu (Message jsg:108) Received: from wotan.compaq.com by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/lib/mh/slocal -user jsg id AA06328; Thu, 5 May 94 18:49:33 -0400 Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp (Smail3.1.28.1 #6) id m0pzCBP-0002fAC; Thu, 5 May 94 17:46 CDT Received: from bangate.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #8) id m0pzCBO-000peJC; Thu, 5 May 94 17:46 CDT @xxx.com> Received: by bangate.compaq.com with VINES ; Thu, 5 May 94 17:46:17 CDT Date: Thu, 5 May 94 17:42:55 CDT @xxx.com Subject: re: Thots cont'd To: twisto.eng.hou.compaq.com!wotan!coulomb.eng.ohio-state.edu!Diy_Efi-Owner Cc: @xxx.com (Mike Palmer) Wrote: | >One thing I have noticed that has been missed so far is battery | voltage. | >You need to measure this to correct the pulse width sent to the | injector. | >Perhaps there are some new injector driver circuits out there | that do this? | > | >I have been using the MC 3334 form Motorola. | | Yep. It will be necessary also to scale battery volts into the | fuel delivery. One way to establish a crude correction table | would be | to have an injector fire into a measuring crucible for a specified | number of pulses at a constant fuel pressure and pulse-width. For | various battery volts from 6.0 to 17.0, measure the quantity | delivered and then apply a scale factor to the applied pulse width | based on the battery voltage to achieve constant deliveries. What voltage does an injector need to open? If it is an electro-magnetic device like a solenoid then voltage isn't really important, as long as there is plenty of current. If the voltage level is important, then it would be simpler to use a regulator to keep the voltage constant at, say, 10 volts. If battery voltage drops below that, the car isn't going to run well anyway, regardless of what the injectors are doing. >From Diy_Efi-Owner Fri May 6 01:45:15 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA08141; Fri, 6 May 94 01:45:15 GMT Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) @xxx.edu diy_efi-outgoing id AA08135; Thu, 5 May 94 21:45:14 -0400 Date: Thu, 5 May 94 21:45:14 -0400 From: jsg (John S Gwynne) @xxx.edu> Apparently-To: DIY_EFI Sender: Diy_Efi-Owner Precedence: bulk @xxx.edu (Message jsg:109) Received: from wotan.compaq.com by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/lib/mh/slocal -user jsg id AA06394; Thu, 5 May 94 19:04:18 -0400 Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp (Smail3.1.28.1 #6) id m0pzCOF-0002cBC; Thu, 5 May 94 17:59 CDT Received: from bangate.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #8) id m0pzCOE-000pe6C; Thu, 5 May 94 17:59 CDT @xxx.com> Received: by bangate.compaq.com with VINES ; Thu, 5 May 94 17:59:33 CDT Date: Thu, 5 May 94 17:47:27 CDT @xxx.com Subject: re: Work from START - - - - - > FINISH To: twisto.eng.hou.compaq.com!wotan!coulomb.eng.ohio-state.edu!Diy_Efi-Owner Cc: @xxx.EDU Wrote: | Before we hammer out software and control algorithyms we really | need to figure out what kind of hardware setup we are going to | use. | | Is it 8048, 8051, 8086, 80186, 6800, 6500, 68000, or what? | Lets keep all the discussions going. I am personally more interested in the control algorithms than the hardware itself, but the hardware issues need to be resolved also. We have two basic choices: microcontroller (8052, 6811, etc). and CPU (80x86, 680x0). I would say that in the interests of cheapness and simplicity the microcontroller provides the best solution, but that is IMO. Maybe we should bat ideas around for a week or so, then have a vote. we are probably still picking up new people who have valuable opinions, so no need to rush things. I'm enjoying just reading what has been posted so far. also, if anyone has access to things we are likely to need like pcb routing and etching, compilers for whatever processor we decide on, etc., they should speak up. Hardly anyone will have all the resources to do all this, but between us we should be able to put all the pieces together. --steve ÿ