From owner-diy_efi Mon Nov 7 21:13:29 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA06345; Mon, 7 Nov 94 21:13:29 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 AA06340; Mon, 7 Nov 94 16:13:26 -0500 Received: from twisto.eng.hou.compaq.com by wotan.compaq.com with smtp (Smail3.1.28.1 #12) id m0r4bKO-000vJgC; Mon, 7 Nov 94 15:10 CST Received: from bangate.compaq.com by twisto.eng.hou.compaq.com with smtp (Smail3.1.28.1 #10) id m0r4bIF-000uHWC; Mon, 7 Nov 94 15:07 CST Message-Id: Received: by bangate.compaq.com with VINES ; Mon, 7 Nov 94 15:07:59 CST Date: Mon, 7 Nov 94 14:51:31 CST From: Steve=Ravet%Prj=Eng%PCPD=Hou@bangate.compaq.com Subject: re: Chips To: diy_efi Cc: Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI jws@mlb.semi.harris.com (James W. Swonger) Wrote: | I had an interesting conversation today with a couple of guys from our | Automotive design group. They were down for an "Engineering Excellence | Workshop" and were running a demo of an integrated knock sensor signal | processor. This thing (HIP9010) is controlled by a microprocessor bus | port, and does programmable gain, filtering, windowing and integration. | It produces an analog output voltage for knock amplitude. This sounds like a great part for diy_efi. Is it in a knock sensor form factor, or does it require a knock sensor and other stuff in front? And does it work with the J1850 single wire bus you mentioned below? | They also had an eval board for the J1850 single wire automotive bus | interface products. I read about this in EDN products edition. It sounds very interesting. for those of you who don't know, this is sort of an ethernet for cars. Rather than run a 40 pin ribbon cable carrying address/data info in parallel all around the car's interior, SAE J1850 provides for packetizing information, shipping it onto a bus, prioritizing packets, resolving bus contention, etc on a single or double wire bus. Single wire is 10.4kbps, double is 41.6kbps. Harris makes a two chip set for this where one encodes/decodes messages with an 8bit digital interface, the other is the driver for the line. The idea is that eventually smart sensors (like the one described above) won't just put out some sort of analog voltage, they will package their information and put it right on the bus, where the microprocessor can get the info already in digital form. I would be interested in getting more information on this chip set and the eval board, James, if that is possible. | | They seemed apprehensive about opening themselves up to a deluge of | e-mail, but if anybody has the urge to discuss these devices I am | not so shy. I broached the subject of samples to them; I think that | discreet inquiries could be handled, if it doesn't become a scene | from a nature show. Could you find out what other types of automotive products Harris makes, and post a summary? --steve From owner-diy_efi Mon Nov 7 22:58:02 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA06910; Mon, 7 Nov 94 22:58:02 GMT Received: from slopoke.mlb.semi.harris.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 AA06905; Mon, 7 Nov 94 17:57:59 -0500 Received: from billy.mlb.semi.harris.com by slopoke.mlb.semi.harris.com (4.0/SMI-4.0) id AA02376; Mon, 7 Nov 94 17:57:57 EST Received: by billy.mlb.semi.harris.com (4.1/SMI-4.1-jmb) id AA07954; Mon, 7 Nov 94 17:57:56 EST Date: Mon, 7 Nov 94 17:57:56 EST From: jws@mlb.semi.harris.com (James W. Swonger) Message-Id: <9411072257.AA07954@billy.mlb.semi.harris.com> To: DIY_EFI Subject: re: Chips Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI The knock sensor is a digitally controlled analog signal processing function block. The filters, gain blocks, etc. can be "bent" by bytes of data written over a bus, but the output is still an analog voltage. I suggested to them the possibility of developing a J1850 follow-on product which would incorporate an analog I/O function, in order to make single-wire bus compatible sensors a practical thing. This is certainly a doable thing, but it would take a year or so to see product (if it even gets onto the roadmap). This device takes a standard sensor output and does gain, filter, window functions (it also uses a reference channel for noise cancellation; I gather that one approach is to put a knock sensor on each head of a V- motor and use the quiet one as the reference for the live one on a per-cylinder basis. I'll need to digest the datasheet a bit more thoroughly. I took a few extras, if anybody wants to send me a SASE (e-mail me). From what I saw, the output of the sensor processor is an analog pulse; I believe there is a sample/hold block on chip which can turn this into a DC output. At this point some sort of A-D (1 - n bits) would still be necessary for a digital system; an analog controlled spark advance system could use the output as a counterweight to RPM. I was free- associating at length, and mentioned to the Automotive guys the possibility that some clever lad could take this output and mate it to an MSD box's spark retard input and do some neat knock elimination. I had to explain what an MSD box was; they weren't motorheads. I will try to find a copy of the Automotive databook and see what else looks interesting. I know there are injector drivers and that sort of thing. If any of you out there have specific experience with instrumenting up automotive systems using a PC, one of the guys (the one who wrote the demo/control software) was interested in getting more familiar with the down-'n'-dirty; he has his own method, but really perked up when I mentioned the aftermarket laptop-accessible injection controllers (DFI) and the Turbolink monitoring hdwr/sftwr for GNs. I think these folks could really benefit from a few E-'rodders participating in a mutually advantageous exchange (say no more, say no more, nudge). I will forward contact info if desired. I have the guy's card, but he was the one worried about too much random E-mail so for now I'll be his mail drop. From owner-diy_efi Mon Nov 7 23:29:33 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA08219; Mon, 7 Nov 94 23:29:33 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 AA08214; Mon, 7 Nov 94 18:29:30 -0500 Received: from aztec.al.noaa.gov by tomcat.al.noaa.gov with SMTP id AA13469 (5.65c/IDA-1.4.4 for ); Mon, 7 Nov 1994 16:36:16 -0700 Message-Id: <199411072336.AA13469@tomcat.al.noaa.gov> Date: 7 Nov 1994 16:27:56 -0700 From: "Ciciora Steve" Subject: FW: Chips To: DIY_EFI Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI I for one would _LOVE_ to play with some of these neat chips, but if you can get only one (if you are lucky) or can't get the chip at all, then what's the point? I saw a review of a Bosch knock sensor chip in SAE'e rag and circled number 41 for mor information. Never got a response, so I made half a dozen phone calls to track down the manufacture. He wasn't even interested in talking to me unless he could 'sample' me 50 of them at $25 each. Was a realy neat chip, and I might pay a little more if I could buy just one, but he had no interest in that. If memory serves, this chip had programmable width filters, programmable center frequency, programmable gain, and outputs a digital signal when it detects a knock (one bit). - Steven Ciciora ________________________________________________________ I had an interesting conversation today with a couple of guys from our Automotive design group. They were down for an "Engineering Excellence Workshop" and were running a demo of an integrated knock sensor signal processor. This thing (HIP9010) is controlled by a microprocessor bus port, and does programmable gain, filtering, windowing and integration. It produces an analog output voltage for knock amplitude. One of the guys had a PC/Windows control demo running the IC against a simulated sensor knock waveform generated from a digital recording. Pretty spiffy. The designers have very little automotive (i.e. greasy bloody knuckles) experience; I talked to them for a while about my various mailing list lurkings and my impressions of the garage tinkering and aftermarket developments I see ongoing. They also had an eval board for the J1850 single wire automotive bus interface products. They seemed apprehensive about opening themselves up to a deluge of e-mail, but if anybody has the urge to discuss these devices I am not so shy. I broached the subject of samples to them; I think that discreet inquiries could be handled, if it doesn't become a scene from a nature show. From owner-diy_efi Tue Nov 8 01:12:51 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA10385; Tue, 8 Nov 94 01:12:51 GMT Received: from mailbox.syr.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 AA10380; Mon, 7 Nov 94 20:12:48 -0500 Received: from hydra.syr.edu by mailbox.syr.edu (8.6.9/SUM-V8-1.0) id RAA01856; Mon, 7 Nov 1994 17:24:00 -0500 Received: by hydra.syr.edu (5.0/Spike-2.0) id AA24516; Mon, 7 Nov 1994 17:25:07 +0500 Message-Id: <9411072225.AA24516@hydra.syr.edu> To: DIY_EFI Subject: Re: mailing list for 68hc11 In-Reply-To: Your message of "Mon, 24 Oct 1994 15:25:55 EDT." <9410241925.AA27289@coulomb.eng.ohio-state.edu> Date: Mon, 07 Nov 1994 17:25:06 -0500 From: Bob Valentine Content-Length: 337 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI John -- Could you please change my mail address from 'ravalent@mailbox.syr.edu' to 'ravalent@liii.com'? I've moved recently, and telnetting to Syracuse is a pain.... thanks, --> Bob Valentine <-- --> ravalent@mailbox.syr.edu <-- "Hard Acceleration Saves Costly Aggravation" From owner-diy_efi Tue Nov 8 01:43:20 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA10452; Tue, 8 Nov 94 01:43:20 GMT Received: from localhost.eng.ohio-state.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 AA10446; Mon, 7 Nov 94 20:43:18 -0500 Message-Id: <9411080143.AA10446@coulomb.eng.ohio-state.edu> To: DIY_EFI Subject: Re: Chips In-Reply-To: Your message of "07 Nov 94 16:27:56 MST." <199411072336.AA13469@tomcat.al.noaa.gov> Date: Mon, 07 Nov 94 20:43:18 -0500 From: John S Gwynne Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI -------- In message <199411072336.AA13469@tomcat.al.noaa.gov> , you write: | I for one would _LOVE_ to play with some of these neat chips, but if you ca | n | get only one (if you are lucky) or can't get the chip at all, then what's the | point? I saw a review of a Bosch knock sensor chip in SAE'e rag and circled | number 41 for mor information. Never got a response, so I made half a dozen | phone calls to track down the manufacture. He wasn't even interested in | talking to me unless he could 'sample' me 50 of them at $25 each. Was a real 50 at $25 each... This is the kind of stuff that I would like to see us, as a group, be able to purchase. There are now 130 DIY_EFI readers and if we could just get 25 of us to buy two each, we could do something like that. We don't need the latest in technology to succeed, but it sure could improve the out-come (IMHO). John S Gwynne Gwynne.1@osu.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 owner-diy_efi Tue Nov 8 02:22:01 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA10592; Tue, 8 Nov 94 02:22:01 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 AA10587; Mon, 7 Nov 94 21:21:58 -0500 Message-Id: <9411080221.AA10587@coulomb.eng.ohio-state.edu> Received: by eigen.ee.ualberta.ca (1.37.109.4/15.6) id AA00753; Mon, 7 Nov 94 19:21:54 -0700 From: Dale Ulan Subject: re: admin: group purchase of chips To: DIY_EFI Date: Mon, 7 Nov 94 19:21:53 MST In-Reply-To: ; from "Steve=Ravet%Prj=Eng%PCPD=Hou@bangate.compaq.com" at Nov 7, 94 10:19 am Mailer: Elm [revision: 70.85] Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI > > John S Gwynne Wrote: > > | sensor buffers, CPU's (anyone want to try to split a brick of, say, > | 68333's or 68332's?), etc. 68332's are available from ElectroSonic up here in Canada, but they are going for $45.00 each. They are available in whatever quantity you want, however. Anything from one all the way up to thousands. > etc. I'll collect the list, and post it back when suggestions run dry. Then > decide on what sounds interesting, etc. For now, I'd say lets limit it to > chips/components (ie no group buys for Bosch FI computers, etc). >ALSO, I am very much in favor of purchasing a pre-printed circuit board rather I'm just laying out a PC board for a 68332-based EFI computer. My application has four injector drivers on it, although it's going onto a 3-cylinder. It also has TTL level outputs for four ignition coils, which allows it to be used for any engine from a one-cylinder all the way up to a V8. True SEFI is available for 1-4 cylinder engines, though. 5-cylinders are a bit awkward, as well. After I get a prototype PC board made up and tested, I wouldn't mind building up several of such boards... this will happen sometime in January or February. If there's interest, anyways. -Dale From owner-diy_efi Tue Nov 8 02:24:21 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA10600; Tue, 8 Nov 94 02:24:21 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 AA10595; Mon, 7 Nov 94 21:24:16 -0500 Received: (from met@localhost) by pine.cse.nau.edu (8.6.9/2.2-nau) id TAA04015 for diy_efi@coulomb.eng.ohio-state.edu; Mon, 7 Nov 1994 19:24:14 -0700 Message-Id: <199411080224.TAA04015@pine.cse.nau.edu> From: met@pine.cse.nau.edu (MTN-KAT) Date: Mon, 7 Nov 1994 19:24:14 -0700 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: diy_efi Subject: A nice automotive chip Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Steve Ciciora turned me onto a really nice Engine Interface Peripheral chip from Silicon Systems. >From the data sheet: (copied without permission) The 67F687 is a high performance MSICs ( Mixed Signal Integrated Circuit ) designed to work with a microprocessor in an engine management system. Using two sensor inputs (crank and cam), the 67F687 tracks engine position through one or two complete revolutions with a resolution of 0.25 degrees. Designed to be flexible, the 67F687 will accept a variety of sensor types and pulse patterns. It generates ignition and injection output pulses based on position and time parameters supplied by the host microprocessor, relieving it of many of the real time interrupt routines associated with these tasks. These outputs can directly drive power devices to actuate automotive ignition coils and fuel injectors. A sense input from each device allows individual diagnostics, short circuit protection and ignition coil current limiting. A timer, which measures coil charge time at the ignition sense inputs, enhances closed loop dwell control. Communication with a host microprocessor is through a parallel data and address bus. A general purpose parallel I/O port offers level sensitive input and output capability, in addition to edge detect inputs and PWM outputs. Features: Engine Control Applications 2 or 4 cycle engines Parallel microprocessor bus for control Configurable for a variety of sensor patterns Variable Reluctance or Hall Effect sensor inputs Engine position angle counter to 10,000 RPM 4 igniton outputs (8 individual spark advance values) 8 ignition outputs Dwell timer Igniton coil current limit (for use with external power transistors) Injector driver short circuit protection Diagnostics 8 programmable I/O lines PWM outputs Edge detect inputs On chip oscillator with buffered 8 MHz/31.25 KHz output +5V operation CMOS technology for low power consumption Operating temperature range -40 to +125C 68 pin PLCC The chip are in the low 20's for small quantities. I don't know yet what the break is, IFF enough people are interested then I will contact them for more information. I already have two of these chips and am redesigning my project around them. I'll be using two 6811's and two 67F687's. Here's why; I am designing a complete Engine Managment System, Distributorless Ignition with Multiple Spark Discharge in software running 8 coils. A custom ram tuned intake manifold with SEFI, enhanced with 4 plenum injectors running Ethanol for top-end power. The engine is a stroked 427Ford with 473cid, ported and polished, balanced and blueprinted, nitrous injected. Millam From owner-diy_efi Tue Nov 8 14:32:19 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA12983; Tue, 8 Nov 94 14:32:19 GMT Received: from access4.digex.net 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 AA12978; Tue, 8 Nov 94 09:32:16 -0500 Received: by access4.digex.net id AA08926 (5.67b8/IDA-1.5 for DIY_EFI@coulomb.eng.ohio-state.edu); Tue, 8 Nov 1994 09:16:19 -0500 From: Andy Harrah Message-Id: <199411081416.AA08926@access4.digex.net> Subject: 67F687 To: DIY_EFI Date: Tue, 8 Nov 1994 09:16:18 -0500 (EST) X-Mailer: ELM [version 2.4 PL24beta] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 73 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI The 67F687 chips sounds fantastic! Where fo I get mine? ../Bill Lewis From owner-diy_efi Tue Nov 8 15:29:36 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA13341; Tue, 8 Nov 94 15:29:36 GMT Received: from localhost.eng.ohio-state.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 AA13336; Tue, 8 Nov 94 10:29:34 -0500 Message-Id: <9411081529.AA13336@coulomb.eng.ohio-state.edu> To: DIY_EFI Subject: Dale's 68332 In-Reply-To: Your message of "Mon, 07 Nov 94 19:21:53 MST." <9411080221.AA10587@coulomb.eng.ohio-state.edu> Date: Tue, 08 Nov 94 10:29:34 -0500 From: John S Gwynne Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI -------- In message <9411080221.AA10587@coulomb.eng.ohio-state.edu> , you write: | I'm just laying out a PC board for a 68332-based EFI computer. My application | has four injector drivers on it, although it's going onto a 3-cylinder. | It also has TTL level outputs for four ignition coils, which allows it | to be used for any engine from a one-cylinder all the way up to a V8. | True SEFI is available for 1-4 cylinder engines, though. 5-cylinders are | a bit awkward, as well. | | After I get a prototype PC board made up and tested, I wouldn't mind | building up several of such boards... this will happen sometime in | January or February. If there's interest, anyways. Sounds good... I look forward to see what you come-up with. Is this an "open" design where you will share both the board schematics and software source code? John S Gwynne Gwynne.1@osu.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 owner-diy_efi Tue Nov 8 17:43:21 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA14791; Tue, 8 Nov 94 17:43:21 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 AA14786; Tue, 8 Nov 94 12:43:18 -0500 Received: from aztec.al.noaa.gov by tomcat.al.noaa.gov with SMTP id AA14247 (5.65c/IDA-1.4.4 for ); Tue, 8 Nov 1994 10:50:05 -0700 Message-Id: <199411081750.AA14247@tomcat.al.noaa.gov> Date: 8 Nov 1994 10:41:48 -0700 From: "Ciciora Steve" Subject: FW: 67F687 To: DIY_EFI Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI I'll bring in the address tomorrow. Although I am not the origional poster (well, I did mention this chip about 2 years ago on the hotrod mailing list), I have access to the $2500 development board they sell that goes with this chip. I have access to their software (which is not a complete fuel injection system software; just shows how to talk to the chip and set it up) and the sch. of their development board. The board consists of a 6811 in expanded mode, eprom, ram chip, and the glue logic to talk to the 67F687. Also has 8 injector drivers, 4 coil drivers (2 cyl per coil driver), and some other drivers for things like idle air bypass valves, etc. I'm not really sure what the legal aspects of just copying their software and hardware designes, but If I figured out how to do the above on my own without directly copying their stuff... They are very good about giving out free samples, but I'm not sure how to actually buy a few. Any suggestions on a good way to distribute the data sheets? I could try digitizing them and uploading them somewhere, but I think it might be easer to xerox them and mail them to interested parties. Interested parties could also just get them from the manufacture, when I post the address. Wait! Here is a contact: Silicon Systems Automotive Products 14351 Myford Road Tustin, CA 92680 USA Attn: Tony Anderson (My data sheets are 55 pages long) - Steven Ciciora ________________________________________________________ The 67F687 chips sounds fantastic! Where fo I get mine? ../Bill Lewis From owner-diy_efi Tue Nov 8 20:12:26 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA15315; Tue, 8 Nov 94 20:12:26 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 AA15310; Tue, 8 Nov 94 15:12:19 -0500 Received: from aztec.al.noaa.gov by tomcat.al.noaa.gov with SMTP id AA14690 (5.65c/IDA-1.4.4 for ); Tue, 8 Nov 1994 13:19:06 -0700 Message-Id: <199411082019.AA14690@tomcat.al.noaa.gov> Date: 8 Nov 1994 13:10:39 -0700 From: "Ciciora Steve" Subject: RE: Found.. 8051 FAQ. To: DIY_EFI Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Craig Pugsley writes: <8051 FAQ stuff deleted> >Now, back to an EFI question. > >This is what I plan to do to get it running: > >I'm going to just use a "3-D" look-up table, with RPM on one axis and >load on the other (load being just engine vacuum level for starters). >The location pointed to by RPM and load will be a number that is used >for a counter that turns on the injectors: > >I plan to use 4 bits (=16 points) for the RPM axis and 5 bits (=32 >points) for the load axis, giving a total of 512 settings - (Co >incidentally the same way that other well known controllers are laid >out). > >Once I get an engine to run then I'll start thinking about an >accelerator pump, cold starting, over-run cut off, altitude >compensation, >EGO correction etc etc etc. > >Does the 3D table sound described above sound like a reasonable >implementation? Has anyone tried something like this before? > >Craig. > It sounds like your line of reasoning is very similar to mine! I'm working on some code to do 4 point linear interpolation for the fuel map. My fuel map will take an 8 bit number (0->255) for the engine RPM and an 8 bit number for the engine load. It will then output a number (8 bits? 16 bits?) proportional to the amount of fuel to inject. My map will be 17 x 17 x 8 bit numbers. Even though i will use the upper 4 bits (0->15) for the lookup of the map, to get a point on either side of the 0->15 number you need 17 points, hence the 17 x 17 map instead of 16 x 16. From then I will use the lower 4 bits to do a 4 point linear interpolation. I have some basic code for developing the algorithm, now I need to make it work with only 16 bit integer math. Then I need to translate it to assembly. I could show you what I have so far if you wish. Below is some ramblings that was on the list earlier that you might find of interest: ===================================================================== Lets start off by assuming a few things before we get started. For this example, let's assume we have a 4 cyl 4 liter engine and we want an air/fuel ratio of 14.7/1. This means 14.7 grams of air for each gram of fuel. Also for now, lets assume this engine is operating at an RPM that gives us 100% volumetric effency. Since our engine is 1 liter per cylinder, in order to determine how much fuel to deliver to each cylinder, we need to know the mass of the air in each cylinder. Remember back in high school physics, PV=nRT? P is the pressure in atmosphers, V is the volume in Liters, n is the number of mols of air, R is the universal gas constant (8.206x10E-2 Liters * atmosphers/mols*K), and T is the temperature in degrees Kelvin. A little bit of manipulation will give us P/(R*T)=n/V, where n/V is the density of air in mols per liter. This isn't very useful, so to convert mols to grams, we multiply bolth sides of the equation by the molecular weight of air. I know that somewhere there must be a 'standard' average value for air, but I couldn't find it. I calculated the molecular weight of dry air to be 28.96475143. This should be close. So anyway, the result is: density of air in grams per liter = (mw * P)/(R*T) where mw is the Molecular Weight of air, P is the pressure of air in Atmospheres, R is the gas constant and T is the Temperature in degrees Kelvin. For example, let's plug in 1 atmosphere and 300 degrees Kelvin (24 degrees C, about room temperature). At this temperature and pressure, the density of air is 1.1765 grams per liter. Dividing by the desired air/fuel ratio (14.7) tells us that we want 0.08019 grams of fuel for each liter of engine per cycle. Using a lookup table (generated using a fuel injector flow bench like the one described in Performance Engineering Magazine) we would determine the desired amount of time to hold the fuel injector open. So by measuring the intake manifold pressure and the intake air temperature (hopefully at the same spot that the pressure was measured) we can calculate the amount of fuel needed for a given a/f ratio. But wait! This assumes a constant 100% volumetric effency. We all know that most of the time it is less than 100%, and some times greater. A good estimate is to assume volumetric effency changes with engine RPM and to correct the mass of air calculation with an RPM factor. This is usually done with a 3D Fuel Map. On the X axis we would have the mass of air, the Y axis we would have the engine RPM, and on the Z axis we output the amount of fuel needed. This can be in grams per cycle or if we include the fuel injector correction factor in the fuel map, it can output pulse width. (ranges of values for map/temp) (corrections for cold start, acc, power mode, emmissions mode, fuel econ, etc) (what do you think?) ===================================================================== What do you people think about look up tables? I seem to remember years back in a DFI catalog that they used 16 x 16 look up tables with 4 point linear interpolation. Without having any hands on experience with EFI systems, this is what I plan to use in my system. For the fuel map, I will have an 8 bit RPM go in on one axis and an 8 bit "Density of Air" number (calculated from Air Intake Temp and MAP pressure) go in on the other axis. The output will be an 8 bit pulse width. I will use the 4 most significant bits of each byte (hence the 16 x 16 table part) to get the 4 nearest points to linearly interpolate between. I will then take the top two points and do a linear fit to them (y=mx+b) and plug in the lower 4 bit number into x. Dito for the bottom two points. Then I will take these two y values, do another linear fit (y=mx+b) and this result will be my pulse width. Hmm, reading the above isn't too clear to me, so let me try to re-word it. Assume these names for the 4 points: A B X1 and X2 are the 4 bit lower nibbles to interpolate with. C D Y1=(B-A)*X1 + A Y2=(D-C)*X1 + C Result=(Y2-Y1)*X2 + Y2 A, B, C, and D are 8 bit unsigned numbers. X1 and X2 are 4 bit unsigned numbers. (B-A) and (D-C) are 8 bit signed tempoary results. Y1 and Y2 are (8 bits good enough?) signed numbers. Although the 68332 (sp?) looks like an ideal processor to use because of the timer unit, I have too much time, $$, and effort invested in the 6811. I will be implementing the above in assembly language. Does anyone have any comments/suggestions to the above? Am I on the right track? In thinking about how a carb works, I would need a 'Modifier' for the EFI equivilent of a choke on a carb (works off coolent temp?) and a modifier for the accelerator pump (works off the rate at which the gas petal is being pressed down). Besides for a ignition curve, what else would I need a lookup table for? Thanks for your help, -Steven Ciciora sciciora@aztec.al.bldrdoc.gov ===================================================================== Ciciora Steve writes: > Does anyone have any comments/suggestions to the above? Am I on the right > track? I'm not familiar with the details of interpolation, so I can't comment on that. However I do believe that an 8x8 map is very inadequate. 16x16 plus interpolation is what my EFI Techinologies ECU used. > In thinking about how a carb works, I would need a 'Modifier' for the EFI > equivilent of a choke on a carb (works off coolent temp?) and a modifier for > the accelerator pump (works off the rate at which the gas petal is being > pressed down). Besides for a ignition curve, what else would I need a lookup > table for? Okay, here are the curves that the EFI Technologies ECU I had used: Fuel (16x16) Spark (16x16) Temperature Sensor Linearization Injector Correction f(Throttle) Battary Offset Correction f(Battery Voltage) Transient Multiplier f(Watertemp) Injection Correction f(Air Temp) Injection Correction f(Water Temp) Spark Correction f(Air Temp) Spark Correction f(Water Temp) Injector phasing f(RPM) Except for the first three and the last one, all of those are multiplier tables. By that I mean the pulse width from the first two tables is multiplied by the value in the table for the given condition. In our setup, several of those curves were straight lines at 1 :). Acceleration encrishment uses a constant multiplier and a constant decay rate. There is also a minimum throttle position threshold for acceleration enrichment and a throttle position point for acceleration enrichment saturation. I believe accelration enrichment is scaled linearly between those two points (as a function of throttle position of course). Does this help any? -- Jonathan R. Lusky -- lusky@knuth.mtsu.edu "Turbos are nice but I'd rather be blown!" 68 Camaro Convertible - 350 / TH350 80 Toyota Celica - 20R / 5spd ===================================================================== -------- Before the discussion on lookup tables really gets going, I would like to make sure that I fully understand the basic concepts and equations needed to control the injector portion of this project. The following is a start on what I believe to be the relevant equations for a speed density system. If I'm not on track (check my math), please let me know and feel free to contribute. ************************************** 1 --- Injector duration Description of the control algorithm for injector duration. 1.1 --- Calculation of air flow: lb/hr of air The following describes the calculation of air flow (lbs/hr) as a function of the input parameters MAP, Ta, RPM 1.1.1 --- Constants and variables A_lb/hr: air flow in lb/hr MAP: Manifold Absolute Pressure (atm) (1 atm = 29.29 in (760 mm) of Hg) RPM: revolutions per minute (1/min) Sa: specific gravity of air at 0 deg C and 1 atm Sa = 0.0012929 gr/cc = 0.080713 lb/ft^3 Ta: air temperature (K) (T_in Kelvin = T_in Celsius + 273.15) Vd: engine displacement (ft^3) (i.e., 0.2025 ft^3 for 350 cu. in.) %VE: the volumetric efficiency 1.1.2 --- Equation A_lb/hr = (Sa) X (temp & pressure correction factor, assuming ideal gas) X (engine displacement) X (RPM/2) X (%VE) A_lb/hr (lb/hr) = Sa (lb/ft^3) * MAP/1 () * 273.15/Ta () * Vd/2 (ft^3) * RPM (1/min) * 60 (min/hr) * %VE () A_lb/hr = (661.4 * Vd) * MAP / Ta * RPM * %VE comments: - the 2 in Vd/2 is for a 4-stroke engine. - %VE is primarily a function of MAP and RPM. - (661.4 * Vd) is a constant for a given engine. 1.2 --- Calculation of fuel rate: gal/hr of fuel From the equation in section (1.1.2), the fueling rate can be found as a function of air-fuel-ratio (AFR). 1.2.1 --- Constants and variables AFR: Air fuel ratio F_gal/hr: fuel flow rate in gal/hr Sg: specific gravity of gasoline Sg = 0.74 gr/cc = 46 lb/ft^3 1.2.2 --- Equation F_gal/hr = (air flow lb/hr) / (air fuel ratio) / (specific gravity of gas) X (gal/cubic feet) F_gal/hr (gal/hr) = A_lb/hr (lb/hr) / AFR () / Sg (lb/ft^3) * 7.481 (gal/ft^3) F_gal/hr = 0.1626 * A_lb/hr / AFR Substituting the above equation for A_lb/hr gives, F_gal/hr = (107.6*Vd) * MAP * RPM * %VE / Ta / AFR where (107.6*Vd) is a constant and %VE is primarily a function of MAP and RPM. While this is the basic equation needed to control the injector duration, the terms should be grouped and normalized in such a way as to make programming the CPU easier (i.e., the terms MAP, RPM, and %VE could be combined into one lookup table as a function of MAP and RPM). 1.2.3 --- Determination of AFR The air-fuel-ratio should be 14.7:1 whenever the system is operating in closed-loop mode with the oxygen sensor. During conditions of starting, cold engine, cold O2 sensor, or power enrichment, the system should be operated open loop. Open loop AFR depends on coolant temperature, MAP, and RPM. (need more info here --- need to define the controlling algorithm) 1.3 --- Additional terms -- Acceleration Enrichment, Deceleration Enleanment, and Close-Loop Feedback 1.3.1 --- Acceleration Enrichment (AE) In the prototype controller, AE should simulate the accelerator pump of a traditional carburetor. That would make it an additive term to the equation of (1.2.2) that would add a pre-set quantity of fuel as a function of throttle change. Additionally, it would have an adjustable "decay parameter" that would be similar to the hole diameter of the "shooter". In the future, it may be beneficial to include MAP and coolant temperature into this term. For now, I will just represent it as a yet to be defined additive function of AE. (need more info here --- need to define the controlling algorithm) 1.3.2 --- Deceleration Enleanment (DE) I don't believe this term is necessary in the first prototype of our controller. Ultimately this term will lean the engine during deceleration much as the acceleration enrichment term adds fuel during acceleration. It should have the same inputs as the acceleration term. 1.3.3 --- Close-Loop Feedback (CLF) This should be a multiplicative term representing the integrated error from the oxygen sensor. The conditions for when this term should be included are yet to be defined. Conditions to consider are cold O2 sensor, cold engine, acceleration, deceleration, power enrichment. (others?) (need more info here, need to define the controlling algorithm) 1.4 --- The overall fuel delivery equation. F_gal/hr = (107.6*Vd) * MAP * RPM * %VE / Ta / AFR * DE * CLF + AE In this equation, MAP, RPM, and Ta are engine parameters measured directly. (107.6*Vd) is a constant. %VE is experimentally determined as a function of MAP and RPM. DE and AE depend on MAP, TPS, and coolant temperature. CLF is a function of the O2 sensor input. AFR is a function of crank (starting), cold engine, and power enrichment. 2 --- Idle Air Control TBD 3 --- Spark Timing TBD ****************************************** This is getting lengthy... Will expanding this help anyone? Someone want to start an input/output description or a software description? John S Gwynne Gwynne.1@osu.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 --------------------------------------------------------------------- ---------- ===================================================================== jsg@coulomb.eng.ohio-state.edu (John S Gwynne) Wrote: [article about injection equations deleted] instead of calculating mass airflow from rpm, shouldn't an airflow sensor be used? --steve ===================================================================== > From: Steve=Ravet%Prj=Eng%PCPD=Hou@bangate.compaq.com > Subject: re: basic fuel metering equations > [article about injection equations deleted] > > instead of calculating mass airflow from rpm, shouldn't an airflow sensor > be used? > > --steve Thats a classic debate. Mass-air based systems are generally easier to tune than speed-density system. However, a mass airflow sensor is a restriction in the intake path. Traditionally, mass airflow sensor have also been quite expensive. The aftermarket scene for 5l mustang has changed that for some sizes of MAF sensors, though. Still, the MAF needs to be roughly sized to the airflow requirements of the engine. From what I understand at high flowrates the accuracy of MAF sensors is pretty bad. Bottom line is that MAF costs more and doesn't work as well at WOT... compared to well tuned speed-density systems. The question to ask is does the esier tuning outweigh its other disadvantages? -- Jonathan R. Lusky -- lusky@knuth.mtsu.edu "Turbos are nice but I'd rather be blown!" 68 Camaro Convertible - 350 / TH350 80 Toyota Celica - 20R / 5spd ===================================================================== > In the prototype controller, AE should simulate the accelerator pump of a > traditional carburetor. That would make it an additive term to the equation > of (1.2.2) that would add a pre-set quantity of fuel as a function of > throttle change. Additionally, it would have an adjustable "decay parameter" > that would be similar to the hole diameter of the "shooter". In the future, > it may be beneficial to include MAP and coolant temperature into this > term. For now, I will just represent it as a yet to be defined additive > function of AE. (need more info here --- need to define the controlling > algorithm) It's actually pretty important to have the 'shooter size' and 'decay rate' controlled by engine temperature. I've seen systems that have two accel pumps: one for delta MAP and the other for delta throttle. Ideally, you would model the fuel thickness in the intake manifold between the injector and valve, which would require air temp, manifold temp, manifold vacuum/pressure, and probably an estimation of the willingness of the air to accept the gasoline as a vapour. This is something for someone who has done research on this area... if you can model it, you don't have to spend as much time tuning... > 1.3.2 --- Deceleration Enleanment (DE) > > I don't believe this term is necessary in the first prototype of our > controller. Ultimately this term will lean the engine during deceleration > much as the acceleration enrichment term adds fuel during acceleration. It > should have the same inputs as the acceleration term. Exactly. Just acceleration enrichment turned around. It only adds about fifty or so lines in my code (assembler). Makes a big difference when you're coming out of a corner and you don't have to let the engine cough out the raw gas it sucked in on the overrun. > 1.3.3 --- Close-Loop Feedback (CLF) > > This should be a multiplicative term representing the integrated error from > the oxygen sensor. The conditions for when this term should be included are > yet to be defined. Conditions to consider are cold O2 sensor, cold engine, > acceleration, deceleration, power enrichment. (others?) (need more info here, > need to define the controlling algorithm) Actually, I've seen it done as a combined additive and multiplicative term. The short-term feedback (oscillator) is additive, the long term (block-learn) is multiplicative. I guess this simplifies control calculations... Most FI software I've seen has a lot of compensation for the temperature effects on the O2 sensor. A lot of engine control software attempts to predict the temperature of the exhaust and the exhaust system components to compensate for this. I thought it was wierd, too... -Dale