DIY_EFI Digest Friday, March 31 2000 Volume 05 : Number 131 In this issue: Re: Custom PCM & Injectors Questions A-B Encoder software Re: Looking for pulse output MAF Re: A-B Encoder software Re:Aftermarket ECU & RT OS Re: aftermarket ecu etc... 4 Bar Map Sensor Re: Aftermarket ECU & RT OS data logger files - software to read them Re: data logger files - software to read them RE: Looking for pulse output MAF RE: Looking for pulse output MAF Re: data logger files - software to read them Re: 8051 Code VR Sensor See the end of the digest for information on subscribing to the DIY_EFI or DIY_EFI-Digest mailing lists. ---------------------------------------------------------------------- Date: Thu, 30 Mar 2000 08:13:17 -0500 From: "nacelp" Subject: Re: Custom PCM & Injectors Questions Well, I only have slight info., that may help ya here. > This computer was custom programmed by a company in AZ by the > name of Z-Industries (I believe) for an owner of a Ram SS/T > 360 with a Paxton SuperCharger and N2O. The goal was to increase > performance for the 1/4-mi. track. The first computer sent to him > with the custom program was erroneously put on a Dakota computer. > At the time, he was told it was for a '97 and, hence, my interest > and one of the main reasons for buying it. (MP has never put out > a hi-po PCM for the '97s). The '96 and '97 Dakotas are both OBD-II > compliant but went through a major exterior design as well as major > differences in how sensor outputs reach the dash gauges. Z-Industries last I knew was in Orange CA. I haven't had anything good to say about them, after my experiences there. AZ has AZ Speed + Marine, read about their Carprom deal, and you'll share my feeling toward them also. They want you to play a bunch of money and then tell them where the tables are. > I do not have the technical specs of the custom program but > I was told that it was calibrated to run with 30# injectors, > calibrated for 160F coolant thermostat (stock is 195F with > most performance Daks running 180F tstat), all delays were > removed to give instantaneous throttle response, rpm and > speed limiters were raised, tranny shift rpm points were raised, > idle rpm raised, prevent detonation for 10lb supercharger boost > and 150hp N2O shot, etc. No less then 180, and if the chip is right then 190. Lots of chips folks just use the coolant temp correction, as a way to richen up the mixture. Brillance at it worst....... > While my surface knowledge of efi is enough to tell me that > running this PCM on my vehicle is a gamble, I took the chance > and am taking the time to put it through careful road tests with > a scanner. Sounds like you have the right idea. BTW, FWIW, there is tuning.doc at the FTP, just might help ya a little. > At idle, scanner outputs show that timing has been advanced more > than the MP hi-po PCM and pulse width of 19# injectors is shorter > than with the MP PCM (I'm looking to see if the scanner can > output duty cycle data). In closed loop, the o2 sensor is doing > its job bouncing readout of rich and lean with longer stays at > rich. At WOT (open loop) and initial startup, it shows rich. > As previously stated, under sudden WOT at any rpm, there is a > sustained 'bogging' with the 24# injectors, and hence the return > to the 19s. Gradual changes in throttle position does not > cause this problem. AE, is too rich with the bigger injectors. Yep, smaller ones, and can you adjust the fuel pressure?. > My questions were more of a general nature since I do not have > any tech specs of the custom program. It seemed to me that, if > a program is calibrated for 30# injectors, pulse width would be > different than a program calibrated for 19# (or 24#) injectors > as well as duty cycles (???) I have complete zero knowledge on > delays. Your correct in you assumptions. The delay things generally allow th eengine to get on the cam, or rpm high enough for Power Enrichment, part of your bog, might be having eliminated the delay. > I've tried accessing the archives to see if there is anything > in these subject areas (does not have to be specific vehicle > related) but have been unable to access them lately. Not much Mopar stuff there, the is a zipped archive you can down load. > If there are any sites in which I can get a little deeper knowledge > into engine/fuel management, I would appreciate any references. Rading the archives, is about as good as it gets. Specially for refering to Books, etc. Grumpy > > Thanks for taking the time to reply. > > Bob > -------------------------------------------------------------------------- - -- > To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) > in the body of a message (not the subject) to majordomo@xxx.org > - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Thu, 30 Mar 2000 13:56:04 +0000 From: Mike Blakey Subject: A-B Encoder software I'm looking for some pseudo code for a A-B encoder. I want to use this type of encoder instead of a 10K pot/ ADC input for TPS. Does anyone have any code for incrementing and decrementing a file/register using this type of device? - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Thu, 30 Mar 2000 08:39:01 -0500 From: Keith Mezzina Subject: Re: Looking for pulse output MAF I have a Bosch hot-wire unit from a GM TPI setup if anyone needs it. It's a used part but worked just fine. Yours for the cost of shipping. Numbers on the part are: 0280 213 004 14 094 712 On Tue, 28 Mar 2000 20:53:55 -0600, "Brian Franchuk" wrote: >Hi, > >I'm looking for a GM MAF (pulse output) that can handle the flow >from a 4.0 liter motor (approx 220hp). I've already built the pulse to >AFM conversion box so I need to use a pulsed sensor. The sensor >I've got now (I got it from the U-pull-R yard out of a 2.8l chevy) can't >handle the flow rate. Any help is appreciated. > >Brian > >---------------------------------------------------------------------------- >To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) >in the body of a message (not the subject) to majordomo@xxx.org - - - - - - - 1973 Dodge Challenger (340/727/3.91SG/NOS) 13.01 @xxx.2 @ 112 (NOS) 1985 Z-28 Backhalf Race car (356/TH400/5.56) 1977 Suburban (Daily Beater) Homepage: http://www.checkmateracing.com - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Thu, 30 Mar 2000 09:27:00 -0500 From: "John S. Gwynne" Subject: Re: A-B Encoder software In message <"000330130005Z.WT24777. 10*/PN=Mike.Blakey/OU=Personnel/OU=NOTES /O=BAe MAA/PRMD=BAE/ADMD=GOLD 400/C=GB/"@MHS>, you write: | I'm looking for some pseudo code for a A-B encoder. I want to use this type o | f | encoder instead of a 10K pot/ ADC input for TPS. | Does anyone have any code for incrementing and decrementing a file/register u | sing | this type of device? for what it's worth, the 68332's TPU does this function. The TPU does linear increment/decrement without cpu intervention. I have some code to do non-linear based on rotation speed that does require a little cpu intervention. I've used them for strobe-light control and in my injector test bench. john gwynne - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Thu, 30 Mar 2000 09:30:09 -0500 (EST) From: Pat Ford Subject: Re:Aftermarket ECU & RT OS Get a cheap used laptop, and use that as your starting point, then chose os's. I did that, and made a digital dash as well. Previously, you (DIY_EFI Digest) wrote: { { DIY_EFI Digest Wednesday, March 29 2000 Volume 05 : Number 129 { { { { In this issue: { { Re: Aftermarket ECU & RT OS { RE: aftermarket ecu etc... { Re: aftermarket ecu etc... { Re: aftermarket ecu etc... { { Date: Wed, 29 Mar 2000 08:58:55 -0800 { From: Randall { Subject: Re: Aftermarket ECU & RT OS { { Hi Paul : { { No, but I have looked at other UNIX variants with "real time { extensions". Have you looked at QNX? { For what I do (which has nothing to do with EFI or engine { management), they are just way too slow, Hmm you didn't look at qnx! { and take too much processor. 386, 2M flash( or 1.44M floppy) 6M ram { It's possible that Linux would make sense, for a "one of a kind" { homebrew, but you'd want to see some hard figures on worst-case { interrupt latency, task switch, etc. Linux wouldn't be my choice there are priority inversion problems eg serial port driver ( running at a low priority) -> higher priority process wants to write(or read) to serial and blocks a 3rd process that has a priority somewhere between the two gets to run as it's priority is higher then the serial driver that the highest priority process is blocked on. { { Part of the issue is that "real-time" means different things to { different people. Most of the UNIX enhancements I've seen concentrate { on things like adding task priorities (which is certainly important), { but do little to address things like worst-case task switch. Whether { you can live with that depends a lot on what your requirements are. design issues the rt-linux extension runs the os(kernal) as a task and the rt stuff behind the back of the kernal, works fine UNTIL an rt task needs a kernal call, then you are back to regular linux performance { { Frankly, IMO a complex operating system always adds complexity to the { project. Or can simplify it, a true microkernal os is easier to use then setting up an mmu, task switchers... and is small ( ~34K for QNX4.25) { If you don't need that complexity (and I don't see it as being { required for engine management/EFI), protected mode programming is almost always worth the extra thought { why bother ? reliability, testing, and with QNX posix api's { To put it another { way, there's a lot to be said for the KISS (Keep It Simple, Stupid) { principle true BUT an rtos doesn't need to add complexity, if properly chosen it should sheild you from complexity { { Cheers { Randall { { Corner Paul wrote: { > { > Hi Randall { > { > Have you looked at Linux - there are Real Time patches available. I have, its almost as good as RT-NT or embedded NT ( 64Mb ram for an embedded system, yea right!) { > { > Regards, Paul { { Date: Wed, 29 Mar 2000 11:44:00 -0500 { From: dave.williams@xxx.us (Dave Williams) { Subject: RE: aftermarket ecu etc... { { - -> There is also no reason you can't "roll yer own" : use DOS (or { - -> equivalent) to load your program image into memory, then grab all the { - -> interrupts and the machine is yours. { { Tom Wagner's CTASK multitasking library for C does polled and { pre-emptive tasking under DOS. Very small, more features than you can { shake a register at, thoroughly documented and debugged, widely used, { and free. What more could you ask? cool url please? - -- Pat Ford email: pford@xxx.com QNX Software Systems, Ltd. WWW: http://www.qnx.com (613) 591-0931 (voice) mail: 175 Terence Matthews (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8 - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Wed, 29 Mar 2000 21:31:00 -0500 From: dave.williams@xxx.us (Dave Williams) Subject: Re: aftermarket ecu etc... - -> Where do I find the repository for CTASK's most recent source code? I found it on Simtel. - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Thu, 30 Mar 2000 11:46:48 -0500 From: "Flanagan, Stephen CECOM RDEC STCD" Subject: 4 Bar Map Sensor Does anyone have and info on a company that sells a 4 Bar MAP sensors. I am looking for the technical specifications of the output of 4 Bar MAP sensor vs a 3 Bar MAP sensor. Trying to lie to a DFI system and use a 3 Bar fuel Map with a 4 Bar Map sensor. Has anyone tried this? My real concern is the outputs of the sensors, what does a 3 Bar MAP sensor output and what does a 4 Bar MAP sensor output. Is it a linear voltage relative to the pressure? IF so, what is the output range of these types of sensors. 0 - 5 volts???? Thanks in advance. steve - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Fri, 31 Mar 2000 08:27:05 +1000 From: Peter Gargano Subject: Re: Aftermarket ECU & RT OS Pat Ford wrote: > { Tom Wagner's CTASK multitasking library for C does polled and > { pre-emptive tasking under DOS. Very small, more features than you can > { shake a register at, thoroughly documented and debugged, widely used, > { and free. What more could you ask? > > cool url please? Unfortunately, as is often the case with things that are free, I couldn't find a "cool" URL - I searched for the closest SIMTEL repository - In the US you could try: http://oak.oakland.edu/simcgi-bin/dosfind.cgi?ctask or directly FTP the Zipped file: in US ftp://oak.oakland.edu/pub/simtelnet/msdos/c/ctask22d.zip in OZ ftp://sunsite.anu.edu.au/pub/pc/simtelnet/msdos/c/ctask22d.zip So, no "cool" URL, but it comes with a 130 odd page "manual" AND it's totally free. And, if you're wondering, I don't know anything more about it than this! I just downloaded it myself. PG - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Thu, 30 Mar 2000 17:38:19 -0500 From: "Jason R. Haines" Subject: data logger files - software to read them I have some data files from an OE data logger (GM Tech 2). I am trying to see if it would be possible to read them with any other software. Anyone have any good ideas on what software I should try or any companies (or people) I might try sending a sample file to for them to figure out the data storage method? Regards, Jason - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Thu, 30 Mar 2000 16:50:28 -0600 (CST) From: Roger Heflin Subject: Re: data logger files - software to read them On Thu, 30 Mar 2000, Jason R. Haines wrote: > I have some data files from an OE data logger (GM Tech 2). I am trying to > see if it would be possible to read them with any other software. Anyone > have any good ideas on what software I should try or any companies (or > people) I might try sending a sample file to for them to figure out the data > storage method? > > Regards, > > Jason I don't know about a tech 2, but diacom stores that data (on disk) almost exactly how it comes off of the ALDL connector, so knowing that and the exact datastream definition for the vehicle in question you should be able to figure out most of the datastream. I suspect that the tech 2 may add a few tag bytes (time/date or something similar) on each frame, but that is probably all. No one seems to go to alot of trouble to complicate things too much, it is generally just not worth it. Roger - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Thu, 30 Mar 2000 22:13:40 -0800 From: Carl Summers Subject: RE: Looking for pulse output MAF Hi, I would like it to verify a "box" I'm making if noone else has dibs on it....I can give it away again in a couple of months if someone else needs it as well....Thanks - -Carl Summers - -----Original Message----- From: owner-diy_efi@xxx.org]On Behalf Of Keith Mezzina Sent: Thursday, March 30, 2000 5:39 AM To: diy_efi@xxx.org Subject: Re: Looking for pulse output MAF I have a Bosch hot-wire unit from a GM TPI setup if anyone needs it. It's a used part but worked just fine. Yours for the cost of shipping. Numbers on the part are: 0280 213 004 14 094 712 On Tue, 28 Mar 2000 20:53:55 -0600, "Brian Franchuk" wrote: >Hi, > >I'm looking for a GM MAF (pulse output) that can handle the flow >from a 4.0 liter motor (approx 220hp). I've already built the pulse to >AFM conversion box so I need to use a pulsed sensor. The sensor >I've got now (I got it from the U-pull-R yard out of a 2.8l chevy) can't >handle the flow rate. Any help is appreciated. > >Brian > > - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Thu, 30 Mar 2000 22:13:35 -0800 From: Carl Summers Subject: RE: Looking for pulse output MAF Hi Grumpy, I thought the "standard" was 1.3hp for each gram per second?????I could be wrong..... - -Carl Summers - -----Original Message----- From: owner-diy_efi@xxx.org]On Behalf Of nacelp Sent: Tuesday, March 28, 2000 10:54 PM To: diy_efi@xxx.org Subject: Re: Looking for pulse output MAF Ya generally need 1.3 grams/sec per HP. so you need something about 290ish grams/sec. Which is right on the middle of nowhere, of what I'm familiar with. However, using a late model v-8 MAF (3.0") should be in the right neighbor hood. ie 96 and later. I think they were up to 400 grams/sec.. Least you'd get to have too much range.. How could you build the box, without knowing the frequency range?. Grumpy Can I see the diagram?. > I'm looking for a GM MAF (pulse output) that can handle the flow > from a 4.0 liter motor (approx 220hp). I've already built the pulse to > AFM conversion box so I need to use a pulsed sensor. The sensor > I've got now (I got it from the U-pull-R yard out of a 2.8l chevy) can't > handle the flow rate. Any help is appreciated. > Brian - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Thu, 30 Mar 2000 16:50:28 -0600 (CST) From: Roger Heflin Subject: Re: data logger files - software to read them On Thu, 30 Mar 2000, Jason R. Haines wrote: > I have some data files from an OE data logger (GM Tech 2). I am trying to > see if it would be possible to read them with any other software. Anyone > have any good ideas on what software I should try or any companies (or > people) I might try sending a sample file to for them to figure out the data > storage method? > > Regards, > > Jason I don't know about a tech 2, but diacom stores that data (on disk) almost exactly how it comes off of the ALDL connector, so knowing that and the exact datastream definition for the vehicle in question you should be able to figure out most of the datastream. I suspect that the tech 2 may add a few tag bytes (time/date or something similar) on each frame, but that is probably all. No one seems to go to alot of trouble to complicate things too much, it is generally just not worth it. Roger - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Thu, 30 Mar 2000 23:45:54 PST From: "mike mager" Subject: Re: 8051 Code Greetings! I searched around for Al Grippo code and for Al Lipper code, with no result; how could I find it? Circuit Cellar I have, and that's what starterd my interest in a DIY system. Thanks, Mike >From: "John Dammeyer" >Reply-To: diy_efi@xxx.org >To: >Subject: Re: 8051 Code >Date: Wed, 29 Mar 2000 07:51:20 -0800 > > > > Date: Wed, 29 Mar 2000 12:33:12 +0100 > > From: Corner Paul > > Subject: 8051 EFI code > > > > Hi John > > > > Any chance you would like to share the algorithms or some of the source >code > > ? > > I've looked at Al Lipper's work - the core routines aren't that >different to > > what I had allready coded. > > > > Regards, Paul. > > >Hi Paul, > >Can't distribute code as I'm bound by NDA but I can talk about it a bit. I >based my code >on Al Grippo's paper along with the series of articles in Circuit Cellar >Ink. > >In other words, I used a Volumetric Efficiency table approach rather than >the MAP-RPM 2-D >table. I have parameters like Displacement, number of cylinders and >injector size along >with Fuel/air ratio to determine the baseline 100% VE fuel required on a >per stroke basis. >I guess at Vapour pressure because I don't measure RH. > >Given X amount of air in the cylinder at atmospheric pressure I then have >the amount of >fuel (F) the engine requires. The MAP divided by the Barometer forms a >ratio less than >1.0 and the VE table is in percent so the basic equation is simply (X+F) * >MAP/Barometer * >VE[RPM]. > >I have a mainline loop that continuously calculates these values along with >acceleration >and temperature enrichments and updates a global pulse width variable. The >main loop just >reports status out the CAN bus and recalculates PW based on the A/D values >which are >triggered to also update via interrupts. > >We have two HALL sensors underneath the CAM timing pulley which are >switched by 4 magnets >set at 90 degrees to each other to create a Grey Code encoder. This tells >me from the bit >pattern: 00, 01, 11, 10 which cylinder is at TDC and creates an interrupt >on each single >bit change. Notice the Grey Code only has one bit that ever changes so an >interrupt is >fairly easy to decode into a quadrant. The down side is the CAM has to >make one complete >revolution after power up before the sensors report the correct values as >they are >latching sensors where a North magnetic pole turns them on and South turns >them off and >they come up in an unknown state. It means at worst case the engine cranks >two >revolutions before starting. > >I chose the 80C592 because it has enough compare registers to assign one >per injector and >coil pair and of course comes with CAN bus. The rest of the code is just >house-keeping to >make the injectors and coils fire at the right time. I've done empirical >tests and found >that up to about 4000RPM I'm updating the PW once per injector squirt after >that I start >to lag behind but we haven't found that to be a hindrance as an unloaded >engine winds up >to redline far faster than I can pull the throttle back and a fully loaded >engine doesn't >change load on a per stroke basis. > >To tune the engine we've determined the best way is to set the dyno, (or >propeller) to >load the engine enough so that the throttle is wide open at a number of >different RPM >settings. (1500, 2000, 2500, 3000 ...). During this time we tweak the VE >table values >till the O2 sensor starts dancing around 0.5V. With a bit of extrapolating >we end up >filling in the VE table between those values (100RPM steps) and end up >with values from >about 45% up to 95%. For values less than WOT the MAP/Barometer ratio >seems to keep the >mixture fairly even. This beats filling in a > >Lookup[RPM,MAP] table with hundreds of values. > >Enrichments are done by monitoring engine temp, air temp and the TPS. > >What is really cool is that when we put in bigger injectors the only thing >we change is >the size of the injector and the engine runs with shorter pulse widths but >the mixture is >just about spot on. One other parameter that affects the low end idle and >overall mixture >is the open/close time of the injector. We guess that 66% of the rated >fuel is delivered >during this time so if we need 4ms fuel and the open/close time is 3ms then >we need a 5ms >pulse. > >i.e.: PW = Desired rate - (OpenTime*.66666) + OpenTime. > >or PW = 4ms - (3ms * 0.66666) + 3ms ==> 4ms - 2ms + 3ms ==> 5ms. > >Change to Lucas Disk Injectors from Pintle Injectors and that formula >changes because the >Lucas open faster. > >I'd like to say .. simple eh? .... but it wasn't and we still have little >glitches that >are unsolved but I suspect are mechanical or electrical rather than >software. > >Cheers, > >John > > > > > > >---------------------------------------------------------------------------- >To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the >quotes) >in the body of a message (not the subject) to majordomo@xxx.org > ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ Date: Fri, 31 Mar 2000 9:16:18 +0000 From: Mike Blakey Subject: VR Sensor I'm looking for a 8 or 10 mm threaded body Variable Reluctance sensor (crank position) to replace a standard Ford one. Does anyone know of a supplier of VR sensors - ---------------------------------------------------------------------------- To unsubscribe from diy_efi, send "unsubscribe diy_efi" (without the quotes) in the body of a message (not the subject) to majordomo@xxx.org ------------------------------ End of DIY_EFI Digest V5 #131 ***************************** 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".