DIY_EFI Digest Saturday, August 14 1999 Volume 04 : Number 467 In this issue: FS: TEC II for six cyl DIY Injection with a PC Re: Laptop engine management system See the end of the digest for information on subscribing to the DIY_EFI or DIY_EFI-Digest mailing lists. ---------------------------------------------------------------------- Date: Fri, 13 Aug 1999 12:30:55 -0700 From: Jason_Leone@xxx.com Subject: FS: TEC II for six cyl Gents, I'm selling my Electromotive TEC II for a six cylinder, so it's a free for all. I only used it for a couple months, and I'll sell it WITH the software. Retail price is $2000 with software, but I'll sell it for $1400 or so. Comes with all the hardware (2 Bar MAP sensor, RS-232 cable, crank wheel, mag pickup, manual, ECU, coils, PAF Blend software). I'm selling it because my power output goals have changed (400hp--->300hp), but will miss the TEC II's power and tuning parameters. This is a steal, and it won't last long... Sorry for the WOB, but I'm not aware of a DIY_EFI classified section... Jason srgnt03@xxx.net http://www.electromotive-inc.com ------------------------------ Date: Fri, 13 Aug 1999 16:13:06 -0700 From: "John Dammeyer" Subject: DIY Injection with a PC Hi All, Phil has been real helpful to me so I thought I'd pass on some of my experience since I had to make many of the same choices that are itemized below. Let's start with processor. I had a price constraint and a 16 bit processor, both from tools and long term per parts cost was too expensive. In hindsight, I should have used the C167C and bought the compiler since I ended up buying the Tasking 8051 compiler anyway. The extra grief (extra time) caused by the limitations in my processor have more than eaten up the returns a cheaper processor would return. Specifically I have used the 80C592 from Philips. It has a nice T2 set of compare registers that can set and reset or toggle an output compared to the free running T2 timer. CAN bus was a requirement here for remote instrumentation. > >Can the laptop Handle it!!! >- --------------------------- Yes. With a proprietary OS that lets you control what is done with the timer tick. If you can't you will find a periodic delay due to processing on the DOS/WIN side. Timer is high priority so your encoder interrupts would be delayed. I have an electric DC motor and speed control that lets me simulate cranking all the way to 7000RPM. On the scope the signals look perfect. The engine is not so forgiving since the speed is dependent on the control system while the DC motor controller doesn't care what my MAP sensor is doing. I have a program written in Delphi that receives status messages from the igntion and displays instruments graphically on the LCD display. I click on an instrument and I get a dialog box with the injection parameters. I can change them, try them and then store them into EEROM if I like what I see. >Inputs >- ------- > >* Airflow (Analogue - Medium sample rate - 2Hz?) - Corrolates directly to >injector pulse width >* Oil temperature (Analogue - low sample rate - 30s intervals) - Too hot / >mix too lean or undercooling or indirect load sensing? >* Water temperature (Analogue - low sample rate - 30s intervals) - Too cold >/ richen fuel mix (choke) >* O2 sensor (Digital or analogue?) - Mixture adjustment >* Inlet Manifold pressure sensor (Analogue - Medium sample rate - 2Hz?) - >Engine load / adjust injector pulse width >* Crank sensor (Digital) - Gives crank position for injector timing and rpm > You need to sample the MAP sensor far more often than you think. As Phil stated in one of his notes. At the start of every injection cycle, using MAP and RPM to index a table to pull out a PW. >For the crank sensor, worst case is say 10K RPM (From Williams note). Which >equates to 166Hz. Up to this point I agree with the analysis. However I >think I only need 1 digital pulse per revolution of the crank shaft to >determine rpm and hence through knowing the firing order I can time my >squirts. This means that I only need to react to 166 pulses per second at >worst case. Since I am only getting 1 reading per rotation, Under heavy >acceleration / deceleration the timing of the squirts at low RPM would go >off as the engine approaches the end of the revolution but to offset this >I could use proportional / integral / differential stuff (Yep I studied >control theory / stability etc at Uni!) to keep my prediction of the >position of the crank accurate (hence the fuel squirt for the last cylinder >has a fair chance of being correct!). > Not even close. You have to start the engine. The change in engine speed from 0 to cranking and then again from cranking to the first firing is huge. I found when I used a 4 vane system with one unequal sized vane to determine TDC I had trouble reliably detecting TDC during cranking to idle transition. I blamed it on the high acceleration of my DC motor but reality is quite accurate here. Part of the reason was that the T2 timer on my processor is clocked by the 16Mhz/12/8 resulting in a 6uSec tick. The 16 bit T2 counter overflows when engine RPM is less than 225RPM. (My life would have been easier if I had an extra divide by 4 available for the clock.) Because I was interested in knowing absolutely where the engine was I had my disk on the CAM shaft. Now we are talking 225 CAM RPM 550 ENGINE RPM . Four slots and vanes divide this by 8 and keep the timer from overflowing since most events are derived from one of the edges. But, it doesn't help with the initial start which is why I think Phil was so insistant on basing everything on the edges. I found the change in RPM from cranking to Starting to be so dramatic that I would see teh short slot and the following long vane (or visa versa) be exactly or close to exactly the same number of clock ticks in length. This was with the electric Motor. Perhaps a real engine wouldn't have had the problem. One of my other problems is that to determine the engine RPM I need to divide a constant by the number of clock ticks between edge events; this gives me an RPM that can be used as an index. Takes a long time to do a 32 divide operation on a 8051 family so I scaled the # of ticks and used a 16 bit divide. We also tried sensing gear teeth with a Hall Sensor and triggering off a missing tooth. Once again I had problems clearly keeping track of TDC. In hindsight, I would do it differently now. I'd use two sensors: one that told me TDC #1 (CAMSHAFT or Distributor) and the other that measured the RPM from the crank or a large number of teeth in the distributor. I'd use the CAM sensor to tell me where I was, and then use the Flywheel sensor to help me determine RPM based on time between teeth. As I'd know how many teeth we had I would also know where TDC of each cylinder was by counting teeth. Note that the number of teeth must be divisible by 4 to clearly mark the exact TDC point of each cyl if you are also doing Ignition. (I am). >Outputs >- ---------- >* Output to each fuel injector (Digital) > >At worst the engine will rev at 10K requiring 8 x 166 = 1328 pulses per >second. However since anything above 3.5K RPM results in the injectors >struggling to keep up with this rate of pulsing then above this I could >start firing injectors in banks, ie fire 2 together up to 5K RPM then fire >4 together up to 7K RPM then above this just leave all 8 open to get as >much fuel in the engine as possible? This makes the worst case for >injexctor output at 3.5K RPM which would be equal to 3500/60 * 8 = 466Hz. >If I need to be able to control at 1 msec intervals then I would need to be >able to output at 1KHz. I think I will require clever electronics in order >to address 8 injectors individually or in pairs (any ideas for this)? Would >I need a system with 8 digital outputs at 1KHz each? Your timing resolution needs to be much better than 1ms. for the injector. Our Honda is idles comforably with the load of the Hovercraft Fan (Giant Computer Fan (GCF)) at 1000RPM. Pulse width once the engine is warmed up is about 1.0ms and at 1500 RPM about 1.25ms. At WOT driving the FAN with all available torque the PW is only 8.25ms. > >If I was to control the ignition timing electronically, it would probably >be using a control to advance and retard the timing using a servo based on >readings for load / rpm and engine acceleration rather than trying to >calculate each pulse directly. If I had to calculate exactly then it would >require very accurate position sensing of the crank. Let me know any >thought on this? For starters though, it will be a standard distributer >setup using vacuum for retard. If you can avoid developing and testing ignition at the same time as injection then do it. Beats doing it at the same time. I was fortunate. We had an engine on the Dyno that used an Allison Throttle Body Carb (aircraft) and I debugged the ignition first. > >To summise, I think it is possible to control all the basics for an engine >management system using a laptop without reaching any sampling limitations. >This means that it is not neccessary to use any external processing >capability. The processor is fast enough but the DOS/WIN clock will interfere with engine management. you need A/D for the analog signals. An external box into the serial port may not deliver the MAP sensor value in time. If you use a PCMCIA A/D board you can access that hardware directly. To give you another idea of the problems. I still have a latency issue that I have yet to resolve. I think it's in how I'm handling my sensors but I can be idling and push the throttle to the firewall and I get a short stumble and rattle before the engine controller catches the change in MAP and Throttle Position and injects a big enough burst. Once it catches though, the GCF is up to maxium speed in seconds. Quite impressive. Regards, John ------------------------------ Date: Fri, 13 Aug 1999 20:31:45 -0400 From: Chris Conlon Subject: Re: Laptop engine management system >...What I will try to do is get the basics of a system developed then I >will open source my code (C++) for all to use and develop if interested. >This will help me to achieve what I want and also aid others. I'm going to >try and base it on a standard analogue and digital sampling / control >interface for a PC so that nothing is unique unless it has to be. Let me say up front that I'm not trying to be negative, I think this idea is well worth pursuing. (Like everyone else here I'm doing my own engine control stuff too.) I'm just trying to get a clear picture of why you're making certain choices. The first thing I would ask is why do you say you want to do this with a PC/laptop? What benefit is it you're after? Not that there are none, just that it may help us understand the constraints of your design. It doesn't sound like you're aiming for any specific OS. Are you looking for a system with easy SW development tools? Generic hardware? Do you want a nice little display that can ride in the dashboard or passenger seat? Is it primarily an educational/instructional exercise? Would you specifically like to (or like to avoid!) building any part of the hardware yourself? Understanding what it is you're hoping to get by using a laptop instead of an embedded uC will help us make better suggestions (imho). Beyond that I have only a few relatively useless words. For the engine management per se, any OS beyond an RTOS is basically useless, except as a dev/boot platform. You gonna do a lot of disk io/network io/memory mapping/UI graphics while driving? You already have to wire all your code into core; can you imagine what happens the first time you get a page fault while driving? ;) (Now your data logging, mapping and adjustment software is a different story of course.) You probably *could* use a full-size OS, if you can lock out other interrupts, but what is it *gaining* you? Again, understanding this will help. Ignition timing is by far the toughest (time-wise) and perhaps the most critical. Injector timing is not too hard by comparison. All else is a cakewalk. So consider hardware support for the tough parts, which could be built-in timer channels in an embedded controller, or add-ons to a generic PC. The hardware in one lousy little 68hc11 will make up for so much brute cpu power required to do the same things in software via ints and a generic timer. If you go with a big OS (non-RTOS), and don't have hardware support for certain things, you *will* be writing device drivers, and (in the case of ignition timing) you *will* be having latency problems. Even at a lowly 8000 RPM, every 20usec is one crank degree. If your OS thought it was doing anything important come spark time, uhhh that's how many degrees of retard again? "Oops". One of the main things an RTOS guarantees you that a big OS does not is an absolute max (OS-imposed) interrupt latency, for just this reason. My personal opinion is that the mechanics of how I manage the spark and injector timing are a lot less interesting than how I calculate what those values should be (maps, formulas), and how you condition the sensor values. Perhaps you could have a somewhat modular design, where there is a "black box" which deals with the cam sensor, injectors and spark. It provides info on RPM, delta RPM, misfire, whatever. You feed it info on spark advance, injector timing and pulse width. (Maybe this box also handles MAP/MAF/AFM input too; IMHO the filtering on MAP is important and sometimes tricky.) Pretty much all the other sensors are less high-speed and thus your "higher level" control code could deal with them in a less real-time-critical way. Ideally you would update spark & injector timing once every rev, or once per spark, but even that is a lot less demanding time-wise than taking interrupts to fire sparks and turn injectors on and off. Data flow to and from this box would be easily handled by the bidirectional parallel port common on PCs, USB, or marginally so by a high speed serial line. As an aside, someone said A/D parts are slow. A/D parts are not slow, they're as fast as you can afford, up to and including sample rates in the hundreds of megahertz. Sub-5-usec is not hard to get, and if you use many singles instead of a big mux-ed part, you can almost always pipeline the reads, so the effective conversion time = 0. Ok, that's my BS quota for the month. Hope it helped. Chris ------------------------------ End of DIY_EFI Digest V4 #467 ***************************** To subscribe to DIY_EFI-Digest, send the command: subscribe diy_efi-digest in the body of a message to "Majordomo@xxx. A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace "diy_efi-digest" in the command above with "diy_efi".