From Diy_Efi-Owner Fri May 6 15:17:22 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA11807; Fri, 6 May 94 15:17:22 GMT Received: from relay1.UU.NET by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA11801; Fri, 6 May 94 11:17:20 -0400 Received: from camelot.dsccc.com by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AAwosr09907; Fri, 6 May 94 11:17:14 -0400 Received: from sun001.dsccc.com (spd.dsccc.com) by camelot.dsccc.com (5.65c/SMI-V1.8) id AA17228; Fri, 6 May 1994 10:19:49 -0500 Received: from aplo1.dsccc.com by sun001.dsccc.com with SMTP id AA08540 (5.65c/IDA-1.4.4 for ); Fri, 6 May 1994 10:19:51 -0500 Received: by aplo1.dsccc.com id AA04102 (5.65c/IDA-1.4.4 for DIY_EFI@coulomb.eng.ohio-state.edu); Fri, 6 May 1994 10:16:30 -0500 Date: Fri, 6 May 1994 10:16:30 -0500 From: John Jennings Message-Id: <199405061516.AA04102@aplo1.dsccc.com> To: DIY_EFI Subject: Intro and Suggested 1st Priority Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu Hi, I'm a EE/SW Engineer with about 12 years of professional experience. I currently work for a communications equipment manufacturer. I've got extensive experience in design/implementation of real-time operating systems. My prior work includes computer-related consulting in the Nuclear Power industry, and process control for a small packaging industry OEM. Steve Baldwin writes: > > Anyway.....decide what it has to do and _then_ decide what can do it. > Ron Rader aka PTM writes: > Exactly _what_ are we designing? What requirements are we trying > to satisfy? I'll tell ya one thing, if I'm gonna contribute, it had > better be cheap. I can't agree more!!!!! I've seen too many projects die or end with a mediocre product due to fundamental design decisions being made prematurely (even prior to informal requirements). This reminds me of the cartoon where a SW manager gives his subordinates the instructions "You guys get coding and I'll see what they want!". Anyway ... let's talk requirements! Ask yourself the questions "What's this thing going to do and how can we verify that it's doing it correctly?". So far I've seen: 1) The system would have to work at: 1.1) Startup 1.2) Idle 1.3) Part throttle cruise 1.4) WOT 1.5) Deceleration 2) It had better be cheap (< $???) 3) Ability to talk to the ECM with the engine running. 4) Inputs: 4.1) O2 Sensor 4.2) Throttle Position sensor 4.3) Temperature sensor (temp. of what?) 4.4) Intake air temp. sensor. 4.5) Exhaust temp. sensor. 4.6) RPM sensor (maybe an engine position sensor - so you know exactly which cylinder needs fuel / spark next (distributor mounted of course). 4.7) Either a MAP or MAF sensor. 4.8) Humidity sensor? - or altimeter? I suggest that we add: 4) It had better be reliable (> ??? MTBF) 5) The ECM must be small (< 4" X 8" X 2" ??) 6) Standardized RS-232c communications interface. 7) Outputs: 7.1) Fuel Injector drivers. 7.2) Alarms? 7.3) Timing control? Food for thought. Thanks, JJ ----------------------------------------------------------------------- John Jennings INTERNET: jjenning@spd.dsccc.com DSC Communications, Corp. (214) 519-3957 1000 Coit Road, Plano TX 75075 From Diy_Efi-Owner Fri May 6 15:24:53 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA11872; Fri, 6 May 94 15:24:53 GMT Received: from nic.hookup.net by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA11866; Fri, 6 May 94 11:24:42 -0400 Received: from ndigital.UUCP (ndigital@localhost) by nic.hookup.net (8.6.9/1.155) with UUCP id LAA12729; Fri, 6 May 1994 11:24:38 -0400 Received: by ndigital.com (1.64/waf) via UUCP; Fri, 06 May 94 10:38:58 EDT for DIY_EFI@coulomb.eng.ohio-state.edu From: Mpalmer@ndigital.com (Mike Palmer) Message-Id: <18750@ndigital.com> Date: Fri, 6 May 94 10:38:55 EDT Organization: Northern Digital Inc. Waterloo, Ontario, Canada To: DIY_EFI Subject: Reading an O2 sensor Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu >Can someone who is electrically-inclined please explain how O2 sensors >are read? I understand the output of the sensors (basically an s-curve >that is an on/off switch, between 0 and 1 volt), but do you read this >voltage? I have heard that due to something (high-impedance?), you >cannot read this voltage with a normal voltmeter or you will ruin the >sensor. Can someone explain WHY this is and what the correct way to read >the sensor is? Also, how will we read the sensor for our EFI system? >Will a regular A/D board be able to do it? > >thanks- >Brian > >PS I have no idea what impedance is. In simplest terms, impedance is a measure of how much current a load will draw from a source. The source itself has a certain output impedance. When load impedance becomes too low, it attempts to draw alot of current from the source. The output impedance of the source becomes in effect a dropping resistor and the voltage drops across this resistance by Ohm's law. The idea is that a device measuring the voltage at any point in a circuit be of such high input impedance that it draws neglible current. In contrast, a current measuring device (like an ammeter) is best if it mimics a short circuit - i.e. it adds no impedance of it's own to the circuit. An O2 sensor is basically a little source with really high output impedance. This means that in an open circuit condition, the output of the O2 sensor is what the sensor actually produced. However, as soon as a load is put on the sensor (i.e. a meter, A/D converter etc), the voltage quickly drops due to the current drawn by this device producing a voltage drop across the output impedance. It is exceedingly simple to buffer an O2 sensor with an operational amplifier configured as a voltage follower: (see cheesy ascii drawing:) |-------------/\/\/\/\--------- bias voltage (450 mV) | 1 megohm | |\ resistor or higher O2 sensor--------*----|+ \ | \____________________A/D converter | / | |----|- / | | |/ | | | |______________| Op-amps have *very* high impedances (i.e. the LF256 J-FET op-amp has 10^12 ohms of input impedance) and can easily drive the input of an A/D converter. This may be simplifying things a bit *too* much since many O2 sensors must actually have a small bias voltage applied to them (as in the case of GM sensors: the ECM applies a small bias voltage of 450mV through a high impedance. When the voltage read back from the O2 sensor is not this bias, the ECM decides the O2 sensor has reached operating temperature, it's internal imedance has fallen a bit and it can now overcome the bias voltage and drive the line itself). Adding this part would be simple though...(see above) Most digital voltmeters have immensely high input impedances. These units should be fine for measuring an O2 sensor -- - Mike From Diy_Efi-Owner Fri May 6 15:59:43 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA12073; Fri, 6 May 94 15:59:43 GMT Received: from pine.cse.nau.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA12067; Fri, 6 May 94 11:59:40 -0400 Received: (from met@localhost) by pine.cse.nau.edu (8.6.9/2.2-nau) id IAA11374 for diy_efi@coulomb.eng.ohio-state.edu; Fri, 6 May 1994 08:59:32 -0700 Message-Id: <199405061559.IAA11374@pine.cse.nau.edu> From: met@pine.cse.nau.edu (MTN-KAT) Date: Fri, 6 May 1994 08:59:32 -0700 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: diy_efi Subject: FTP site for DIY_EFI Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu I have an ftp site that can handle the miscellaneous bits and pieces that will need to be shared amongst us. Source code, shareware, whatever.... mail to me at met@pine.cse.nau.edu I'll put it in ftp.nau.edu under /public/graphics/gif/racing/DYI_EFI The path may be deceptive but what the heck. I'm for the 6811 myself, due to it's availability, simplicity, abundance of cross assemblers and versatility. Not to mention that I have two EVB boards. I'm working on a sequential port injection scheme using the peak/hold firing technique. I want this to fire-off very quickly, so I have devised a digital logic array to allow me to use only four bits in order to trigger all 16 transistors. This should contribute to the system being able to run upwards of 8-9000RPM's and still maintain control. Personally I'm trying to avoid using the timer for calculating cylinder timing, Not wanting to slow the processor down, I'll use a Hall Effect crank trigger and interrupt at each cylinder with #1 recorded at start-up and let the digital logic board control proper cylinder firing order. More to follow as required. gotta run, Millam E. Tackitt From Diy_Efi-Owner Fri May 6 16:36:32 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA12134; Fri, 6 May 94 16:36:32 GMT Received: from stdvax.gsfc.nasa.gov by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA12128; Fri, 6 May 94 12:36:30 -0400 Date: Fri, 6 May 1994 12:34:56 -0400 (EDT) From: OADDAB@STDVAX.GSFC.NASA.GOV (DIRK BROER) Message-Id: <940506123456.2dc04180@STDVAX.GSFC.NASA.GOV> Subject: Re: Suggested 1st Priority To: DIY_EFI X-Vmsmail-To: @EFI Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu Personally I'm not set on any processor and I am flexible - once I understand how all the sensors and actuators work I can always to the hardware myself.... so... Taking someone else requirements list > >So far I've seen: >1) The system would have to work at: > 1.1) Startup > 1.2) Idle > 1.3) Part throttle cruise > 1.4) WOT > 1.5) Deceleration >2) It had better be cheap (< $???) >3) Ability to talk to the ECM with the engine running. >4) Inputs: > 4.1) O2 Sensor > 4.2) Throttle Position sensor > 4.3) Temperature sensor (temp. of what?) Water temperature! - to tell when the engine has warmed up enough to lean out the mixture a little - perhaps a limp mode to richen the mixture when the water temp gets too high. > 4.4) Intake air temp. sensor. > 4.5) Exhaust temp. sensor. > 4.6) RPM sensor (maybe an engine position sensor - so you know > exactly which cylinder needs fuel / spark next (distributor > mounted of course). > 4.7) Either a MAP or MAF sensor. > 4.8) Humidity sensor? - or altimeter? 4.9) MAT or Manifold Air Temperature 4.10) Additional inputs - knock sensors etc. > >I suggest that we add: should be 5) >4) It had better be reliable (> ??? MTBF) should be 6)... >5) The ECM must be small (< 4" X 8" X 2" ??) >6) Standardized RS-232c communications interface. >7) Outputs: > 7.1) Fuel Injector drivers. > 7.2) Alarms? > 7.3) Timing control? Maybe: 8.4) Additional solenoid and d/a outputs... (Electronically controller waste gate???) I like it. Perhaps we could discuss this list? The come up with a consensus. Keep the requirements flexible. A system that can accomodate all the above - and let the end user delete things he doesn't want or need. Next step would be to do research on the sensors and actuators - to see what kind of drivers and a/d would be needed. Those with algorithm experience could give input on what kind of accuracy / sample rates are required. Then you can decide what CPU to use - maybe one with built-in drivers maybe not.... We may find some people interested in a simple system and some in a more complex system. This might be a good place to split... just keep the info on sensors and actuators going. Dirk From Diy_Efi-Owner Fri May 6 17:05:28 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA12197; Fri, 6 May 94 17:05:28 GMT Received: from suvm.acs.syr.EDU by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA12191; Fri, 6 May 94 13:05:26 -0400 Received: from gamera.syr.edu by SUVM.SYR.EDU (IBM VM SMTP V2R2) with TCP; Fri, 06 May 94 13:05:43 LCL Received: by gamera.syr.edu (5.0/Spike-2.0) id AA07438; Fri, 6 May 1994 13:07:02 +0500 Message-Id: <9405061707.AA07438@gamera.syr.edu> To: DIY_EFI Subject: Re: Suggested 1st Priority In-Reply-To: Your message of "Fri, 06 May 1994 12:34:56 EDT." <940506123456.2dc04180@STDVAX.GSFC.NASA.GOV> Date: Fri, 06 May 1994 13:07:00 -0400 From: Bob Valentine Content-Length: 741 Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu >Personally I'm not set on any processor and I am flexible - once I >understand how all the sensors and actuators work I can always to the >hardware myself.... so... I agree... >Then you can decide what CPU to use - maybe one with built-in drivers maybe >not.... I'd opt for seperate drivers. This would probably be cheaper, and allow more flexibility. I can't find my notes right now (I'm moving tommorrow), but Cherry Semiconductor has some injector drivers and other units that seem to be rather flexible. I'll look into this and post findings.... --> Bob Valentine <-- --> ravalent@mailbox.syr.edu <-- "Clinging Tenatiously to the Trailing Edge of Technology" From Diy_Efi-Owner Fri May 6 17:21:23 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA12330; Fri, 6 May 94 17:21:23 GMT Received: from maxwell.ee.washington.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA12324; Fri, 6 May 94 13:21:21 -0400 Received: from uw-isdl.ee.washington.edu by maxwell.ee.washington.edu (1.37.109.4/UW-NDC Revision: 2.26 ) id AA11862; Fri, 6 May 94 10:21:19 -0700 Received: from calcium.ee.washington.edu (calcium.ee.washington.edu [128.95.31.192]) by uw-isdl.ee.washington.edu (8.6.8.1/8.6.6) with ESMTP id KAA28537 for ; Fri, 6 May 1994 10:22:58 -0700 From: Pierre-Henry Marbot Received: from localhost (phm@localhost) by calcium.ee.washington.edu (8.6.4/8.6.4) id KAA22447 for DIY_EFI@coulomb.eng.ohio-state.edu; Fri, 6 May 1994 10:21:36 -0700 Date: Fri, 6 May 1994 10:21:36 -0700 Message-Id: <199405061721.KAA22447@calcium.ee.washington.edu> To: DIY_EFI Subject: Topics on EFI Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu It would be cool to use this list (since a lot of people have their own idea on which processor to use etc) to build up some kind of EFI encyclopedia (kinda lika a FAQ): topics would include: * where to find parts. * how to read sensors/ which sensors to use/ how to adapt them to a non EFI car. * equations and control algorithms. * examples of "running" implementations. * who has which resources (eg: I have a great sccanner and a comprehensive programmer (PROMS and uProcs). * Lets not forget electronic timing. Maybe water injection. I am up to my neck in administering other aliases, but I am sure some of you might volunteer to compile what others know. It would be great. just my 0.0000002 cents carburator-full Peter From Diy_Efi-Owner Fri May 6 17:28:28 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA12389; Fri, 6 May 94 17:28:28 GMT Received: from us.dynix.com by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA12383; Fri, 6 May 94 13:28:26 -0400 Received: from cpu.us.dynix.com by dnxjcit.us.dynix.com with SMTP id AA26393 (5.65c/IDA-1.4.4 for ); Fri, 6 May 1994 11:26:57 -0600 Received: by cpu.us.dynix.com (AIX 3.2/UCB 5.64/4.03) id AA47684; Fri, 6 May 1994 11:28:07 -0600 Date: Fri, 6 May 1994 11:17:38 -700 (MDT) From: Jim Conforti Subject: Direction To: DIY_EFI Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu If everyone is *serious* about doing this, then I would suggest that you take Rod's advice and begin with an ignition controller FIRST .. Learn how to interface the uC stuff w/ the engine!! Having worked with Rod on reversing some Bosch stuff, I can tell you that a full blown SEFI system is MUCH more complex than you wish to deal with for a first project .. too many darn variables to do it RIGHT .. Now some input: 1) Devise the controller software around TWO possible algorithms ... a) Speed/Density .. aka TPS,MAT,MAF .. and b) Measured Air .. aka Airflow or Airmass sensors .. reason: The norm-aspirated "std." engine guys can use the Measured Air better with stock setups, the "turbo" and "multi-butterfly" guys will want the speed/density stuff .. 2) Decide on how many different trigger setups are allowable .. a) Missing Tooth b) Added Tooth and 2 sensor systems c) Cam sensor, distrib sensor, or #n coil wire sensor (for bank position) 3) Consider your coil output .. may I suggest DUAL-PLUG coils .. that way a 4 output system will handle a V-8 .. 4) Once you have all this down and LISTED somewhere .. THEN YOU CAN TALK ABOUT the ALGORITHMS to RUN IT! Jim Conforti From Diy_Efi-Owner Fri May 6 18:10:59 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA12498; Fri, 6 May 94 18:10:59 GMT Received: from dopey.cc.utexas.edu by coulomb.eng.ohio-state.edu via SMTP (920330.SGI/920502.SGI) for /usr/local/mail/majordomo/wrapper resend -p bulk -M 10000 -l Diy_Efi -f Diy_Efi-Owner -h coulomb.eng.ohio-state.edu -s -r DIY_EFI@coulomb.eng.ohio-state.edu diy_efi-outgoing id AA12492; Fri, 6 May 94 14:10:56 -0400 Received: (from efrank@localhost) by dopey.cc.utexas.edu (8.6.8.1/8.6.6/cc-wf-sunos.mc-1.1) id NAA29624; Fri, 6 May 1994 13:10:49 -0500 Date: Fri, 6 May 1994 13:10:46 -0500 (CDT) From: The_Mechanic Subject: Re: Direction To: DIY_EFI In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Diy_Efi-Owner Precedence: bulk Reply-To: DIY_EFI@coulomb.eng.ohio-state.edu A digression providing food for thought: I'd like to suggest one thing regarding timing position sensors: On all engines, it is far more accurate to obtain timing information (via toothed wheel, hall effect sensor/magnets, etc.) at the crankshaft, rather than at the distributor or camshaft. Of course, this is not always feasible, but in general, much greater timing accuracies can be achieved. This is especially true if the given crank has been indexed so that each rod journal's relative position is known accurately. This is typicial of a blueprinted race engine, or for someone looking to extract the "maximum" performance (ie, precision, accuracy) of their EFI system. That *IS* the ultimate goal here, isn't it? Make _serious_ (but managable) horsepower? It sure is mine... In any case, the timing position sensor type needs to be determined. I'm told that this piece is the "weak link" in the Electromotive TEC-II system. What do people think is the best way to go here? The TEC-II uses a 60 tooth wheel and sensor to read crank postion. (a 120 tooth wheel is available for distributor installations) Other crank triggered ignition systems use magnets imbedded in the front pulley or harmonic balancer. Others use optical triggers. What say? Anyone out there have any practical experience? Do tell... Erik The University of Texas, Austin 1968 BMW 2002. Currently using sputtering Weber DCOE's.