DIY_EFI Digest Tuesday, August 3 1999 Volume 04 : Number 447 In this issue: Re: From Cranking to Idle.DIY_EFI Digest V4 #443 RE: ECU7 and diy-efi development RE: Ecu 6 See the end of the digest for information on subscribing to the DIY_EFI or DIY_EFI-Digest mailing lists. ---------------------------------------------------------------------- Date: Wed, 04 Aug 1999 03:28:28 +1000 From: Phil Lamovie Subject: Re: From Cranking to Idle.DIY_EFI Digest V4 #443 Hi All, The problem of Injection timing at cranking is one of engine requirements. The problem is not as it seems. The engine doesn't run on petrol it runs on vapor. When the engine is cold very little vaporization takes place in the cold air stream. In fact the only physics available to aid us is low pressure. Thus the time to inject is during the exhaust stroke. This allows maximum time for latent heat absorption and thus vaporization and allows for a vacuum build up during intake as long a you can convince the customer to keep their foot of the acc. pedal. You will need approx. 300% excess fuel to start the engine. This is due to the partial vaporization of the fuel. A cranking engine often has HC components in the exhaust of 50-60% raw fuel. Don't assume that the compression of the air will supply sufficient heat as the pressure builds up very late in the piece. And the dwell time at that temp is only a few ms. Worse still if you get the A/F wrong you have just chilled your combustion chamber with a dose of raw fuel. Makes it important to really over fuel. Try and imagine the volume of fuel from a Holley double pumper in the two or three squirts that are applied before cranking. 20 - 40 cc !!! Then check to see your 5 ms injection volume. Say grams/ms/injector GMS 0.03x5x8= 1.2 40cc=22 gms approx. You're working in grams and Holley in gallons. You can either multiple fire the injectors by dropping the input divisor or simply have a table with very big numbers. You may still run out of pulse width if your injectors are too small. (See Toyota for several hundred million examples) they still fit cold start injectors in place with very low winter temps. The aim of the game is to use the smallest injector possible that fulfills the requirements. Often 85% duty cycle is the target. that is of course 85% of 720 Deg. or 612 Deg. Due to the acc of the engine 0 to 600 in 1 to 1.5 seconds the pulses must be linked to the crank. This will ensure that there are no missed pulses. This also means that the crank trigger event must result in an injection event even if the output buffer has not been updated with a sensible rpm measurement and thus in fact the ecu may not know how fast the engine is tuning. Most manufacturers use a cranking table that cuts out at say 350 rpm. Below that each trigger pulse is greeted with the same ms injector output regardless of vacuum.. If you hard link the events then it doesn't matter how fast the acc of the engine really is. If the fueling is wrong it will simply acc more slowly. The clue is to use the micro to set up a timer/off event from the instigation of injection. Your electric motor should not be able to unsync a magnetic trigger firing a gate on a transistor. Though it would confound the heck out of an input capture rpm reading as it is using clock events to determine rpm. During cranking it would be very late in it's determination. By the time it has worked out the rpm it could be 200% wrong in its phasing as the engine speed could more than double on a 1/4 revolution. Hope this cures some headaches and creates many others. Regards Phil Lamovie injec@xxx.au cogito ergo zoom Injec Racing Developments Director of Engineering ------------------------------ Date: Tue, 3 Aug 1999 10:42:51 -0700 From: "Al Lipper" Subject: RE: ECU7 and diy-efi development Chris, I will try to answer some of your questions here. > -----Original Message----- > From: Chris Caloto [mailto:caloto@xxx.edu] > Sent: Tuesday, August 03, 1999 9:00 AM > To: Al Lipper > Subject: ECU7 and diy-efi -> thanks for your reply > > > Hi Al. > > Got your e-mail reply. Thanks. > > >What makes it unique is that it's a real-time > >based system using multiple inputs, and especially, that it > "learns." The > >learning is a tricky problem which can be approached in a number of ways. > > This sounds really good. That's the first thing I noticed about the > ECU6/ECU7 projects when I looked at the web pages -> that they can > self-calibrate themselves to whatever engines they are put on. > Do they build\modify their own fuel map ? They start with a pretty crude map which lets the engine run extremely rich. The idea is that the engine will at least run if it's too rich (and have time to warm up), but if it's cold, it won't even start. Then, it checks to see if the EGO (Exhaust Gas Oxygen) sensor is giving what appears to be valid feedback. Next, it starts the steady_state timer to determine if the engine has not had major MAP or RPM variations for a certain period of time. If it has indeed been steady, then it decreases PW (injector pulse width) one step at a time (CL_STEP). As long as the engine state is steady, it will do this every few seconds (based on EGO_DELAY) until the EGO sensor indicates it is in a stochiometric range and then learn the value. Otherwise, until a variation occurs in which case it will back off one step and learn that value before moving on to the table cell for the current inputs. This is a simplified description, but should give you the general idea. Note that TICK15 is a timer that increments every 15ms - its value is converted to seconds and used for general timing purposes (like the EGO timer). > This could be a really good computer science master's thesis project. > I downloaded all the ECU6 files and was looking through them to > try to identify your learing algorithms. I see it's making use of > learning tables (stored at appropriate address spaces in the memory.) > Can you e-mail some info so I can understand the software better - > like a software module map that shows the software components and > how they interact / their purposes. > Or maybe you don't have that. Just anything you have to speed > up my learning curve as I try to pick apart the ECU6 code. I'll see what I can dig up. If I don't get you what you need soon, feel free to remind me :) > I assume it doesn't matter which one I work on - ECU6 or ECU7 - > they're pretty much the same, right ? > Yes, they are very similar. ECU7 improves over ECU6 in that it uses a currently manufactured CPU (Intel stopped making the 80C51GB about 8 months ago, but you can probably still order them from distributor stock. ECU7 supports 4 independent sets of injectors (ECU6 does 2). ECU7 uses a 5-volt flash memory instead of the 12-volt one on ECU6. ECU7 has much better protection from noise, spikes, etc. than ECU6 (ECU6 may have a tough time in electrically noisy cars, or those with voltage fluctuations). Otherwise, they are the same. > For this to work as my thesis project I have to come up with some > significant improvements to your learning algorithm. > Did you come up with it yourself - or is your implementation based upon > somebody else's work ? If so, please give me the reference(s) so I > can go read up on it. > Are there some shortcomings to the learning algorithm > in it's current implementation that you would like me to > fix / improve ? This would be great. The algorithms are entirely original. But please note, I have a minimal background in control systems theory, and they could no doubt be greatly improved or re-written. The current algorithm works as long as the vehicle is warm and there are a minimum number of abrupt throttle movements. It also tends to enter a nasty oscillation at idle, where there are many zero crossings (reaching stoich) of the EGO sensor (ultimately stalling the engine). > > A second issue is that I must have some way > of testing the new learning algorithm to show that it really > does perform better than the old one. Ideally I would build the > circuit and implement it on a vehicle(s) and it would run superbly > and I would collect performance date to document it - > but that is TOO big a project for me right now - although I think > it would be great fun and it is something I would like to do - > I have to remind myself I am not superman and I have limited > time and resources. > > So is there some way to create an artificial test environment for > the learning algorithm to evaluate it / test it ? > Have you done anything comparable when you were developing > ECU6 ? (or any prior versions - I assume there was an ECU4 and ECU5 ?) Yes, there were many versions (the first was the PC-based EFI system on the DIY_EFI site - it was a bit clunky with a PC in the back seat, but it ran!) For development of ECU6, I used a "vehicle simulator." Basically, a box with variable resistors for each of the analog inputs (Temp., TPS, EGO and MAP), each with a calibrated dial. Then, there were switches/pushbuttons for digital inputs. The RPM signal was generated using a function generator which I connected a digital tach to in order to accurately monitor its "RPM." I used a relay as an inductive load for the injector output, just so I could hear it buzzing when things worked right. You can also use LEDs for other outputs. The setup works very well - better than a car even. Too bad you can't drive the thing :) What I mean is you're creating an ideal situation with it, and a real engine is far from ideal and has fluctuations which are not detected by the system's inputs. The simulator is extremely helpful in setting things up and debugging, but really needs to be used with the actual installation to guarantee it works. For example, the learning rountines worked great on the sim., but in the actual vehicle, I ran into that idle fluctuation problem. Basically, you need both. Surprisingly, getting it to work on a car is not nearly as tough as it seems. I got it installed on a 57 corvette (including putting in the fuel pump, and all the wiring) in about 2 days. And, it ran without too much work! While it seems like there's so much data that comes from a car, I've actually found ways to deal with it all. In the beginning of ECU6.BAS, you see all of the PRINT statements. These are status reports. I plug an old laptop in and simply capture all of the data while the car is running under different conditions. Then, I take the saved file, import it into Excel and examine it. For example, lets say RPMs fluctuate and the engine dies going up a hill. Start the data capture, drive up the hill and let it stall. Then, going back through the data will prehaps reveal a pattern of high MAP and excessively lean mixture, leading to an attempt at compensation by the learning rountine. You go home and simulate the inputs on the simulator, duplicate the problem, and ultimately see that the compensation is too extreme. Or something like that. Anyway, that's the general idea. > > So this diy_efi stuff definitely has potential. > I am interested in working on the learning algorithm. > My two main concerns are > 1) Are there problems / inadequacies in the current learning > algorithm so that I could come up with SIGNIFICANT improvements ? Yes, there is room for significant improvements in the learning algorithm. I have done very little research into control algorithms, but there is certainly a lot out there. > 2) Is there a way to test my new software implementation ? > This is very important but could be a sticking point, because > as you pointed out the system is real time and uses multiple inputs. > But testing \ evaluation is critical for my thesis. > I wouldn't mind working on and developing testing software. > In fact, that could be a thesis project on it's own ... You need an ECU6 or ECU7 board to work with. Once you get the parts, the ECU6 board takes about 3 hours to put together (if you're reasonably good with PC boards). Through some major miracle, mine worked the first time (though I'm skeptical about ever experiencing this again :) If you do some decent work on the software, I'd be happy to attach your name to the copyright and include you if it ever turns into a marketable item. > > > >From the EE perspective, there's the hardware of ECU7. > >What about taking the circuit and getting it to actually work > >on a vehicle? > > I would love to work on that, but I've got to be realistic. > Right now I can't do it. It's too big a project for me. > I'd need to go buy another car (I'm fairly confident I could > get a suitable rust bucket for a few hundred dollars) > because if I try getting this to work on my > current car (a 1982 carburated Mazda RX-7) I will be without > transportation until I get it to work. I live in Tampa Bay, > Florida and the public transportation system sucks so this is > not an option. > I also don't have a large dedicated work area. > Must have a good work area. > If you just want to do the simulator part and don't have a vehicle to try it on yourself, I might be able to work something out where you could do the software development, and I would test new code on a vehicle, then e-mail you results, etc. I've done similar things before and it has worked out pretty well. > >You didn't mention if your EE program requires a > >thesis or senior project ... > > It does, but I've already got some stuff lined up. > Of course, I could end up doing something diy_efi related, > but the senior project needs to be a SMALL, compact > project. > > > >If you are > >interested in pursuing this further, let me know and I'd be happy to give > >you plenty of additional info on the hardware, software and application. > > Yes, please send me anything you have that will help me > understand the software, especially in regards to the learning > algorithm. > > Also, a file contents listing would be handy -> when I unzipped > the ECU6 zip file it contained a Software directory with 23 files. > Some it's obvious what they are, others not so obvious. > A listing of file names and what their purpose is would be good to > have. If such a thing is already in the zip package what is its > file name ? I didn't find such a listing. > I'll see what I can dig up for this. Are there particular files you need to know about? > Looking forward to hearing from you, > - Chris. > > > Here's the full text of the e-mail you sent me: > At 7/29/99 3:33:00 PM, you wrote: > Chris, > It's great to hear of your interest in EFI stuff. > Actually, there are a > number of aspects of the EFI projects that lend themselves to > master's-level thesis work. On the computer science end of things, there > is the programming of ECU7. What makes it unique is that it's a real-time > based system using multiple inputs, and especially, that it "learns." The > learning is a tricky problem which can be approached in a number of ways. > >From the EE perspective, there's the hardware of ECU7. While > the design on > this is apparently complete, we have yet to build and test one - that is, > it looks good on paper, but will no doubt need plenty of work once > constructed. What about taking the circuit and getting it to > actually work > on a vehicle? The combination of programming and hardware might work well > for your requirements. You didn't mention if your EE program requires a > thesis or senior project, but if so, you may be able to kill 2 birds with > one stone. In any case, congratulations on being almost done. If you are > interested in pursuing this further, let me know and I'd be happy to give > you plenty of additional info on the hardware, software and application. > > Al > > > > > > ------------------------------ Date: Tue, 3 Aug 1999 10:43:01 -0700 From: "Al Lipper" Subject: RE: Ecu 6 Yes. I have a few left. If you want one C.O.D., give me your address. Or, if you would prefer, let me know, and I'll give you my address to send a check to (that way no one needs to be around to receive it, and you don't need to pay C.O.D.). The main code is stored in flash memory and can be re-programmed easily to control just about anything from a toaster to a turbo. See the ECU6.ZIP file for details on all this. Al Al Lipper efi@xxx.org - -----Original Message----- From: RSRACE@xxx.com] Sent: Tuesday, August 03, 1999 8:19 AM To: efi@xxx.org Subject: Ecu 6 I saw an e mail saying you had some of the ECU 6 boards left. You also said they were $37 each plus shipping. Could you tell me how to get one shipped to me. Would C.O.D. be best. You could ship it to our shop that way someone is always there with the money order. Just let me know I'm pretty interested in it. Also can the code be changed to do other things such as a wastegate control and such. I'm in Maryland. Thanks Tom Ross ------------------------------ End of DIY_EFI Digest V4 #447 ***************************** 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".