DIY_EFI Digest Friday, August 13 1999 Volume 04 : Number 466 In this issue: Fw: [JP] O2 sensor for 350 TBI Re: DIY_EFI Digest V4 #465 Designing Engine Management MasterTune 9V power supply Dis and advance 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 07:07:59 -0700 From: "Michael Selig" Subject: Fw: [JP] O2 sensor for 350 TBI - ----- Original Message ----- From: Larry Maggio To: Sent: Thursday, August 12, 1999 10:08 PM Subject: [JP] O2 sensor for 350 TBI "Larry Maggio" writes: Those of you who have the sensor after the y-pipe... are you sure the engine is staying (or getting) into closed loop? The o2 must get to 600 degrees before the computer goes into closed loop operation. Im wondering if it doesnt fall in and out of closed loop during different driving types such as stop and go traffic.... especially during cold weather. Any thoughts or am I high? LarryM ===> JeepTech List Message End <======================================== Subscription changes: http://www.off-road.com/4x4web/jeep/jeeplists.htm Sponsored by Off-Road.com's JeepWeb http://www.off-road.com/4x4web/jeep ------------------------------ Date: Fri, 13 Aug 1999 09:11:15 -0400 (EDT) From: Pat Ford Subject: Re: DIY_EFI Digest V4 #465 Previously, you (DIY_EFI Digest) wrote: > > DIY_EFI Digest Friday, August 13 1999 Volume 04 : Number 465 > > > > In this issue: > > Re: DIY_EFI Digest V4 #464 > New Project - 514 > 9V power supply > Signetics N82S2708N > Re: DIY_EFI Digest V4 #462 > > See the end of the digest for information on subscribing to the > DIY_EFI or DIY_EFI-Digest mailing lists. > > ---------------------------------------------------------------------- > > Date: Thu, 12 Aug 1999 16:43:20 -0400 (EDT) > From: William T Wilson > Subject: Re: DIY_EFI Digest V4 #464 > > I hate digest mode. > > Somebody please fix it. :} > > > The most common pitfalls are not coming to terms with writing "real > > time" applications and how very "real time" the engine management > > game is. > > Something that is extremely lacking - not just in engine management but in > many technology applications - is people actually quantifying what they > want the stuff to do. the missing spec stage. You have to specify what you want before you get going > > 10,000 RPM is equal to 166 RPS. Since you have one pulse for every other > revolution for each cylinder (assume 4) you'll have 4 * 166 / 2 = 332 > pulses per second. Now, that doesn't seem all that bad, but consider all > the stuff that has to be done for that pulse and how precise it has to be. > It's easy enough for a computer to do 332 things per second but for it to > do one thing precisely every 3 msec is a little different. The hardware needs to run that fast, Not the program. Al Lipper did a PC based efi, I used that as a starting point for a pc104 (industrial pc) based efi. Using a 386ex 16 with 8M ram it worked. Think and look and Ludis's page ( http://www.cruzers.com/~ludis/1227748sheet1.gif ) and look at u15 you just program the capture channels and read the registers th cpu only sets it up then sets back and reads at will . > > First you must sense the current RPM. You can't do this in the same > thread that does anything else because by the time you get the RPM sensed > you'll have missed a pulse. If you have 6 teeth with one missing on your > sensor widget (that's a technical term) you'll be getting 50,000 pulses a > second, which means you need resolution of 100,000 pulses a second (so you > can find the missed one) which means you need additional hardware to help > with this, *already* your laptop is by itself inadequate. not so if you hook into the 8253/4 timer chip your code only has to set it up. Software and hardware guys tend to try what they know, this is something to do in hardware. > > Assuming you have a unit which sends you a 16-bit value (adequate for any > RPM) 10,000 times a second. You need to read your serial port at a bit > rate of 19,200 bps just to make 9600 RPM max. 38,400 if you want to be > safe. The good news is that if you miss one of these it's not the end of > the world. > > Then you need to send the injection pulse. First you need 3msec timer > accuracy. The hardware clock can do that, but if your system is too > heavily loaded, you'll lose out. This is where Windows really falls over; > it's simply not that precise. Most of the time Windows can't even play > mp3's and run Netscape at the same time without cutting out even though > the total cpu load is less than 25%. again easy in hardware to avoid this overhead, Al Lippers PC based efi is an excellent starting point. He made good h/w vs. s/w choices. SNIP > Somewhere in there you have to find time to check the TPS, correlate it > with the RPM and boost level (if applicable) and find out how much fuel > you're going to squirt for the next pulse. If you are running closed loop > you'll have to check the value of the O2 sensor... oh, bad news. A/D > converters are slow - so you can't do that read instantaneously. But you > need to know this ahead of time because otherwise you don't want to go > lean accidentally. sample the analog signals at the start, then do it after each read > > Any of this stuff is easy enough to do, but getting all the scheduling > right is the hard part. > not if the right decisions are made about whats h/w and whats s/w tasks > > On the Engine Management side things are a lot more difficult. > > You can get a good handle on things just by connecting an A/F meter to see > how much fuel is being pushed in at various RPM's. You can then simply > capture this data for a good starting point. > > > Let us know what you find out ? Can a 300mHz 32 bit wintel run an > > engine ? > > No chance. Windows cannot do this. AGREED windows is a nice TOY ( try reading from an empty floppy drive while doing anything else) > Linux probably can if you are > comfortable with programming for real time applications, but you would > probably be safest with a genuine real-time OS, which of course is a very > specialized skill and probably expensive for the software. There are free rtos's but with dos you can set up a fairly good system for this type of load just don't run any windows stuff, avoid himem.sys ... Or you can go OS less. Compile your program as a .com and patch the bios signature and jump to the front and the post will take and run it before any os starts > > You kind of reach a point of diminishing returns with PC hardware. The > CPUs today are designed for computationally intensive applications which > engine management is certainly not. Your real bottleneck is the I/O, > most PC systems are very poor at this and it's the most important part of > engine management. > I agree to a point, the stock io is poor BUT its easy to extend the io. Think of a pc as the small block chev of computers, easy to add stuff to, lot of off the shelf stuff, not hard to graft home made stuff to. One of QNX's customers does engine management on a turbine engine test bed( like a dyno) , using a PC. - -- Pat Ford email: pford@xxx.com QNX Software Systems, Ltd. WWW: http://www.qnx.com (613) 591-0931 (voice) mail: 175 Terrence Matthews (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8 ------------------------------ Date: Fri, 13 Aug 1999 16:22:51 +0100 From: JMACKENZ@xxx.com Subject: Designing Engine Management Hi Phil / William & other readers, Sorry for this long note.... "Seems like everyone is designing an engine management system today ! " ...But are any of them sucessful and if so where's the public domain source? "It would be great if some of you would get together and pick a common platform. Makes it much easier to help a group of you and the open source nature should help you attract others." ...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. I'm doing this for a long term interest and hobby and that rush of adrenalin I'll get when an engine actually drives and is managed reasonably well (until the computer crashes!) "It's probably best to spend your first year or so investigating engine design issues then you will be in a position to asses current technology and methodology of engine management." ...I'm not rushing into it head first. I know a bit but I'm looking for a book which describes everything as a starter. "The care and feeding of an engine is a technology neutral issue. You can't design a carby without having a reasonable grasp of the physics of IC engines and the chemistry of combustion." ...With the mechanical engine stuff I should be OK to start with. Initially I'm not designing the engine, simply using something which I know works with the management system it came with. "Same goes for writing code for an embedded engine management application." ...This is where the challenge lies for me. I'd like to design it so that it is capable of being compatible with existing fuel maps. Can the laptop Handle it!!! - --------------------------- As regards the stuff about can a Laptop handle it...I dunno yet but I think so. This for me is is the interesting bit because I don't know anyone that's done it before. This is where I need real help as I am trying to figure out exactly what analogue and digital inputs / outputs are needed so I can ensure that what I choose in terms of hardware is more than adequate. I can guarantee that I am not even looking at in 95 / 98 / NT or any varient of that nasty unreliable stuff because the 'Blue screen of death' probably would kill a high reving engine! I will consider OS/2 as I have worked with it for years and it is one of the few true multitasking OS's and is extremely reliable but my heart tells me to go with Linux as it seems to be very flexible and extremely fast and free (and fashionable). (Unless Microsoft want to sponsor anything?) Even with the most powerful operating system running on the most powerful laptop with the fastest interfaces (USB / firewire?) to the DAC / ADC / driver circuits I may still be limited. However I don't think I will be as based on a 10K RPM engine I need the following sensors initially for basic control of fuel injection (using mechanical ignition timing). Please correct me if I've screwed up and am way out but these are my initial calculations; 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 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!). 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? 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. 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. Best Regards James MacKenzie ------------------------------ Date: Fri, 13 Aug 1999 12:46:05 EDT From: Mikepoore@xxx.com Subject: MasterTune I called the makers of Mastertune today and found out that they quit selling the software. I never saw the software, but it sounded like a useful product. Does anyone have a copy they would like to sell? If it worked, it would save me a lot of time. Mike Poore ------------------------------ Date: Fri, 13 Aug 1999 08:27:11 -0400 From: "Peter D. Hipson" Subject: 9V power supply Be careful, many LCD meters cannot have a common ground with the voltage being measured. You probably will have to either buy or make an isolator (they are nto that expensive). Otherwise just use a 7809 regulator, with a small by-pass cap on the output. The resistor and diode trick requires a 9V zener diode and a dropping resistor, and is rather inefficient to boot! At 05:00 8/13/99 -0400, you wrote: >------------------------------ > >Date: Thu, 12 Aug 1999 21:50:04 -0500 >From: Tom Sharpe >Subject: 9V power supply > >I need 2 mv @xxx. My radioshak book says I can do >it with a resistor and diode. Can any EEs out there give me values or part >numbers??? TIA Tom > >------------------------------ Thanks, Peter Hipson (founder, NEHOG) 1995 White NA Hummer Wagon ------------------------------ Date: Fri, 13 Aug 1999 14:16:30 -0400 (EDT) From: Pat Ford Subject: Dis and advance Hi All: I was thinking (rare but does happen) what does the signal from the dis module to the computer look like and what the the computer send back as an advance signal. What I'd like to do is make a small advance box that I can put a simple advance curve into and have it control the advance. Thanks - -- Pat Ford email: pford@xxx.com QNX Software Systems, Ltd. WWW: http://www.qnx.com (613) 591-0931 (voice) mail: 175 Terrence Matthews (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8 ------------------------------ End of DIY_EFI Digest V4 #466 ***************************** 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".