From owner-diy_efi Fri Nov 11 20:41:13 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA04640; Fri, 11 Nov 94 20:41:13 GMT Received: from eye.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 AA04635; Fri, 11 Nov 94 15:41:10 -0500 Received: from ash.eye.com by eye.com with SMTP (1.36.108.4/16.2) id AA03702; Fri, 11 Nov 1994 15:40:42 -0500 Received: by ash (1.37.109.8/15.6) id AA15597; Fri, 11 Nov 1994 15:40:42 -0500 Date: Fri, 11 Nov 1994 15:40:42 -0500 From: Mark Reichert Message-Id: <9411112040.AA15597@ash> To: DIY_EFI Subject: bad math humor (was re: Re: HIP9010) Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Steve writes: > Maybe Jason forgot these: > > :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) I don't know. I'd imagine a quadratic or cubic interpolation would be nice. Everyone wants their engine to run continuously, but I want mine to run *smooth*! Mark From owner-diy_efi Sat Nov 12 00:44:30 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA26319; Sat, 12 Nov 94 00:44:30 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 AA26314; Fri, 11 Nov 94 19:44:26 -0500 Received: by knuth.mtsu.edu (Smail3.1.28.1 #21) id m0r66Yk-000CuNC; Fri, 11 Nov 94 18:43 CST Message-Id: From: lusky@knuth.mtsu.edu (Jonathan R. Lusky) Subject: Re: OEM algorithms (DSM) To: DIY_EFI Date: Fri, 11 Nov 1994 18:43:14 -0600 (CST) In-Reply-To: <9411111619.AA03272@fuelrod> from "Jim Pieronek" at Nov 11, 94 09:19:51 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: 1463 Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Jim Pieronek writes: > > OK, you got me. What the heck is a UEGO? In late '85 I left GM for > my current job, which does not involve engines. It's an oxygen sensor that is accurate from about 10:1 to 20:1 AFR with gasoline. We paid $900 for a spare from Horiba back in '93. I think the cost of the box to read it plus the original sensor was around $10k back in 92. Program the box with the a couple of ratios to reepresent the makeup of the fuel, and it reads out AFR to two decimal places. It will also display in Lambda. > I never saw any docs on the heads-up display either. As I recall, > there was a location in ECM memory that the software could look at to > see where the thumbwheel (a pot) was set. There were also some > digital inputs. There were several BNC connectors on the big black box, never found out what those were for. > This all brings back a lot of old war stories about that job, like the > time we got a catalytic converter so hot that the carpeting melted and > smoked... and several hand-made engines that we wrecked... what fun > that all was. Never smoked the carpet, but I did disentigrate my lightoff cats in '93. COre was just GONE, no trace... -- 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 From owner-diy_efi Sat Nov 12 04:47:34 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA20488; Sat, 12 Nov 94 04:47:34 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 AA20483; Fri, 11 Nov 94 23:47:29 -0500 Message-Id: <9411120447.AA20483@coulomb.eng.ohio-state.edu> Received: by eigen.ee.ualberta.ca (1.37.109.4/15.6) id AA03383; Fri, 11 Nov 94 21:47:27 -0700 From: Dale Ulan Subject: Re: bad math humor (was re: Re: HIP9010) To: DIY_EFI Date: Fri, 11 Nov 94 21:47:26 MST In-Reply-To: <9411112040.AA15597@ash>; from "Mark Reichert" at Nov 11, 94 3:40 pm Mailer: Elm [revision: 70.85] Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI > I don't know. I'd imagine a quadratic or cubic interpolation > would be nice. Everyone wants their engine to run continuously, > but I want mine to run *smooth*! > > Mark Internally, linear interpolation is fine, but engines are horribly non-linear devices. They often have 5+ order differential equations that describe their behaviour. Check out any of Elbert Hendricks' SAE papers... :-) The implication of this is that you need a fuel table that's at least 16x16 to catch the peaks. With some clever software, you can time the peaks to match up with boundaries, but this is not often done. Memory is cheap, programmer's time is not. So although the fuel map can be interpolated in the ECM linearly, when you have an engine 'map' that only has a few points on it, you may want to run it through a PC or workstation based math package to come up with a full table. In most engine control platforms, there just isn't time to do anything other than linear interpolation. A typical engine computer has over fifty tables that it has to do interpolations on... and it typically goes through most of them in about 5 ms or so... along with the other calculations the ECM has to do. It really isn't necessary either, depending on the resolution of the map. The normal way of doing ECM work is to do the math 'grunt-work' in a workstation in someone's office, then leave the ECM firmware as simple as possible when it comes to math. Memory in a computer is cheap, processing speed is not. Neither is a programmer's time to come up with an optimum quadratic or cubic curve-fitting interpolation and have it execute in the required (insane) amount of time. -Dale From owner-diy_efi Sat Nov 12 06:33:10 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA10185; Sat, 12 Nov 94 06:33:10 GMT Received: from [129.55.55.1] 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 AA10180; Sat, 12 Nov 94 01:33:07 -0500 Received: from fuelrod ([129.55.57.2]) by juliet.ll.mit.edu id AA02314g; Sat, 12 Nov 94 01:37:21 EST Received: by fuelrod (4.1/SMI-4.1) id AA03432; Fri, 11 Nov 94 23:32:18 MST Date: Fri, 11 Nov 94 23:32:18 MST From: jvp%fuelrod@juliet.ll.mit.edu ( Jim Pieronek) Message-Id: <9411120632.AA03432@fuelrod> To: DIY_EFI Subject: Complicated math, Multi-tasking in ECMs Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Dale Ulan writes: > > The normal way of doing ECM work is to do the math 'grunt-work' in > a workstation in someone's office, then leave the ECM firmware as > simple as possible when it comes to math. Memory in a computer is > cheap, processing speed is not. Neither is a programmer's time to > come up with an optimum quadratic or cubic curve-fitting interpolation > and have it execute in the required (insane) amount of time. > I agree that linear interpolation is the way to go, particularly with the controllers that people tend to use these days - 6811s and so forth. I suspect it won't be as big an issue when PowerPC controllers (and the 68k job I've heard about here), possibly with floating point, come along. But I think that the tradeoff in programmer's time vs. memory tilts toward spending money on the programmer. The engine that I worked on was targeted for production by the million. Every cent that could be cut from the engine cost was $10,000 over a million engines. If a programmer could work a year on something and save 25 cents on memory the company would save $250,000 - many times his salary. And then he'd be hacked off because he didn't get any of that loot. On a completely different subject, as I regurgitate all of this rubbish from my GM days, I recall that all of the ECM code ran in "big loop" mode - we did not use true multi-tasking. We only had one or two interrupts and they couldn't cause task switching. There were some big hunks of low-priority code that were run in "chunks" that had to execute in a fixed number of milliseconds and preserve their state until the next piece was run. This drove me nuts after a while and I secretly wrote a tiny multi-tasking exec for our ECM that was referred to as the "secret weapon exec" by us software guys. This was strictly against Delco policy - "There will be no multi-tasking, it is too scary." We did a lot of our development work with the secret weapon because we didn't have to pay attention to the "wedgies" - the preassigned time slices for the low priority code. It worked very nicely. I heard that it found its way into an electronic transmission controller, and I don't know if the Delco guys ever managed to pry it out. Hopefully things have changed at Delco over the years. (At GM, Delco supplies the ECM tools to the engine types, of which I was one, and they develop with it. The engine types give their results to the Delco guys who sprinkle holy water on it and stick it in a PROM. I think the Delco people set policy on coding because they ultimately had warranty responsibility for the ECMs). So my question is this - do you diy types use multi-tasking, or are you running the "big loop"? In all of my more recent microcontroller work I have used multi-tasking and planned on using it for redoing the timing on my vehicle. Why do I want to multi-task? Because I want to run some complicated floating point stuff in the background to update tables! By gum, these topics are tied together! Any thoughts/comments? - Jim From owner-diy_efi Sat Nov 12 20:04:47 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA22801; Sat, 12 Nov 94 20:04:47 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 AA22796; Sat, 12 Nov 94 15:04:42 -0500 Message-Id: <9411122004.AA22796@coulomb.eng.ohio-state.edu> Received: by eigen.ee.ualberta.ca (1.37.109.4/15.6) id AA05411; Sat, 12 Nov 94 13:04:32 -0700 From: Dale Ulan Subject: Re: Complicated math, Multi-tasking in ECMs To: DIY_EFI Date: Sat, 12 Nov 94 13:04:30 MST In-Reply-To: <9411120632.AA03432@fuelrod>; from "Jim Pieronek" at Nov 11, 94 11:32 pm Mailer: Elm [revision: 70.85] Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI > I agree that linear interpolation is the way to go, particularly with > the controllers that people tend to use these days - 6811s and so > forth. I suspect it won't be as big an issue when PowerPC controllers > (and the 68k job I've heard about here), possibly with floating point, > come along. Yes, but running the program loop faster (using the power of the CPU to increase the speed, rather than the complexity) allows the use of simple engine models that reflect the engine dynamics in real time. My ECM runs in 1 ms loops... that's 5 loops per cylinder 'fire'. I use that time to model the intake manifold and fuel film dynamics using Elbert Hendricks' equations given in 910258. It turns out that by moving the equations into the z-domain, the tuning and algorithms for transient compensation are much simpler, as they require very few tables, and more measurements than dyno testing. I don't know what the accuracy is supposed to be like, but Hendricks claims that the model is normally within 2% of good dyno data. .... > the company would save $250,000 - many times his salary. And then > he'd be hacked off because he didn't get any of that loot. .... True, I suppose. What I find, though, is that if the code is 24k long (with tables), there's not much of a reason you: a> want to make the code smaller because the next smallest chip available is 16k and b> can't use another 8k of memory, since the smallest common chip that fits that amount of code into it is 32k. ... > This drove me nuts after a while and I secretly wrote a tiny > multi-tasking exec for our ECM that was referred to as the "secret > weapon exec" by us software guys. This was strictly against Delco .... Did that end up in the 6801-based ECM? I found a neat address table that is used to call various routines. There were 16 addresses, and the routine called them in a round-robin fashion. Was this the thing you're talking about, or.... maybe I should quit asking so many questions... > So my question is this - do you diy types use multi-tasking, or are .... > tables! By gum, these topics are tied together! Any > thoughts/comments? Here's my software design... and coding on it is going ok. Should have it running sometime in early January. I don't think many people like the way I do things, but... fast calculations are run in a tight 1ms code loop. It consists of about ten simple differential equations, and a few interpolations as well. This is running the linear fuel-film compensator, although I am considering re-coding the compensator to be the more complicated multi-state compensator, proposed and tested in a later paper. Manifold filling dynamics also contribute two or three de's in this section. pseudo-slow calculations are run in a 4ms round-robin manner, as these calculations are grouped into four sections. Each section is called during each main loop. These include tasks like sensor filtering, 'tweak' calculations, desired fuel mixture calculations, etc. Also, a sliding-mode oxygen feedback controller goes in here. slow sensors and calculations are run in a round-robin manner, and I have 32 spots for these routines. These are called immediately after the main code loop. Sensor diagnostics and very slow sensor calculations go in this group. the MAF sensor is sampled every 60 crank degrees, in an interrupt service routine run off of the TPU. This is to enable the EABS sampling system covered in a later paper by Hendricks. MAP is also treated in this way. Other sensors are sampled at a slower rate in the main code loop. the diagnostic comm routines are run in an interrupt service routine. FLASH re-programming is done in the ISR, as well.... but it's wierd. A FLASH PROGRAM command causes the interrupt routine to lock the processor up, and begin polling the serial port for further special commands. Only the SECTOR_ERASE, SECTOR_PROGRAM, SECTOR_VERIFY, and CONTROLLER_REBOOT commands work in this mode. in case the FLASH gets blown away, I am placing a connector on the board for background-debug mode. This would allow me to re-load its brains in case power was lost during the first power-up. For this reason, the first sector consists of a simple test to verify that the code blocks are ok, and also the diagnostic serial routines. Hopefully, the first sector doesn't need to be erased, but if it gets nuked, there is a back door. That's my approach, anyways. I am trying to use as much engine modelling in my code to estimate internal variables, so I can eliminate as much of the fuel transient problems as possible. That's why I'm using such a high sampling rate in my main loop. And also why I'm not using a multi-tasking exec. The pseudo multi-tasker built into the main loop is capable of handling anything I would like to do with the ECM. -Dale From owner-diy_efi Sun Nov 13 01:01:33 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA23346; Sun, 13 Nov 94 01:01:33 GMT Received: from naitgate.nait.ab.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 AA23341; Sat, 12 Nov 94 20:01:28 -0500 Received: by naitgate.nait.ab.ca (AIX 3.2/UCB 5.64/4.03) id AA14330; Sat, 12 Nov 1994 17:58:16 -0700 Date: Sat, 12 Nov 1994 17:58:15 -0700 (MST) From: Grant Beattie Subject: index 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 index diy_efi From owner-diy_efi Sun Nov 13 01:19:11 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA23568; Sun, 13 Nov 94 01:19:11 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 AA23563; Sat, 12 Nov 94 20:19:08 -0500 Received: from fuelrod ([129.55.57.2]) by juliet.ll.mit.edu id AA05001g; Sat, 12 Nov 94 20:23:37 EST Received: from isotope.reactor by fuelrod (4.1/SMI-4.1) id AA03539; Sat, 12 Nov 94 18:18:34 MST Date: Sat, 12 Nov 94 18:18:34 MST From: jvp%fuelrod@juliet.ll.mit.edu ( Jim Pieronek) Message-Id: <9411130118.AA03539@fuelrod> Received: by isotope.reactor (4.1/SMI-4.1) id AA07413; Sat, 12 Nov 94 18:21:02 MST To: DIY_EFI In-Reply-To: <9411122004.AA22796@coulomb.eng.ohio-state.edu> Subject: Re: Complicated math, Multi-tasking in ECMs Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Dale Ulan writes: > ... > > This drove me nuts after a while and I secretly wrote a tiny > > multi-tasking exec for our ECM that was referred to as the "secret > > weapon exec" by us software guys. This was strictly against Delco > .... > Did that end up in the 6801-based ECM? > > I found a neat address table that is used to call various routines. > There were 16 addresses, and the routine called them in a round-robin > fashion. Was this the thing you're talking about, or.... > maybe I should quit asking so many questions... > No, that is the thing that I got rid of. I put all 16 of those devils into one task that had the lowest priority. That way I didn't have to worry about making sure that everything got done in time for those fellows to get their piece of the pie. Much of the rest of the code ran in interrupt routines. > Here's my software design... and coding on it is going ok. Should have > it running sometime in early January. I don't think many people > like the way I do things, but... > Thanks for all the gory details. As far as the multi-tasking stuff goes - ya gotta do what ya gotta do. If you like doing it your way, well, you've got about a billion GM cars out there doing the same thing. That's hard (not impossible, but hard) to argue with. - Jim From owner-diy_efi Mon Nov 14 05:25:00 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA25911; Mon, 14 Nov 94 05:25:00 GMT Received: from aztec.co.za 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 AA25905; Mon, 14 Nov 94 00:24:52 -0500 Received: by aztec.co.za (Smail3.1.28.1 #5) id m0r6ttb-000KddC; Mon, 14 Nov 94 07:24 EET Date: Mon, 14 Nov 1994 07:24:02 +0200 (SAT) From: Wouter de Waal Subject: Bosch Mono-Jetronic To: efi list Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Maybe this is not the right place to ask, but I'm taking a chance that some of you out there has experience with the Bosch Mono-Jetronic. I'm thinking of fiddling with the one in my wife's Uno, since the car has trouble starting in the morning etc. The local agents say that the thing can't be set, but I've noticed that : 1. There's a (tamper-proof) set screw that opens the throttle butterfly (like an idle speed adjust) This screw is not touching the control arm at all, which can't be right. 2. There's another screw that adjusts just when the idle switch is activated. Now the question is, how do I convince the computer _not_ to adjust the idle speed, so that I can set the butterfly up correctly? Can I just unplug the idle switch? Secondly, I assume the idle switch has to be _just_ closed at idle. Any thoughts appreciated. Wouter de Waal From owner-diy_efi Mon Nov 14 07:13:34 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA26040; Mon, 14 Nov 94 07:13:34 GMT Received: from maxwell.ee.washington.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 AA26035; Mon, 14 Nov 94 02:13:31 -0500 Received: by maxwell.ee.washington.edu (1.37.109.4/UW-NDC Revision: 2.26 ) id AA10593; Sun, 13 Nov 94 23:13:27 -0800 From: Mike Gruber Message-Id: <9411140713.AA10593@maxwell.ee.washington.edu> Subject: Re: Bosch Mono-Jetronic To: DIY_EFI Date: Sun, 13 Nov 94 23:13:27 PST In-Reply-To: ; from "Wouter de Waal" at Nov 14, 94 7:24 am Mailer: Elm [revision: 70.85] Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI Hi: Factory manuals are great for this if you can get hold of one. Haynes is the next best choice. On my MR2, I have to jumper two pins in the service connecter in order to manually adjust the setting of the screw you describe and not have the computer trying to compensate against me. -- Mike Gruber From owner-diy_efi Mon Nov 14 20:03:27 1994 Received: by coulomb.eng.ohio-state.edu (920330.SGI/920502.SGI) id AA29537; Mon, 14 Nov 94 20:03:27 GMT Received: from ece.rutgers.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 AA29531; Mon, 14 Nov 94 15:03:22 -0500 Received: by ECE.Rutgers.EDU (4.1/25-eef) id AA23527; Mon, 14 Nov 94 15:02:18 EST Date: Mon, 14 Nov 94 15:02:17 EST From: Jason Borkowsky To: DIY_EFI Subject: Questions about our design Message-Id: Sender: owner-diy_efi Precedence: bulk Reply-To: DIY_EFI A very small group of true hotrodders (ie: 2 people) are starting to construct a batch fuel injection system for a 350 Olds dual exhaust engine, and we have a few specific questions we'd like to ask about our project: 1. Since the car is dual exhaust, is there ANY advantage to using dual oxygen sensors? (If we were to use two, we would just alternate reading each sensor, as opposed to reading each sensor every cycle and taking an average). 2. Timing control. Have other DIY implemented this in a fuel control system? We want to, and our choices of doing it thus far are a DIS ignition system (bit more expensive and complicated) or the MSD timing control method (Hook a transistor and capacitor across the coil, store the energy intended for the coil in the capacitor, and then release the energy into the coil after a certain delay. This is an oversimplistic view of how it works, but is the basics of it). 3. We are also interested in the HIP9010 knock sensor controller. How can we get info on it and is anybody planning group purchasing of these chips? 4. How heavily can we depend on the oxygen sensor? Originally we were planning to use the oxygen sensor as our main source in determining the fuel needs (along with references to a MAF and MAP sensor), but it seems this may not be such a great idea. Any comments? 5. Inlet air temperature: Do we need one, or will the combination of oxygen sensor and MAF sensor be enough to take care of air temp differences? (The underlying idea we are trying to achieve is simplicity, yet cutting edge). 6. All along we have been assuming that a MAF sensor would be easier to use as opposed to speed density. Before we totally commit ourselves to MAF, does anybody have any convincing arguments as to why we should consider speed density? 7. We are gravitating towards either using the 68HC11 or 68HC16 as the microcontroller for our system. I know this might seem to processor war inducing question, but we just want an opinion if there is any reason we should use the 68HC16 or would the 68HC11 be fine? (Our system inputs are basically coolant temp, MAF, MAP, oxygen sensor, RPM, timing, and possibly a knock sensor. And as stated, the output will be a batch injection system). 8. Does a home brew system need an IAC, or is this really used for stringent emission control? (As I said, we want SIMPLE!). We appreciate any comments. (Also, I might add, we are going to use a pre-constructed 68HC11/68HC16 board to add even more simplicity). Bob I6 - the quickest way to the future (ravalent@liii.com) Jason Matter cannot be created or destroyed, nor can it be returned without a receipt (jcborkow@ece.rutgers.edu) (jcborkow@eden.rutgers.edu)