DIY_EFI Digest Thursday, March 2 2000 Volume 05 : Number 081 In this issue: The EFI332 system and stuff the 8051 ;-) New .bins on ftp site Kelsey hayes website. EFI Corvair? Misc questions. Re: DIY_EFI Digest V4 #713 Re: Misc questions. Re: DIY_EFI Digest V5 #80 Re: DIY_EFI Digest V5 #80 Multi-processor Engine Management ECT and voltage divider help? Re: ECT and voltage divider help? See the end of the digest for information on subscribing to the DIY_EFI or DIY_EFI-Digest mailing lists. ---------------------------------------------------------------------- Date: Thu, 2 Mar 2000 23:08:52 +1300 From: "Nicholas Parker" Subject: The EFI332 system and stuff the 8051 ;-) This is a multi-part message in MIME format. - ------=_NextPart_000_0056_01BF849C.46EF0F60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there, I have been playing with 87c552 and Dallas 87c550 for a while and = mucking around trying to figure out various way to implement the fuel = and spark timing with the good, but very limitted timing hardware. I am = despressed that I cant get a good C compiler without $$$ (because I'm 25 = and not rich!) I can program C and have extensive experience with 8051 asm = and good digital signal processing knoledge & practical skills I absolutely love the idea of the TPU being able to run an engine under = static fuel and air conditions with no cpu help. BUT If I could find a = separate chip or 'that 67F684 Silicon Systems chip' on the net I'd be = slighty tempted to use it and say an 8051 would cope - though I'd = rather try my luck with a 68332 I think, and have better instructions = and more bits to better support 'ieee floats' etc. My questions are: 1. Can I order a driver board for 4 injectors, and 2 coils=20 and all the 'other' CPU boards and stuff I need to run a 4 = cylinder vehicle ? 1.5 How many $ ? =20 2. Is it correct that the TPU can run the engine under static = conditions.? Without any help from the cpu except to supply what ? coil = load time, ign angle , pulse width, pulse start angle, & injector on = delay compensation. 3. Are there free tools for the 68332 including C compilers and maybe = an IDE ? 4. Theres lots of io for adding a knock sensor input ? Nick Parker '87 Toyota Supercharged MR2 New Zealand. - ------=_NextPart_000_0056_01BF849C.46EF0F60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi there,

I have been playing with 87c552 and Dallas 87c550 = for a while=20 and mucking around trying to figure out various way to implement the = fuel and=20 spark timing with the good, but very limitted timing hardware. I = am=20 despressed that I cant get a good C compiler without $$$ (because I'm 25 = and
not rich!) I can program C and have extensive experience = with 8051=20 asm and good digital signal processing knoledge & practical=20 skills

I absolutely love the idea of the TPU being able = to run=20 an engine under static fuel and air conditions with no cpu = help. BUT=20 If I could find a separate chip or 'that = 67F684 Silicon=20 Systems chip' on the net I'd be slighty tempted to use it and say an = 8051 would=20 cope - though I'd rather try my luck with a 68332 I think, and = have better=20 instructions and more bits to better support 'ieee floats' = etc.

My questions are:

1. Can I order a driver board for 4 = injectors, and=20 2 coils

and all the 'other' = CPU boards=20 and stuff I need to run a 4 cylinder vehicle ?

1.5 How many $ ?

2. Is it correct that the TPU can run = the engine=20 under static conditions.? Without any help from = the cpu=20 except to supply what ? coil load time, ign angle , pulse = width,=20 pulse start angle, & injector = on delay=20 compensation.

3. Are there free tools for the 68332 = including C=20 compilers and maybe an IDE ?

4. Theres lots of io for adding a knock = sensor=20 input ?

Nick Parker

'87 Toyota Supercharged MR2

New Zealand.

- ------=_NextPart_000_0056_01BF849C.46EF0F60-- - ---------------------------------------------------------------------------- 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, 01 Mar 2000 22:06:15 -0500 From: Shannen Durphey Subject: New .bins on ftp site This is a multi-part message in MIME format. - --------------9A7D41D62C65D3C8A18B370E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There are new files at the ftp site from Lyndon. A base calibration is there, ADTCSTK.bin. The application is a 1988 5.0L GM TBI truck with auto 4L60. The modified .bin description is below. Shannen > ADTCCAM.BIN > > This binary was reworked to provide excellent power > gains and performance over the stock calibration due > to changes in the following: > > 1. 305 to 355 CID Displacement > 2. Retained factory TBI Injectors > 3. Retained factory fuel pressure > 4. Compression of 9.4 to 1 > 5. Headers with 1-5/8 Primary tubes > 6. Camshaft 112 L/C overlap 61 degrees > Intake duration 209 @xxx.050 > Exhaust duration 216 @xxx.050 > Intake lift .435 > Exhaust lift .455 > Advertised duration 283 int and 286 exh. > > Truck pulls hard from mid to top and could still use some > bottom end tuning...but this is a good start for anyone. > Use at your own risk... > - --------------9A7D41D62C65D3C8A18B370E Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from [206.191.105.11] by grolen.com id b0750.wrk; Wed, 1 Mar 2000 22:03:44 EDT Received: from nwester ([206.191.105.90]) by eid01.eidnet.org (Post.Office MTA v3.5.3 release 223 ID# 0-59363U3000L300S0V35) with SMTP id org for ; Wed, 1 Mar 2000 20:03:43 -0700 From: "Programmer" To: "Shannen Durphey" Subject: Re: A:\ADTCCAM.BIN Date: Wed, 1 Mar 2000 20:26:10 -0700 Message-ID: <01bf83f7$0e926860$5a69bfce@nwester> X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.71.1712.3 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="zzzz3234f5e2861b109grolen.comzzzz" > If you are reading this text, then your mail reader does not support > the MIME (Multipurpose internet Mail Extensions) standard. To take > full advantage of the features of this message, you need to upgrade > your mailer to a MIME v1.0 compliant package. Some parts of this > message may be in a human readable form. - --zzzz3234f5e2861b109grolen.comzzzz Content-Type: text/plain Content-Transfer-Encoding: 7bit Explorer vs 4.0, Windows 95 plus, and a Compaq non-Pentium...maybe this is the reason ? I should be using the new 433, but its' been giving me grief... Here's an attached explanation of the binary, too...thanks again for uploading for me. Lyndon. - -----Original Message----- From: Shannen Durphey To: Programmer Date: March 1, 2000 7:38 PM Subject: Re: A:\ADTCCAM.BIN >I'm just curious. Wondering if I can spot the trouble. > >Internet Explorer? Netscape? >Shannen > >Programmer wrote: >> >> Yes--Windows95--why ?? >> LW >> -----Original Message----- >> From: Shannen Durphey >> To: Programmer >> Date: February 29, 2000 7:26 PM >> Subject: Re: A:\ADTCCAM.BIN >> >> >What software do you run? Are you windows based? >> >Shannen >> > >> >Programmer wrote: >> >> >> >> A:\ADTCCAM.BIN >> >> >> >> I can't upload it they way you stated...I must not have some software you >> >> have got--can't figure this out ... >> >> >> >> Please upload it for me... >> >> >> >> Lyndon. >> >> >> ---------------------------------------------------------------------- >> >> >> >> Name: ADTCCAM.BIN >> >> ADTCCAM.BIN Type: unspecified type (application/octet-stream) >> >> Encoding: base64 - --zzzz3234f5e2861b109grolen.comzzzz Content-Type: text/plain; name="ADTC.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ADTC.txt" ADTCCAM.BIN This binary was reworked to provide excellent power gains and performance over the stock calibration due to changes in the following: 1. 305 to 355 CID Displacement 2. Retained factory TBI Injectors 3. Retained factory fuel pressure 4. Compression of 9.4 to 1 5. Headers with 1-5/8 Primary tubes 6. Camshaft 112 L/C overlap 61 degrees Intake duration 209 @xxx.050 Exhaust duration 216 @xxx.050 Intake lift .435 Exhaust lift .455 Advertised duration 283 int and 286 exh. Truck pulls hard from mid to top and could still use some bottom end tuning...but this is a good start for anyone. Use at your own risk... nwester@xxx.org - --zzzz3234f5e2861b109grolen.comzzzz-- - --------------9A7D41D62C65D3C8A18B370E-- - ---------------------------------------------------------------------------- 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, 2 Mar 2000 13:55:37 -0500 (EST) From: Pat Ford Subject: Kelsey hayes website. Hi All: Does anyone know the url for kelsey hayes? The ecm on my tracker is a kelsey hayes beast and I want to get some info on it. Thanks - -- 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: Thu, 02 Mar 2000 14:23:03 -0500 From: Joe Curran Subject: EFI Corvair? Greetings all, I am steadily building myself up to the point that I might start to consider thinking about possibly adding EFI to my Corvair, someday. I came across this list, and noticed that there had been mention of EFI Corvairs in the past. I know they exist, and I know that Clark's now sells a kit to do it (poorly, as far as I can tell). Has anyone on this list ever gotten EFI to work on a 'vair? My original thoughts were to modify my heads to accept 3 barrel Weber carbs (IDA-3) from an old Porsche 911. Then to use TWM throttle bodies in place of the carbs, and cobble the rest together. I know of the two SDS modules that have been sold for Corvair applications, and I also know they haven't been installed, yet. For a first run, I may try to adapt the electronics and hardware from a GM 3.1L V6, since the SDS unit is a bit pricey. This is a ways down the line, but I'd like to solicit some input before I get started. Any advice, comments, etc. would be greatly appreciated. Thanks, - -Joe Curran espace@xxx.edu '66 Corvair Monza coupe w/'67 110/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, 2 Mar 2000 11:33:48 -0800 From: "Cudabob" Subject: Misc questions. Hooked up my ign analyzer and Oscope to try and get a feel for injector duty cycle an it's effect (if any) on spark. Dang old Heath Kit analyzer has a trigger problem, so no reliable results but, messing with two displays and associated connections reminded me of a project (long forgotten), which was to digitilize the analyzer. But before I start remodeling I thought maybe there is a circuit already designed to emulate an Oscope/Ign Analyzer for desktop/laptop computers. Does anyone know of such a beast? OBTW: Who, or whom do I contact to participate in the next 332 pwa buy? CudaBob '65 - Angels Camp, Calif CudaBob@xxx.com http://www.goldrush.com/~rhuish/ - ---------------------------------------------------------------------------- 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, 02 Mar 2000 13:38:31 -0800 From: MASON HAYES Subject: Re: DIY_EFI Digest V4 #713 well im asking to cross my address off the list nothing against list, I just dont check it often enough and my mailbox gets crammed full of redundant mail thanks mason hayes mahayes@xxx.us At 05:00 AM 12/23/1999 -0500, you wrote: > >DIY_EFI Digest Thursday, December 23 1999 Volume 04 : Number 713 > > > >In this issue: > > Horsepower verse Torque > Re:EFI throttle bodies > Re: Horsepower verse Torque > >See the end of the digest for information on subscribing to the >DIY_EFI or DIY_EFI-Digest mailing lists. > >---------------------------------------------------------------------- > >Date: Wed, 22 Dec 1999 15:18:04 -0500 >From: Will McGonegal >Subject: Horsepower verse Torque > >Power [Hp] = 5252.113122 * Torque [ft lbs] / rpm >5252.113122 = 550 [ft lbs/sec/Hp] * 60 [sec/min] / (2 * pi [rad / rev] ) > >------------------------------ > >Date: Wed, 22 Dec 1999 21:06:52 -0500 >From: Michael Frank >Subject: Re:EFI throttle bodies > >Dave: > > I don't know about Holley pattern, but I got a great price on the Weber >pattern TB from Jenvey in the UK. The cost for a two bore Weber-equivalent >is about US$300. They can custom make whatever you want: one or two >injectors, idle bypass, any size throttle body. If you are ordering from >the US, be sure to ask them not to charge you VAT. Their website is: > >http://www.jenvey.com > >There's a complete online catalog. > >(No Affiliation, caveat emptor, etc.) > >Mike Frank > > >> What's the going price for Weber and Holley pattern EFI throttle bodies >>with injector mounts? > >------------------------------ > >Date: Wed, 22 Dec 1999 20:15:11 -0600 >From: John Nutter >Subject: Re: Horsepower verse Torque > >DIY_EFI Digest wrote: >> >> DIY_EFI Digest Wednesday, December 22 1999 Volume 04 : Number 712 >> > >> With carb I think the down sizing is to increase the gas speed through the >> carb to increase the efficiency of the carb (not the engine). I am an SU >> person (Variable venturi, constant gas speed). I think that with Injection >> as long the gas speed is high enough to stop the fuel dropping out of the >> air then bigger is better. If the induction system is long enough and not >> too big then you will get some raming effect due to gas momentum at certain >> RPMs... >> >> Interesting to see what other people say... >> >> Ade >> > >I've read that the purpose of the venturis is to raise the speed of the >air/fuel mixture to improve atomization and to drop the air pressure to >help evaporate the gas. > >- -- >John Nutter '85 CJ7 >Admin for Jeepoffroad Mailing List >http://www.pclink.com/jnutter/jpor.htm > >President of Trailriders 4x4 club >http://www.off-road.com/~riders/ > >------------------------------ > >End of DIY_EFI Digest V4 #713 >***************************** > >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". > > > - ---------------------------------------------------------------------------- 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, 03 Mar 2000 08:53:48 +1100 From: Peter Gargano Subject: Re: Misc questions. Cudabob wrote: ... > But before I start remodeling I thought maybe there is a circuit > already designed to emulate an Oscope/Ign Analyzer for > desktop/laptop computers. > > Does anyone know of such a beast? There are a number of oscilloscope "emulators" using a PC sound card - try a net search! - ---------------------------------------------------------------------------- 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, 2 Mar 2000 14:04:06 -0800 From: "John Dammeyer" Subject: Re: DIY_EFI Digest V5 #80 > >Date: Thu, 2 Mar 100 09:45:00 +0800 (WST) >From: Bernd Felsche >Subject: Re: Multi-processor EFI > >John Dammeyer writes: > >>>------------------------------ >>>From: "Jack E. James" > >>>Hi Bernd, >>[snip] >>>controllers becomes available, it would seem that there might be >>>an advantage to separating cylinders, like two identical 4 >>>cylinder controller's for a V8. Two ignition sensors (like >>>Pertronix modules switching resistor loads to provide position >>>logic) and parallel mass air flow or 2- MAF units for less air > >That's actually done in many multi-bank engines. Only recently has >there been sufficient "processing power" been available to run a V8 >as well on a single CPU - according to the big makers anyway. ;-) Depends on the level of controllability desired I guess. For emissions control I suspect that is true but for engine control less so. >>>flow loss. Or one controller for part throttle and another for >>>full throttle. Just curious about multiple processors, having >>>thought about using some of the faster PIC,s for each cylinder. > >Running each cylinder on its own is probably not that good an idea >IMHO as it's the whole engine you need to control. The necessary >interchange of information is probably going to be the limiting >factor. This is what I was referring to later on in my previous posting. By the time you add the input filtering for each of the sensors for the individual boards your costs and complexity go way up. If you have common filters for the sensors and supplied the values to the individual processors as linearized and scaled all on one board you're at the point where the question is... why bother with a bunch of little processors and just use a big one instead. >[interesting bits snipped] > >>Fascinating question though. If absolute position information is >>available for each cylinder then designing a single PIC or ATMEL >>processor on a per cylinder basis would be an interesting project >>and certainly scalable up to V12 engines. It gets more complicated >>if you wish to use the newer 'waste spark' coils because now you >>need to work with two cylinders at a time and handle overlapped >>injector timing. > >Depends how you group the cylinders - space them at 360 degrees [snip] >Nor is it useful because all injectors wired in parallel and >separate wiring would require another output (which is "available") >and a separate harness/connector-pin to group the injectors. > I've always considered 'proper' fuel injection as multi-port sequential so I tend to forget that it's also possible to bank fire on each 360 crank stroke. >>i.e. With a one cylinder engine and a 720 degree cycle you have a >>total of 4 events to manage; Injector on/off and coil current >>on/off. [snip] >You could use a common interrupt (clock) for crank position. Each >PIC can be told to watch for a particular clock tick for each event. >There is the constraint of feeding counter information quickly to >the PICs in time. It's conceivable though, that a "broadcast" to >all the PICs could be used to give base information and to have each >perform some simple arithmetic to determine appropriate trigger >values. Think of it as having a scalable number of counters with >multiple output-compare registers (OCRs). > >With a small number of cylinders and "common" events, that's not >necessary, especially if you can reset the OCRs quickly enough. Now who does the broadcast? Another PIC? That's 7 PICs for a 6 cylinder engine. > >>Now let's talk cost. >Read about internal packaging option below. > >>Just throwing two MAP sensors into the engine for two controllers >If you look at the possibilities presented by high-speed >inter-processor busses and cheap packaging options such as SIMM, >then a scalable option, at least for the data-acquisition and driver >sections becomes attractive. > >The high-level control strategy is probably better achieved by >a "proper" CPU with sufficient address and physical memory space as >well as crunch capability, driving the slave processors. Well... that same scalability is also there with a C167C 16 bit RISC processor architecture though and it has a heap of OCR type timers. It has enough to dedicate one to each event (injector and ignition) and is fast enough to handle everything. I used the Philips 80C592 because it had 5 OCRs. Even then I ran into timer sharing problems because I used sequential injection and there are times when the new pulse width for cyl. X will suddenly need to start before the pulse for cyl. Y by 5 or 6 clock ticks. By the time the new compare values are installed and handled cyl X injector may turn on but the turn on point for cyl Y is passed so the injector misses a cycle and results in an engine miss. > >I initially brought up the possibility of using multi-processors as >a means of expanding capabilities of the specialised chips which, [snip] Most of the smaller specialized chips (PIC in particular) are really poor at 16 bit math operations and if your counter needs to handle timing between TDC and BDC at Cranking and at 7000RPM you need to be able to manipulate 16 bit values. Add to that the math to handle enrichments and 32 bit results become a reality and the small 8 bit processors fall flat on their face. It can be done. I just had to write a specialty 32 bit library of routines for a PIC used in a Oil Well Down hole operation (sin, cos, arcsin and square root). Physically the board was large enough to hold a C505C from Infinion but without the Flash ability there would need to be a large program storage device. > >>Good idea but not economically viable - especially for a hobby. > >Like you, I doubt that one-PIC-per-cylinder is economically viable; >though it is intellectually stimulating. > >The question of scalability remains: If you run out of capacity, do >you perform a leap in architecture, or do you use tandem processors >for the required functions? I'll do the leap in architecture. The C167C can use an 8 bit external bus for program storage and there are some nice FLASH parts around for holding code. So if I do another ignition/injection system, I'd use the 167. I'd have the RISC speed like a PIC, large program addressability and 16 bit math operations plus the built in A/D and OCRs. For the bigger 8 bit family check out www.lawicel.com for the C505C with WSI FLASH/EEROM/RAM/PLD as an example of what can be done inexpensively. With the Keil or Tasking compiler 32 bit longs (and floats) (although still clumsy) are available. > >The trick may be to gaze into the crystal ball and see where that >wall is located - and see if it matters. I have one of those.... but it's opaque. > >- -- >Real Name: Bernd Felsche 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 ------------------------------ Date: Thu, 2 Mar 2000 18:47:17 -0500 From: "crash70" Subject: Re: DIY_EFI Digest V5 #80 > "Camden Lindsay" >Subject: saab ignition > >Hello, >I'm just getting started on a project; an 84 audi with a newer turbo = >motor. I am interested in doing my own work/ using a computer/etc. I = >was wondering if you had any of the saab systems left, and if not can = >you get them? Also, I would be interested in how to interface the saab = >ignition setup with any other or a custom setup. =20 >Thank You, >Sincerely, >Camden Lindsay Camden, Exactly what motor do you have? Also, I'm curious as to your interest in installing a Saab ignition. Are you after the "APC" system? I have a little project of my own I've been working on. I am using a Bosch LH-Jetronic (hot wire) system on a 2.0L VW motor. The motor was previously used a Bosch CIS system. I've "bench tested the entire system (worked perfectly) but I'm saving cash up to buy an adjustable fuel pressure regulator so I don't have to change fuel pumps (I'll have a little extra pressure too). My reasoning for this is simple: eliminate the air restriction of the metering plate on the stock CIS system. Between the airflow increase, and the extra fuel (and timing) I'm hoping to see a significant increase in horsepower. I have not integrated the Saab ignition as of yet; VW's electronic system (with knock sensor) is similar (if not better) than Saab's system. I'd be curious to know what you're up to; maybe we can swap info! PS I have LH bins if you need them. Chris - ---------------------------------------------------------------------------- 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, 3 Mar 100 09:27:53 +0800 (WST) From: Bernd Felsche Subject: Multi-processor Engine Management John Dammeyer writes: >>From: Bernd Felsche >>>>From: "Jack E. James" >>That's actually done in many multi-bank engines. Only recently has >>there been sufficient "processing power" been available to run a V8 >>as well on a single CPU - according to the big makers anyway. ;-) >Depends on the level of controllability desired I guess. For >emissions control I suspect that is true but for engine control >less so. The other problem was of course the range of operation of the air-flow meters... a smaller size allows better control at low engine speeds. It's like adding an extra bit of resolution. >>>>flow loss. Or one controller for part throttle and another for >>>>full throttle. Just curious about multiple processors, having >>>>thought about using some of the faster PIC,s for each cylinder. >>Running each cylinder on its own is probably not that good an idea >>IMHO as it's the whole engine you need to control. The necessary >>interchange of information is probably going to be the limiting >>factor. >This is what I was referring to later on in my previous posting. >By the time you add the input filtering for each of the sensors for >the individual boards your costs and complexity go way up. If you >have common filters for the sensors and supplied the values to the >individual processors as linearized and scaled all on one board >you're at the point where the question is... why bother with a >bunch of little processors and just use a big one instead. If the big one lack inputs/output or a particular facility, then it may be wise to use a separate processor with the necessary facilities; instead of using dedicated hardware or cooking up external multiplexing, etc. It's a way of minimising the complexity, but allowing for expansion. You could use the same main controller for one, two, three or four- cylinder operation, then add identical "co-processors" to handle engines with more cylinders. (A 32-bit RISC controller could probably handle 8 cylinders with ease. But it would struggle with 18.) You could also add on auxiliary processors to handle supplementary functions which don't fit well into the core function of engine management - e.g. OBD-II, data logging, CAN, etc. That means you use the same core for all engines - it, and the co-processors become a building blocks for future projects. Each building block is relatively simple to implement. That improves reliability as the interaction of functions, and the inherent problems arising are reduced. One processor per cylinder (or function) is probably the extreme in terms of cost. >[snip] >>Nor is it useful because all injectors wired in parallel and >>separate wiring would require another output (which is "available") >>and a separate harness/connector-pin to group the injectors. >I've always considered 'proper' fuel injection as multi-port >sequential so I tend to forget that it's also possible to bank fire >on each 360 crank stroke. You won't forget after this discussion. :-) >>>i.e. With a one cylinder engine and a 720 degree cycle you have a >>>total of 4 events to manage; Injector on/off and coil current >>>on/off. >[snip] >>You could use a common interrupt (clock) for crank position. Each >>PIC can be told to watch for a particular clock tick for each event. >>There is the constraint of feeding counter information quickly to >>the PICs in time. It's conceivable though, that a "broadcast" to >>all the PICs could be used to give base information and to have each >>perform some simple arithmetic to determine appropriate trigger >>values. Think of it as having a scalable number of counters with >>multiple output-compare registers (OCRs). >>With a small number of cylinders and "common" events, that's not >>necessary, especially if you can reset the OCRs quickly enough. >Now who does the broadcast? Another PIC? That's 7 PICs for a 6 >cylinder engine. It would have to be a more complex management unit. Mainly due to the limited arithmetic capabilities of PICs. >>>Now let's talk cost. >>Read about internal packaging option below. >>>Just throwing two MAP sensors into the engine for two controllers >>If you look at the possibilities presented by high-speed >>inter-processor busses and cheap packaging options such as SIMM, >>then a scalable option, at least for the data-acquisition and driver >>sections becomes attractive. >>The high-level control strategy is probably better achieved by >>a "proper" CPU with sufficient address and physical memory space as >>well as crunch capability, driving the slave processors. >Well... that same scalability is also there with a C167C 16 bit >RISC processor architecture though and it has a heap of OCR type >timers. It has enough to dedicate one to each event (injector and >ignition) and is fast enough to handle everything. I'm not familiar with the scalability of the C167C; I will look it up though... how do you add extra OCR's/counters to extend your two-cylinder controller to run 18 cylinders, for the sake of argument? Got a URL? >I used the Philips 80C592 because it had 5 OCRs. Even then I ran >into timer sharing problems because I used sequential injection and >there are times when the new pulse width for cyl. X will suddenly >need to start before the pulse for cyl. Y by 5 or 6 clock ticks. >By the time the new compare values are installed and handled cyl X >injector may turn on but the turn on point for cyl Y is passed so >the injector misses a cycle and results in an engine miss. Ah - so you had a scalability problem. :-) >>I initially brought up the possibility of using multi-processors as >>a means of expanding capabilities of the specialised chips which, >[snip] >Most of the smaller specialized chips (PIC in particular) are >really poor at 16 bit math operations and if your counter needs to >handle timing between TDC and BDC at Cranking and at 7000RPM you >need to be able to manipulate 16 bit values. Add to that the math Good point. Something as simple as a PIC would however be relegated to watching the common clock and toggling outputs for ignition and fuel. The appropriate clock tick can be calculated by the PIC as its offset from the "distributed" value provided in the broadcast from the main processor. (For tight control - each PIC could have presets provided by the main processor for cylinder-specific spark timing and fuel trimming.) >to handle enrichments and 32 bit results become a reality and the >small 8 bit processors fall flat on their face. It can be done. I Those high-level functions should be handled by the high-level controller. >just had to write a specialty 32 bit library of routines for a PIC >used in a Oil Well Down hole operation (sin, cos, arcsin and square >root). Physically the board was large enough to hold a C505C from >Infinion but without the Flash ability there would need to be a >large program storage device. I don't believe that sort of complex arithmetic is required for engine control. Given the low resolution of inputs and outputs, those sorts of functions can be approximated by up to second- and third- order terms of Fourier series if they became absolutely necessary. >>The question of scalability remains: If you run out of capacity, do >>you perform a leap in architecture, or do you use tandem processors >>for the required functions? >I'll do the leap in architecture. The C167C can use an 8 bit >external bus for program storage and there are some nice FLASH >parts around for holding code. So if I do another >ignition/injection system, I'd use the 167. I'd have the RISC >speed like a PIC, large program addressability and 16 bit math >operations plus the built in A/D and OCRs. So you reckon it'll run a W18 engine with a single controller? :-) Currently takes 3 Motronic units. One per V6. >For the bigger 8 bit family check out www.lawicel.com for the C505C >with WSI FLASH/EEROM/RAM/PLD as an example of what can be done >inexpensively. With the Keil or Tasking compiler 32 bit longs (and >floats) (although still clumsy) are available. I can do 32-bit arithmetic using 8-bit registers. No need for a fancy compiler. :-) >>The trick may be to gaze into the crystal ball and see where that >>wall is located - and see if it matters. >I have one of those.... but it's opaque. All the more reason to consider scalability. - -- Real Name: Bernd Felsche Email: nospam.bernie@xxx.au http://www.perth.dialix.com.au/~bernie - Private HP - ---------------------------------------------------------------------------- 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, 2 Mar 2000 22:16:05 -0700 (MST) From: Daniel Houlton Subject: ECT and voltage divider help? I'm working on a schmatic for a small controller for an electric radiator fan and I have some questions on reading the ECT sensor. Doing some testing on my truck I found that the sensor is fed 5V from the ECM (measured with the wire dis-connected from the ECT), but connected it only reads 3V when cold. The voltage then drops to around .65 V at normal operating temp. It's not really important, but I was somewhat confused how hooking the wire to the ECT sensor caused the voltage to drop from 5V to 3V (or .7V or so when hot). After some research on the net, I found that it's set up as a voltage divider. The 5V (OK, actually like 4.9x or so) goes through a resistor in the ECM before coming out to the ECT. The readings I were taking were between the two series resistors so it's working as a voltage divider. After some math, I found the internal ECM resistor is around 1765 ohms, confirmed by both hot and cold readings. So, my question is, how do I switch something based on this voltage? Basically, I want to monitor the voltage to the ECT sensor and when it drops to around .4 or .5 V I want to trigger an output (that eventually drives a relay). Then, while the output is triggered and the voltage goes back up to around .7 V to turn the output back off. And I want to be able to fine-tune the on and off voltages with a couple pots. Any ideas how I can do this? I don't know a lot of the solid state devices. Would I be using a transitor, op-amp, etc? Will tapping into the ECT wire to read voltage somehow screw up the reading to the ECM by acting as a sink or source? Also, I'm including several inputs that can trigger the fan relay like the A/C clutch, air compressor clutch, and a couple extras as well as a manual on, manual off (which over-ride the other inputs) and an automatic setting. The inputs are diode protected to prevent backflow from one signal to another and they run into a low amp relay. That relay is controlled by the manual off/on/auto over-ride and triggers the 30 amp fan relay. My question is, that he low-amp signal relay (needs to handle about 200 mA max to trigger the fan relay coil) seems kinda big and bulky. Is there a solid state device that can replace this? Typically, a relay is used to drive a big load with a small signal, but I want to drive a small load with a small signal. Just wondering if there was some kind of small IC that would do that instead of a big relay. Oh yeah, one more thing. I've found sockets for different types of relays in Jameco and a couple other catalogs, but they aren't very high amperage and I'd rather use a common automotive 30A relay. I can't find board mounted sockets for these automotive relays though, just pigtail sockets with wire leads. Anybody know where I could find a board mount socket for these? thanks a bunch - --Dan houlster@xxx.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, 3 Mar 100 14:58:07 +0800 (WST) From: Bernd Felsche Subject: Re: ECT and voltage divider help? Daniel Houlton writes: >I'm working on a schmatic for a small controller for an electric >radiator fan and I have some questions on reading the ECT sensor. >Doing some testing on my truck I found that the sensor is fed 5V from >the ECM (measured with the wire dis-connected from the ECT), but >connected it only reads 3V when cold. The voltage then drops to >around .65 V at normal operating temp. Looks like nominal behaviour for any NTC device. You're probably seeing the result of a constant-current supply being used to determine the sensor's resistance - a constant current through a variable resistance will give a variable voltage. >It's not really important, but I was somewhat confused how hooking >the wire to the ECT sensor caused the voltage to drop from 5V to 3V >(or .7V or so when hot). After some research on the net, I found that >it's set up as a voltage divider. Test the sensor in isolation; switch off the engine, unplug the sensor and measure the resistance using a multi-meter. If the resistance falls with increasing coolant temperature, then it's probably an NTC resistor. >So, my question is, how do I switch something based on this voltage? >Basically, I want to monitor the voltage to the ECT sensor and when it >drops to around .4 or .5 V I want to trigger an output (that eventually >drives a relay). Then, while the output is triggered and the voltage First; you need to isolate your circuit from the other one using the same sensor. Using an op-amp is the easiest way of doing that - Op amps have input impedances in the megaohm range. Isolating the sensor gives you a buffered output signal - you might want to have a small gain set up on the op-amp for convenience - else keep it at unity. You can then feed the signal into a "comparator"; an op-amp can be used for that as well. The comparator is basical a "switch" that has a low output when the sensed input is less than the reference voltage, and the output is high when the sense level is higher than reference. Depending on the op-amp, you can then drive the relay "directly" from the comparator output. >goes back up to around .7 V to turn the output back off. And I want >to be able to fine-tune the on and off voltages with a couple pots. If you need hysteresis, then the circuit gets more complex. You'd need another comparator and then combine outputs to set and reset the corresponding driver output. There are dozens of ways of doing that; a flip-flop is just one way - using the high-level comparator output as the SET and the low-level comparator output to RESET the flip-flop. The reference levels of the comparator would be how you set the on-off levels. Use the potentiometers in series to ensure that the high reference level will always be higher than the low! >Any ideas how I can do this? I don't know a lot of the solid state >devices. Would I be using a transitor, op-amp, etc? >Will tapping into the ECT wire to read voltage somehow screw up the >reading to the ECM by acting as a sink or source? >Also, I'm including several inputs that can trigger the fan relay like >the A/C clutch, air compressor clutch, and a couple extras as well as >a manual on, manual off (which over-ride the other inputs) and an >automatic setting. In that case, you may be better off with a small computer with an analogue to digital converter and several digital inputs. You then also have the ability to drive the radiator fan at a speed according to the load by using a pulse-width-modulated drive instead of a relay. The computer (micro-controller) would eliminate all the small relays and a heap of nested wiring. Flash-programmable computers are very cheap - the micro-controller itself typically costs a few dollars; the big bucks arise due to sophisticated output (mainly driver transistors), housings and environmental requirements - heat sinks, etc. In your application; if you're not worried about how it looks, you should be able to throw something together for about $50 - assuming you have access to a suitable desktop computer to write and compile the programs; and then download them to the micro-controller. I know what the necessary circuits look like on my car when using "conventional" setups that do the same sort of thing == UGLY. >My question is, that he low-amp signal relay (needs to handle about 200 >mA max to trigger the fan relay coil) seems kinda big and bulky. Is >there a solid state device that can replace this? Typically, a relay >is used to drive a big load with a small signal, but I want to drive a >small load with a small signal. Just wondering if there was some kind >of small IC that would do that instead of a big relay. A high-power transistor. say a (MOS)FET - don't know how an IGBT would handle being on all the time. >Oh yeah, one more thing. I've found sockets for different types of >relays in Jameco and a couple other catalogs, but they aren't very >high amperage and I'd rather use a common automotive 30A relay. I >can't find board mounted sockets for these automotive relays though, >just pigtail sockets with wire leads. Anybody know where I could find >a board mount socket for these? Turn the problem upside-down. See if you can fit your logic circuits into a relay case, find a relay plate and plug it in. A relay plate is just a moulded plastic section designed for you to plug in a relay - you clip a few together and wire the connections as needed using conventional automotive spade connectors. Auto-electricians will never guess you have a computer in one of those tiny relay cases. :-) - -- Real Name: Bernd Felsche Email: nospam.bernie@xxx.au http://www.perth.dialix.com.au/~bernie - Private HP - ---------------------------------------------------------------------------- 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 #81 **************************** 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".