From niche at iinet.net.au Sun Apr 1 07:00:27 2007 From: niche at iinet.net.au (Mike) Date: Sun, 01 Apr 2007 20:00:27 +0800 Subject: [Diy_efi] Good insulation tubing recommendation In-Reply-To: <003201c772d4$6daa77b0$0300a8c0@userc276844d8d> References: <590205.9792.qm@web50304.mail.re2.yahoo.com> <007e01c77233$c5e95410$0300a8c0@userc276844d8d> <7.0.1.0.0.20070330132356.02759eb0@iinet.net.au> <002e01c7728e$5b0adeb0$0300a8c0@userc276844d8d> <7.0.1.0.0.20070330153742.026eb7d0@iinet.net.au> <003201c772d4$6daa77b0$0300a8c0@userc276844d8d> Message-ID: <7.0.1.0.0.20070401195751.026f0820@iinet.net.au>> At 10:05 PM 3/30/07, you wrote: >To insulate wiring and small hoses in hot areas I've been making good use of the stuff used to double-insulate spark plug wires, fiberglass sleeving in silicon rubber. Most autoparts stores are beginning to handle the stuff now, not expensive. A friend who runs a car at Bonneville turned me on to it. Diesel injector and turbo rebuild shops also handle it, or something similar. >Ernie Interesting, thanks one more item on the list to check when I go trvalling amoungst various suppliers - should see the look on anguish on those in the queue behind me when I ask technical questions, or I might add (and this is a worrying trend) questions just a little out of the ordinary. its as if the general technical skill level of most people going to suppliers has dropped or not advanced as much as I would have assumed cheers mike >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi Regards from Mike Perth, Western Australia VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! Twin tyres for most sedans, trikes and motorcycle sidecars http://niche.iinet.net.au From Steve.Ravet at arm.com Tue Apr 3 00:35:09 2007 From: Steve.Ravet at arm.com (Steve Ravet) Date: Mon, 2 Apr 2007 22:35:09 -0700 Subject: [Diy_efi] OBD2 emulation In-Reply-To: <20070331.101552.2157.1144504@webmail45.nyc.untd.com> Message-ID: I saw one time the flowchart used by the OBD 2 test. Part of it is illuminating the check engine light so you'd have to wire to it as well as the OBD2 connector. The short answer to your question is that it certainly can be done, with a cheap freescale MCU that has a BDLC. I've not heard of anyone doing it, though, so you'd have to do it from scratch. There's probably a demo board in the couple hundred dollar range from freescale or another supplier that would give you the hardware you needed, if so you'd just have to hunt up the flowchart for the test and write firmware to implement it. --steve > -----Original Message----- > From: diy_efi-bounces at diy-efi.org > [mailto:diy_efi-bounces at diy-efi.org] On Behalf Of Jason D. > Sent: Saturday, March 31, 2007 1:16 PM > To: diy_efi at diy-efi.org > Subject: [Diy_efi] OBD2 emulation > > I don't know if this has come up before, but for those who > have OBD2 GM vehicles and have used a different ECU to allow > you to tune it, what can you do to pass emissions? The > emissions check where I live is a simple plug in test to the > computer where they just check for codes and see if it lists > as "ready" on the emissions pre-tests. SO, is it possible to > emulate an OBD2 port on the vehicle? Or even hack a 2nd obd2 > ecu to just say all is well? Swapping back to the old ecu is > not possible as it isn't hackable nor could it even the run > the engine if I wanted it to. Thanks. > > > > ______________________________________________________________ > __________ > Interested in getting caught up on today's news? > Click here to checkout USA TODAY Headlines. > http://track.juno.com/s/lc?s=198954&u=http://www.usatoday.com/ > news/front.htm?csp=24 > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From liberty1 at gmail.com Tue Apr 3 01:12:34 2007 From: liberty1 at gmail.com (Bobby Yates Emory) Date: Mon, 2 Apr 2007 23:12:34 -0700 Subject: [Diy_efi] OBD2 emulation In-Reply-To: References: <20070331.101552.2157.1144504@webmail45.nyc.untd.com> Message-ID: <54b6188b0704022312u25c50ef6x2df0faa31e8a267f@mail.gmail.com> Steve, I don't think he wanted to be able to run the OBD 2 test. I think he just wanted to put the correct signals to the OBD 2 connector so the OBD 2 scan tool reports that there are no codes stored. That should be simpler, but your freescale idea may be a good way to do it. Bobby On 4/2/07, Steve Ravet wrote: > > I saw one time the flowchart used by the OBD 2 test. Part of it is > illuminating the check engine light so you'd have to wire to it as well > as the OBD2 connector. The short answer to your question is that it > certainly can be done, with a cheap freescale MCU that has a BDLC. I've > not heard of anyone doing it, though, so you'd have to do it from > scratch. There's probably a demo board in the couple hundred dollar > range from freescale or another supplier that would give you the > hardware you needed, if so you'd just have to hunt up the flowchart for > the test and write firmware to implement it. > > --steve > > > -----Original Message----- > > From: diy_efi-bounces at diy-efi.org > > [mailto:diy_efi-bounces at diy-efi.org] On Behalf Of Jason D. > > Sent: Saturday, March 31, 2007 1:16 PM > > To: diy_efi at diy-efi.org > > Subject: [Diy_efi] OBD2 emulation > > > > I don't know if this has come up before, but for those who > > have OBD2 GM vehicles and have used a different ECU to allow > > you to tune it, what can you do to pass emissions? The > > emissions check where I live is a simple plug in test to the > > computer where they just check for codes and see if it lists > > as "ready" on the emissions pre-tests. SO, is it possible to > > emulate an OBD2 port on the vehicle? Or even hack a 2nd obd2 > > ecu to just say all is well? Swapping back to the old ecu is > > not possible as it isn't hackable nor could it even the run > > the engine if I wanted it to. Thanks. > > > > > > > > ______________________________________________________________ > > __________ > > Interested in getting caught up on today's news? > > Click here to checkout USA TODAY Headlines. > > http://track.juno.com/s/lc?s=198954&u=http://www.usatoday.com/ > > news/front.htm?csp=24 > > _______________________________________________ > > Diy_efi mailing list > > Diy_efi at diy-efi.org > > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > > Main WWW page: http://www.diy-efi.org/diy_efi > > > > -- > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > -- Toward freedom, Bobby Yates Emory From arsoftware at gmail.com Tue Apr 3 07:15:08 2007 From: arsoftware at gmail.com (Alex Ruiz) Date: Tue, 3 Apr 2007 10:15:08 -0200 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage Message-ID: <7b372cc90704030515r47044b6ao58444a5a26294e64@mail.gmail.com> Hello, I'm using a microcontroller with standard CAPTURE/COMPARE units in order to process a 60-2 crank wheel. I'm very concerned about noise and a single step Kalman Filter seems to be a very good tool for this application. Does anybody have experience with that? Could you please point me to some articles or information on how that particular application of Kalman could be implemented? Is it really efficient as it sounds like? I'm still reading the basic literature about Kalman and Statistics. Much appreciated. Alex From Tim.VanSetten at l-3com.com Tue Apr 3 07:59:59 2007 From: Tim.VanSetten at l-3com.com (Van Setten, Tim @ ACSSD) Date: Tue, 3 Apr 2007 05:59:59 -0700 Subject: [Diy_efi] OBD2 emulation In-Reply-To: <54b6188b0704022312u25c50ef6x2df0faa31e8a267f@mail.gmail.com> References: <20070331.101552.2157.1144504@webmail45.nyc.untd.com> <54b6188b0704022312u25c50ef6x2df0faa31e8a267f@mail.gmail.com> Message-ID: <8846C6D2B241184780AAFD4C43D2B74B5F93EB@LIBERTY.phx.acssd.l-3com.com> I have been wanting one of these for a long time now. If you get this working, sign me up for one....Tim. -----Original Message----- From: diy_efi-bounces at diy-efi.org [mailto:diy_efi-bounces at diy-efi.org] On Behalf Of Bobby Yates Emory Sent: Monday, April 02, 2007 11:13 PM To: diy_efi at diy-efi.org Subject: Re: [Diy_efi] OBD2 emulation Steve, I don't think he wanted to be able to run the OBD 2 test. I think he just wanted to put the correct signals to the OBD 2 connector so the OBD 2 scan tool reports that there are no codes stored. That should be simpler, but your freescale idea may be a good way to do it. Bobby From niche at iinet.net.au Tue Apr 3 07:58:30 2007 From: niche at iinet.net.au (Mike) Date: Tue, 03 Apr 2007 20:58:30 +0800 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <7b372cc90704030515r47044b6ao58444a5a26294e64@mail.gmail.co m> References: <7b372cc90704030515r47044b6ao58444a5a26294e64@mail.gmail.com> Message-ID: <7.0.1.0.0.20070403204852.0275c440@iinet.net.au>> At 08:15 PM 4/3/07, you wrote: >Hello, > >I'm using a microcontroller with standard CAPTURE/COMPARE units in order to >process a 60-2 crank wheel. I'm very concerned about noise and a single step >Kalman Filter seems to be a very good tool for this application. Not sure what u mean by a "60-2" though if you are not using it for synchronism of fuel/ignition and only for a speed rpms derivation - albeit a good one then it might be ok. >Does anybody have experience with that? Could you please point me to some >articles or information on how that particular application of Kalman could >be implemented? Is it really efficient as it sounds like? Ive used a multistage kalman filter in a nucleonic ore flow gauge project where two Co60 beams and counters measured mass flow rate of ore by absorption. ie. Trying to data process two normal curves as they were affected by falling ore and gravity was my first foray into 16 bit micros in 1980 or so. It was a bit over my head but I struggled through it and we made the system work fine though we did bring in a specialist mathematician from India's mining industry to lend a hand, his command of english emabrrased us poor colloquial cohorts ! They were reasonably effective and the various coefficients and post processing supplied a total flow rate that was within 1 to 3% *but* the short term accuracy was not better than 20% or so as the various state variables took many cycles to clear or rather 'impose' their accumulations on the overall flow rate. In other words I feel it not appropriate to use Kalman for speed measurements and definitely nor for anything requiring any synchronicty at all under any circumstances. >I'm still reading the basic literature about Kalman and Statistics. it was tough for me 26 years ago, I think you wont need it if you can address the h/w issue with respect to noise such as cable routine, impedance of sensors, screening etc Eg. The Crank signal for the EFI and ignition for an RB30 motor is passed in parallel more or less with the spark wiring loom for a few cms, it might blow the odd sensor but doesnt seem to affect noise on a cycle by cycle basis. ie The ignition is smooth and stable for working sensors that dont get too hot... rgds Mike >Much appreciated. >Alex >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi Regards from Mike Perth, Western Australia VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! Twin tyres for most sedans, trikes and motorcycle sidecars http://niche.iinet.net.au From arsoftware at gmail.com Tue Apr 3 08:33:15 2007 From: arsoftware at gmail.com (Alex Ruiz) Date: Tue, 3 Apr 2007 11:33:15 -0200 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <7.0.1.0.0.20070403204852.0275c440@iinet.net.au> References: <7b372cc90704030515r47044b6ao58444a5a26294e64@mail.gmail.com> <7.0.1.0.0.20070403204852.0275c440@iinet.net.au> Message-ID: <7b372cc90704030633n2ded92f4mf1dbdea3cf290268@mail.gmail.com> >Not sure what u mean by a "60-2" though if you are not using it for synchronism >of fuel/ignition and only for a speed rpms derivation - albeit a good one then it might be >ok. I mean the toothweel 60-2 ( 60 minus 2 or 58 teeth wheel ) very common on Boch EFIs ( VW ). 36-1 and 24 toothweels are also going to be recognized by the system. The signal is conditioned by a lm1815 in case a VR sensor is used and a comparator with hysteresis if a HALL sensor is used. It will be used to do crank angle estimation/measurement in a EFI system. Low pass filters and comparators with hysteresis are used but, I'm afraid noise is still going to hit my capture unit, witch is more likely to happen... There's a SAE article that uses Kalman filter to process signal from a crankshaft of a Scooter engine. I'll check it if I can get that article to have an idea of how that was implemented. http://www.sae.org/technical/papers/2005-01-0076 2007/4/3, Mike : > > At 08:15 PM 4/3/07, you wrote: > >Hello, > > > >I'm using a microcontroller with standard CAPTURE/COMPARE units in order > to > >process a 60-2 crank wheel. I'm very concerned about noise and a single > step > >Kalman Filter seems to be a very good tool for this application. > > Not sure what u mean by a "60-2" though if you are not using it for > synchronism > of fuel/ignition and only for a speed rpms derivation - albeit a good one > then it might be ok. > > >Does anybody have experience with that? Could you please point me to some > >articles or information on how that particular application of Kalman > could > >be implemented? Is it really efficient as it sounds like? > > Ive used a multistage kalman filter in a nucleonic ore flow gauge project > where > two Co60 beams and counters measured mass flow rate of ore by absorption. > ie. Trying to data process two normal curves as they were affected by > falling ore > and gravity was my first foray into 16 bit micros in 1980 or so. It was a > bit over > my head but I struggled through it and we made the system work fine though > we did > bring in a specialist mathematician from India's mining industry to lend a > hand, his > command of english emabrrased us poor colloquial cohorts ! > > They were reasonably effective and the various coefficients and post > processing supplied a total > flow rate that was within 1 to 3% *but* the short term accuracy was not > better > than 20% or so as the various state variables took many cycles to clear or > rather > 'impose' their accumulations on the overall flow rate. > > In other words I feel it not appropriate to use Kalman for speed > measurements > and definitely nor for anything requiring any synchronicty at all under > any circumstances. > > > >I'm still reading the basic literature about Kalman and Statistics. > > it was tough for me 26 years ago, > > I think you wont need it if you can address the h/w issue with respect to > noise such > as cable routine, impedance of sensors, screening etc > > Eg. The Crank signal for the EFI and ignition for an RB30 motor is passed > in parallel more > or less with the spark wiring loom for a few cms, it might blow the odd > sensor but doesnt seem to affect > noise on a cycle by cycle basis. ie The ignition is smooth and stable for > working > sensors that dont get too hot... > > rgds > > Mike > > > > > >Much appreciated. > >Alex > >_______________________________________________ > >Diy_efi mailing list > >Diy_efi at diy-efi.org > >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > >Main WWW page: http://www.diy-efi.org/diy_efi > > > > Regards from > > > Mike > Perth, Western Australia > VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, > guaranteed ! > Twin tyres for most sedans, trikes and motorcycle sidecars > http://niche.iinet.net.au > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > From bbowling at earthlink.net Tue Apr 3 08:36:49 2007 From: bbowling at earthlink.net (Bruce A Bowling) Date: Tue, 3 Apr 2007 09:36:49 -0400 (EDT) Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage Message-ID: <9389119.1175607409627.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> In the MegaSquirt MS-II version, we have implemented a simple form of the kalman filter known as an "Alpha-Beta-Gamma Tracking Filter". http://www.megamanual.com/ms2/alphabeta.htm Note that this is just another form of a predictor-corrector algorithm. In fact, originally we implemented a full-blown kalman filter, but quickly realized that since all of the sample datapoints had the exact same statistical error the a-b-g filter implementation would suffice. Full-up KF are used to determine the best answer for the next state from many different sources of measurements (with corresponding variances) and process model sources. Tracking filters are used everywhere, from missle track determination, machine vision, to brushless commutation of DC motors. A side benefit is that they are extremely easy to implement and are not very computationally intensive - in fact they can be easily synthesized in programmable logic. - Bruce -----Original Message----- >From: Mike >Sent: Apr 3, 2007 8:58 AM >To: diy_efi at diy-efi.org >Subject: Re: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage > >At 08:15 PM 4/3/07, you wrote: >>Hello, >> >>I'm using a microcontroller with standard CAPTURE/COMPARE units in order to >>process a 60-2 crank wheel. I'm very concerned about noise and a single step >>Kalman Filter seems to be a very good tool for this application. > >Not sure what u mean by a "60-2" though if you are not using it for synchronism >of fuel/ignition and only for a speed rpms derivation - albeit a good one then it might be ok. > >>Does anybody have experience with that? Could you please point me to some >>articles or information on how that particular application of Kalman could >>be implemented? Is it really efficient as it sounds like? > >Ive used a multistage kalman filter in a nucleonic ore flow gauge project where >two Co60 beams and counters measured mass flow rate of ore by absorption. >ie. Trying to data process two normal curves as they were affected by falling ore >and gravity was my first foray into 16 bit micros in 1980 or so. It was a bit over >my head but I struggled through it and we made the system work fine though we did >bring in a specialist mathematician from India's mining industry to lend a hand, his >command of english emabrrased us poor colloquial cohorts ! > >They were reasonably effective and the various coefficients and post processing supplied a total >flow rate that was within 1 to 3% *but* the short term accuracy was not better >than 20% or so as the various state variables took many cycles to clear or rather >'impose' their accumulations on the overall flow rate. > >In other words I feel it not appropriate to use Kalman for speed measurements >and definitely nor for anything requiring any synchronicty at all under any circumstances. > > >>I'm still reading the basic literature about Kalman and Statistics. > >it was tough for me 26 years ago, > >I think you wont need it if you can address the h/w issue with respect to noise such >as cable routine, impedance of sensors, screening etc > >Eg. The Crank signal for the EFI and ignition for an RB30 motor is passed in parallel more >or less with the spark wiring loom for a few cms, it might blow the odd sensor but doesnt seem to affect >noise on a cycle by cycle basis. ie The ignition is smooth and stable for working >sensors that dont get too hot... > >rgds > >Mike > > > > >>Much appreciated. >>Alex >>_______________________________________________ >>Diy_efi mailing list >>Diy_efi at diy-efi.org >>Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >>Main WWW page: http://www.diy-efi.org/diy_efi > > > >Regards from > > >Mike >Perth, Western Australia >VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! >Twin tyres for most sedans, trikes and motorcycle sidecars >http://niche.iinet.net.au >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi From Steve.Ravet at arm.com Tue Apr 3 09:04:31 2007 From: Steve.Ravet at arm.com (Steve Ravet) Date: Tue, 3 Apr 2007 07:04:31 -0700 Subject: [Diy_efi] OBD2 emulation In-Reply-To: <54b6188b0704022312u25c50ef6x2df0faa31e8a267f@mail.gmail.com> Message-ID: > -----Original Message----- > From: diy_efi-bounces at diy-efi.org > [mailto:diy_efi-bounces at diy-efi.org] On Behalf Of Bobby Yates Emory > Sent: Tuesday, April 03, 2007 1:13 AM > To: diy_efi at diy-efi.org > Subject: Re: [Diy_efi] OBD2 emulation > > Steve, > > I don't think he wanted to be able to run the OBD 2 test. I > think he just wanted to put the correct signals to the OBD 2 > connector so the OBD 2 scan tool reports that there are no > codes stored. > > That should be simpler, but your freescale idea may be a good > way to do it. It's not as simple as reporting no codes stored. The tester has a procedure that it goes through and it expects the car to respond appropriately at each step. This includes commanding the CEL to come on, and the operator must verify that it actually comes on. There were initially some cars (Mercedes and Mitsubishi) that did not respond appropriately to the various queries that the tester made and were flunked although they were brand new. In some cases dealers were forced to buy back perfectly good cars because they could not be inspected. The way to do this is to get a copy of that flowchart and implement it in firmware in a microcontroller that includes an OBD2 interface. If I can dig up the one I saw before I'll post it on the twiki. --steve -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From arsoftware at gmail.com Tue Apr 3 09:47:07 2007 From: arsoftware at gmail.com (Alex Ruiz) Date: Tue, 3 Apr 2007 12:47:07 -0200 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <9389119.1175607409627.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> References: <9389119.1175607409627.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> Message-ID: <7b372cc90704030747pad419b7u9b8e5744c1b028d8@mail.gmail.com> Bruce, That is exactly the point where I must start doing some digging. Appreciated the information. Alex 2007/4/3, Bruce A Bowling : > > In the MegaSquirt MS-II version, we have implemented a simple form of the > kalman filter known as an "Alpha-Beta-Gamma Tracking Filter". > > http://www.megamanual.com/ms2/alphabeta.htm > > Note that this is just another form of a predictor-corrector algorithm. In > fact, originally we implemented a full-blown kalman filter, but quickly > realized that since all of the sample datapoints had the exact same > statistical error the a-b-g filter implementation would suffice. Full-up KF > are used to determine the best answer for the next state from many different > sources of measurements (with corresponding variances) and process model > sources. > > Tracking filters are used everywhere, from missle track determination, > machine vision, to brushless commutation of DC motors. A side benefit is > that they are extremely easy to implement and are not very computationally > intensive - in fact they can be easily synthesized in programmable logic. > > - Bruce > > > > > -----Original Message----- > >From: Mike > >Sent: Apr 3, 2007 8:58 AM > >To: diy_efi at diy-efi.org > >Subject: Re: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage > > > >At 08:15 PM 4/3/07, you wrote: > >>Hello, > >> > >>I'm using a microcontroller with standard CAPTURE/COMPARE units in order > to > >>process a 60-2 crank wheel. I'm very concerned about noise and a single > step > >>Kalman Filter seems to be a very good tool for this application. > > > >Not sure what u mean by a "60-2" though if you are not using it for > synchronism > >of fuel/ignition and only for a speed rpms derivation - albeit a good one > then it might be ok. > > > >>Does anybody have experience with that? Could you please point me to > some > >>articles or information on how that particular application of Kalman > could > >>be implemented? Is it really efficient as it sounds like? > > > >Ive used a multistage kalman filter in a nucleonic ore flow gauge project > where > >two Co60 beams and counters measured mass flow rate of ore by absorption. > >ie. Trying to data process two normal curves as they were affected by > falling ore > >and gravity was my first foray into 16 bit micros in 1980 or so. It was a > bit over > >my head but I struggled through it and we made the system work fine > though we did > >bring in a specialist mathematician from India's mining industry to lend > a hand, his > >command of english emabrrased us poor colloquial cohorts ! > > > >They were reasonably effective and the various coefficients and post > processing supplied a total > >flow rate that was within 1 to 3% *but* the short term accuracy was not > better > >than 20% or so as the various state variables took many cycles to clear > or rather > >'impose' their accumulations on the overall flow rate. > > > >In other words I feel it not appropriate to use Kalman for speed > measurements > >and definitely nor for anything requiring any synchronicty at all under > any circumstances. > > > > > >>I'm still reading the basic literature about Kalman and Statistics. > > > >it was tough for me 26 years ago, > > > >I think you wont need it if you can address the h/w issue with respect to > noise such > >as cable routine, impedance of sensors, screening etc > > > >Eg. The Crank signal for the EFI and ignition for an RB30 motor is passed > in parallel more > >or less with the spark wiring loom for a few cms, it might blow the odd > sensor but doesnt seem to affect > >noise on a cycle by cycle basis. ie The ignition is smooth and stable for > working > >sensors that dont get too hot... > > > >rgds > > > >Mike > > > > > > > > > >>Much appreciated. > >>Alex > >>_______________________________________________ > >>Diy_efi mailing list > >>Diy_efi at diy-efi.org > >>Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > >>Main WWW page: http://www.diy-efi.org/diy_efi > > > > > > > >Regards from > > > > > >Mike > >Perth, Western Australia > >VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, > guaranteed ! > >Twin tyres for most sedans, trikes and motorcycle sidecars > >http://niche.iinet.net.au > >_______________________________________________ > >Diy_efi mailing list > >Diy_efi at diy-efi.org > >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > >Main WWW page: http://www.diy-efi.org/diy_efi > > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > From niche at iinet.net.au Tue Apr 3 11:37:29 2007 From: niche at iinet.net.au (Mike) Date: Wed, 04 Apr 2007 00:37:29 +0800 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <9389119.1175607409627.JavaMail.root@elwamui-chisos.atl.sa. earthlink.net> References: <9389119.1175607409627.JavaMail.root@elwamui-chisos.atl.sa.earthlink.net> Message-ID: <7.0.1.0.0.20070404002309.0275cdd0@iinet.net.au>> This is needlessly complex and a complete waste of time. You can get the precise timing from the TDC from any optical/magnetic crank sensor by simply counting the pulses....! Used reliably by many systems. If you are worried about noise, then use good hardware (ie. screened leads). Case in point, the Crank Angle Sensor (CAS) (optical) as used on the RB30ET nissan engine. The CAS has 360 pulses per rev plus an index pulse when each cylinder reaches TDC and to discriminate TDC for cyl one, the pulses overlap with an extra pair of "per rev" pulses so the ECU can easily tell that its TDC for cyl 1. No need for any Kalman filter, no need for anything except a bit of NAND/NOR logic and a flip flop. It counts up to 6 for a 6 cyl engine and resets on the next cycle when the pulses overlap with the index, it is sooooo simple, there is no need to take sucessive samples and look for the derivative of a filter coefficient. In other words, where a Kalman filter adjusts its filter coefficient by analysing the rate of change of signal after noise reduction then an outcome is a numerical value for the purpose of feedback/control - it is *not* a discrete trigger !!! For any single chip micro it is computationally intensive and requires a history or rather an 'array' of the data set - it is not designed for a discrete function. In the situation of a crank sensor there is no data except an edge/pulse which the ECU can count and determine by counting pulses when to issue a spark down to 1deg or sometimes better of crank/cam resolution. Me thinks the issue with Kalman filters is like the paradigm of trying to recycle the energy of the back emf from an injector - I viewed the latter of this on the MS group (of which I am a member) and its a complete nonsense, in other words useless and all it does is upset the injector timing... ie. If you try to collect the back emf of the injector coil when its de-energised then you affect the reliability of the closing time... By all means clamp it but to a high enough voltage so it wont affect closing time and just let the few mW of power be dissipated... So calling the circuit for counting a pulse from the cranks sensor a "Kalman Filter" is a complete nonsense... Its a discrete (edge) function not a data value that needs any sort of Kalman algorithm or filter coefficient adjustment or post processing. Cheers Mike At 09:36 PM 4/3/07, you wrote: >In the MegaSquirt MS-II version, we have implemented a simple form of the kalman filter known as an "Alpha-Beta-Gamma Tracking Filter". > >http://www.megamanual.com/ms2/alphabeta.htm > >Note that this is just another form of a predictor-corrector algorithm. In fact, originally we implemented a full-blown kalman filter, but quickly realized that since all of the sample datapoints had the exact same statistical error the a-b-g filter implementation would suffice. Full-up KF are used to determine the best answer for the next state from many different sources of measurements (with corresponding variances) and process model sources. > >Tracking filters are used everywhere, from missle track determination, machine vision, to brushless commutation of DC motors. A side benefit is that they are extremely easy to implement and are not very computationally intensive - in fact they can be easily synthesized in programmable logic. > >- Bruce > > > > >-----Original Message----- >>From: Mike >>Sent: Apr 3, 2007 8:58 AM >>To: diy_efi at diy-efi.org >>Subject: Re: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage >> >>At 08:15 PM 4/3/07, you wrote: >>>Hello, >>> >>>I'm using a microcontroller with standard CAPTURE/COMPARE units in order to >>>process a 60-2 crank wheel. I'm very concerned about noise and a single step >>>Kalman Filter seems to be a very good tool for this application. >> >>Not sure what u mean by a "60-2" though if you are not using it for synchronism >>of fuel/ignition and only for a speed rpms derivation - albeit a good one then it might be ok. >> >>>Does anybody have experience with that? Could you please point me to some >>>articles or information on how that particular application of Kalman could >>>be implemented? Is it really efficient as it sounds like? >> >>Ive used a multistage kalman filter in a nucleonic ore flow gauge project where >>two Co60 beams and counters measured mass flow rate of ore by absorption. >>ie. Trying to data process two normal curves as they were affected by falling ore >>and gravity was my first foray into 16 bit micros in 1980 or so. It was a bit over >>my head but I struggled through it and we made the system work fine though we did >>bring in a specialist mathematician from India's mining industry to lend a hand, his >>command of english emabrrased us poor colloquial cohorts ! >> >>They were reasonably effective and the various coefficients and post processing supplied a total >>flow rate that was within 1 to 3% *but* the short term accuracy was not better >>than 20% or so as the various state variables took many cycles to clear or rather >>'impose' their accumulations on the overall flow rate. >> >>In other words I feel it not appropriate to use Kalman for speed measurements >>and definitely nor for anything requiring any synchronicty at all under any circumstances. >> >> >>>I'm still reading the basic literature about Kalman and Statistics. >> >>it was tough for me 26 years ago, >> >>I think you wont need it if you can address the h/w issue with respect to noise such >>as cable routine, impedance of sensors, screening etc >> >>Eg. The Crank signal for the EFI and ignition for an RB30 motor is passed in parallel more >>or less with the spark wiring loom for a few cms, it might blow the odd sensor but doesnt seem to affect >>noise on a cycle by cycle basis. ie The ignition is smooth and stable for working >>sensors that dont get too hot... >> >>rgds >> >>Mike >> >> >> >> >>>Much appreciated. >>>Alex >>>_______________________________________________ >>>Diy_efi mailing list >>>Diy_efi at diy-efi.org >>>Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >>>Main WWW page: http://www.diy-efi.org/diy_efi >> >> >> >>Regards from >> >> >>Mike >>Perth, Western Australia >>VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! >>Twin tyres for most sedans, trikes and motorcycle sidecars >>http://niche.iinet.net.au >>_______________________________________________ >>Diy_efi mailing list >>Diy_efi at diy-efi.org >>Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >>Main WWW page: http://www.diy-efi.org/diy_efi > >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi Regards from Mike Perth, Western Australia VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! Twin tyres for most sedans, trikes and motorcycle sidecars http://niche.iinet.net.au From bbowling at earthlink.net Tue Apr 3 15:35:06 2007 From: bbowling at earthlink.net (Bruce A Bowling) Date: Tue, 3 Apr 2007 16:35:06 -0400 (EDT) Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage Message-ID: <5728756.1175632507122.JavaMail.root@elwamui-sweet.atl.sa.earthlink.net> > >This is needlessly complex and a complete waste of time. > I think you missed the point. Agreed that the best tach pulse is the actual one (causal), not a predicted one. In fact, the past history of crankwheel pulses does not strictly dictate when the next pulse comes in, and the actual measured crank pulse (corrector) overrides the predicted pulse. Here is a pleasant example. I tie (someone) to a tree and blindfold them. Then I take my fist and punch their face. I throw a new punch once a second, contacting the face each time. I do this for hours (I am really mad). The person who is receiving the blows to the face, after a while, will come to expect (predict) that the next face smash will happen a second after the last one - after all, this is what has happened for the last hour or so. But, in reality the next punch may come sooner, or later, or never - it takes the actual punch to be absolutely sure. Now, back to the crank wheel, if we had the luxury to have a crank wheel with 360 teeth, and a resolution of 1 degree for ignition and spark, then we are golden, just use the actual pulse inputs and correlate events to them. Finished. But, there exists in the real world the situation where there are less teeth on an existing crankwheel. And there exists the possibility where a ign/injection event occurs in-between teeth. In order to accomodate this the need exists to interpolate between teeth. How is this done? A simple way is to predict the desired event point based on the last two teeth time events, i.e. last interval. Works fine. Except when the wheel experiences an acceleration/deceleration. In this case the last interval prediction will not be correct. How much depends on the acceleration, number of teeth, and RPM, and the actual interpolation point. So how do we put in the acceleration component in the prediction? Simply take the rate of the change in computed velocity. Note that these are time-derivatives, requiring storage of past event times, and in most impementations subtractions and divisions. It works fine, but it chews up CPU time - especially for a micro which does not have natine division support. But there is another way - You obtain position, velocity, and acceleration from the a-b-g tracking filter. This is why it is used. No so much for noise elimination, yes there is noise. But events like acceleration are so much more of an effect to the final result. Does it help to add the velocity/acceleration components to the prediction in-between teeth? You bet, and we have real measured engine data to prove it, the error in event timing is reduced when the acceleration component is added. In fact, on every MS-II datalog there is a DTPredErr, which is the prediction error of the next crankwheel tooth update event (remember the face-punching example, this is the error from when one expects the next punch to when it actually happens). And it turns out to be less computationally-intensive, and requires less storage space, to use this form (which is in fact an IIR filter) than to build time differences and perform divisions to determine the acceleration component (see the MS code for details). Again, for high tooth count wheels, this is not required, simple linear prediction works fine. But for low tooth count wheels, having higher-order predictions can help reduce overall timing errors. Also note that errors deviations are greater at low RPMs compared to high RPMs. >Me thinks the issue with Kalman filters is like the paradigm of trying to >recycle the energy of the back emf from an injector - I viewed the latter of >this on the MS group (of which I am a member) and its a complete nonsense, WTF??? The MS hardware does not harvest back-EMF to dump back into the battery. Well, actually, it does during PWM current limit mode (and not final flyback), but not for energy harvesting purposes.... - Bruce From dunvegan at sbcglobal.net Tue Apr 3 15:43:20 2007 From: dunvegan at sbcglobal.net (Rick McLeod) Date: Tue, 3 Apr 2007 13:43:20 -0700 (PDT) Subject: [Diy_efi] weatherpack connectors Message-ID: <318231.23925.qm@web80515.mail.mud.yahoo.com> I am aware of Del-City for these, I ordered some, but they backordered them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I need to repair a cable ASAP and am up the proverbial backorder tree! I'm looking for 4-pin flat male housings and pins. From Steve.Ravet at arm.com Tue Apr 3 16:04:37 2007 From: Steve.Ravet at arm.com (Steve Ravet) Date: Tue, 3 Apr 2007 14:04:37 -0700 Subject: [Diy_efi] weatherpack connectors In-Reply-To: <318231.23925.qm@web80515.mail.mud.yahoo.com> Message-ID: > -----Original Message----- > From: diy_efi-bounces at diy-efi.org > [mailto:diy_efi-bounces at diy-efi.org] On Behalf Of Rick McLeod > Sent: Tuesday, April 03, 2007 3:43 PM > To: diyefi > Subject: [Diy_efi] weatherpack connectors > > I am aware of Del-City for these, I ordered some, but they > backordered them. Does anyone know of another cheap vendor on > 1sy-2sy quantity, I need to repair a cable ASAP and am up the > proverbial backorder tree! > > I'm looking for 4-pin flat male housings and pins. Your GM dealer? Although they'll probably charge you dearly for them. --steve -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. From jimkyser at ieee.org Tue Apr 3 16:07:47 2007 From: jimkyser at ieee.org (Jim Kyser) Date: Tue, 03 Apr 2007 16:07:47 -0500 Subject: [Diy_efi] weatherpack connectors In-Reply-To: <318231.23925.qm@web80515.mail.mud.yahoo.com> References: <318231.23925.qm@web80515.mail.mud.yahoo.com> Message-ID: <4612C223.8030607@ieee.org> MJM National sells weatherpack connectors on eBay. They sell both pre-packaged kits and smaller quantities. Here is a link to their eBay store. They have a 5 pack of those 4 pin connectors for $4 + $1sh and the a 5 pack of the shrouds for $2.50 + $1sh. Pins and terminals are like $2.50 + $1 for shipping for a package of 25. They combine shipping on multiple items. I have bought from them and they ship out quickly. http://stores.ebay.com/MJM-National-Inc_Weather-Pack_W0QQcolZ2QQdirZQ2d1QQfsubZ12QQftidZ2QQtZkm Jim Kyser 1946 Willys CJ-2A w/4.1 liter Buick V6 w/TBI in progress Rick McLeod wrote: > I am aware of Del-City for these, I ordered some, but they backordered them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I need to repair a cable ASAP and am up the proverbial backorder tree! > > I'm looking for 4-pin flat male housings and pins. > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > > From Tim.VanSetten at l-3com.com Tue Apr 3 16:52:16 2007 From: Tim.VanSetten at l-3com.com (Van Setten, Tim @ ACSSD) Date: Tue, 3 Apr 2007 14:52:16 -0700 Subject: [Diy_efi] weatherpack connectors In-Reply-To: <4612C223.8030607@ieee.org> References: <318231.23925.qm@web80515.mail.mud.yahoo.com> <4612C223.8030607@ieee.org> Message-ID: <8846C6D2B241184780AAFD4C43D2B74B5F93F0@LIBERTY.phx.acssd.l-3com.com> Go to http://www.waytekwire.com/ and go to Products, then put in these part #'s. The flat-4 is 38046 & 38047 ($ 0.23 ea and $ 0.44 ea). You have to shop between Del City Wire and Waytek Inc. to get the best prices on these connectors.....Tim. From davida1 at hiwaay.net Tue Apr 3 21:10:56 2007 From: davida1 at hiwaay.net (David Allen) Date: Tue, 3 Apr 2007 21:10:56 -0500 Subject: [Diy_efi] weatherpack connectors References: <318231.23925.qm@web80515.mail.mud.yahoo.com> Message-ID: <001f01c7765e$8dba51f0$d1c2a5a6@yancey.com> If you just nee one or two, check your local Caterpillar dealer, or AGCO dealer. These OEM's use these connectors and dealers usually stock them. David ----- Original Message ----- From: "Rick McLeod" To: "diyefi" Sent: Tuesday, April 03, 2007 3:43 PM Subject: [Diy_efi] weatherpack connectors >I am aware of Del-City for these, I ordered some, but they backordered >them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I need >to repair a cable ASAP and am up the proverbial backorder tree! > > I'm looking for 4-pin flat male housings and pins. > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > From niche at iinet.net.au Wed Apr 4 00:22:18 2007 From: niche at iinet.net.au (Mike) Date: Wed, 04 Apr 2007 13:22:18 +0800 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <5728756.1175632507122.JavaMail.root@elwamui-sweet.atl.sa.e arthlink.net> References: <5728756.1175632507122.JavaMail.root@elwamui-sweet.atl.sa.earthlink.net> Message-ID: <7.0.1.0.0.20070404130449.0275e510@iinet.net.au>> At 04:35 AM 4/4/07, you wrote: >> >>This is needlessly complex and a complete waste of time. >> > >I think you missed the point. Agreed that the best tach pulse is the actual one (causal), not a predicted one. In fact, the past history of crankwheel pulses does not strictly dictate when the next pulse comes in, and the actual measured crank pulse (corrector) overrides the predicted pulse. not in terms of the accurate terminology of the basis for a Kalman filter which is to asses a series of data points and adjust one or more first or second order filter coefficients... What's being done is more akin to basic interpolation albeit with a few smarts, linear or quadratic... >Here is a pleasant example. I tie (someone) to a tree and blindfold them. Then I take my fist and punch their face. I throw a new punch once a second, contacting the face each time. I do this for hours (I am really mad). The person who is receiving the blows to the face, after a while, will come to expect (predict) that the next face smash will happen a second after the last one - after all, this is what has happened for the last hour or so. But, in reality the next punch may come sooner, or later, or never - it takes the actual punch to be absolutely sure. Drives the point but the ready paradigm of violence doesnt help your case ;) I would prefer to think of it as a basket of fruit delivered in round robbin fashion. :) >Now, back to the crank wheel, if we had the luxury to have a crank wheel with 360 teeth, and a resolution of 1 degree for ignition and spark, then we are golden, just use the actual pulse inputs and correlate events to them. Finished. Well most engines (afaik these days) have just that level of resolution or even better. The Crank Angle sensor on a RB30ET motor and the later derivatives have a discrete pulse edge on each deg of its rotation and as its on the cam, then its equivalent to 0.5 degree of crank which is satisfactory. >But, there exists in the real world the situation where there are less teeth on an existing crankwheel. And there exists the possibility where a ign/injection event occurs in-between teeth. In order to accomodate this the need exists to interpolate between teeth. How is this done? A simple way is to predict the desired event point based on the last two teeth time events, i.e. last interval. Works fine. Except when the wheel experiences an acceleration/deceleration. In this case the last interval prediction will not be correct. How much depends on the acceleration, number of teeth, and RPM, and the actual interpolation point. You mean to say the real world of el cheapo crank triggering methods. The technique you are talking about could be termed "divisional instantaneous interpolation" but as there is no filter in respect of first or second order sampled data systems its not a Kalman filter in the truest sense of the word. There are several 'real world' examples of interpolation of a similar paradigm to that which is referred to in resepct of 60 teeth on a crank ring gear that was in use before Kalman... >So how do we put in the acceleration component in the prediction? Simply take the rate of the change in computed velocity. Note that these are time-derivatives, requiring storage of past event times, and in most impementations subtractions and divisions. It works fine, but it chews up CPU time - especially for a micro which does not have natine division support. But there is another way - > >You obtain position, velocity, and acceleration from the a-b-g tracking filter. >This is why it is used. No so much for noise elimination, yes there is noise. But events like acceleration are so much more of an effect to the final result. Ah ha, you might well use a Kalman like technique to arrive at rotational acceleration as a factor to use (perhaps) for additional injection in the same vein as an accelerator pump for carby systems... ie. its "Kalman" like because you use the previous time samples between pulses but you are not using it to change a filter coefficient etc. Your a-b-g filter is really a predictor isnt it ? >Does it help to add the velocity/acceleration components to the prediction in-between teeth? You bet, and we have real measured engine data to prove it, the error in event timing is reduced when the acceleration component is added. In fact, on every MS-II datalog there is a DTPredErr, which is the prediction error of the next crankwheel tooth update event (remember the face-punching example, this is the error from when one expects the next punch to when it actually happens). This raises a question, do you need to know instantaneous changes in rotational acceleration within the 6 deg period of two adjacent crank pulses ? Is it not sufficient to measure the period of time between those 6deg pulses, other than to inject a bit of extra fuel for acceleration, what else do you need it for ? >And it turns out to be less computationally-intensive, and requires less storage space, to use this form (which is in fact an IIR filter) than to build time differences and perform divisions to determine the acceleration component (see the MS code for details). There are easy binary functions of shift/mask/rotate etc which can give a good approximation with little granularity. >Again, for high tooth count wheels, this is not required, simple linear prediction works fine. But for low tooth count wheels, having higher-order predictions can help reduce overall timing errors. Also note that errors deviations are greater at low RPMs compared to high RPMs. Sure, but effectively you are using either linear or quadratic interpolation of a data set, that doesnt automatically make it a Kalman filter, such interpolations have been around before Kalman in analog systems etc >>Me thinks the issue with Kalman filters is like the paradigm of trying to >>recycle the energy of the back emf from an injector - I viewed the latter of >>this on the MS group (of which I am a member) and its a complete nonsense, > >WTF??? The MS hardware does not harvest back-EMF to dump back into the battery. Well, actually, it does during PWM current limit mode (and not final flyback), but not for energy harvesting purposes.... Thank god for that, there was some considerable list noise on MS years ago re that subject, worrying about a few mA here and there, glad its been much simplified, cheers mike Regards from Mike Massen Network Power Systems Lab 08 9444 8961 Mb 0438 048961 Perth, Western Australia * VL/VK & VN/VP/VR GMH Commodore Fuse Rail that wont warp or melt ! * RB30 Skyline/Nissan/VL Milspec ignition drivers with diagnostic features now in economy trials * Twin tyres for most sedans, trikes and motorcycle sidecars * Industrial grade PolyVinyliDeneChloride (PVDC Copolymer) in bulk, the best oxygen and water protective barrier you can find for circuit boards. * Special equipment on offer, 60KVA UPS with large battery cabinet - AUD$12K Web site under construction http://niche.iinet.net.au From bbowling at earthlink.net Wed Apr 4 07:34:36 2007 From: bbowling at earthlink.net (Bruce A Bowling) Date: Wed, 4 Apr 2007 08:34:36 -0400 (GMT-04:00) Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage Message-ID: <19452011.1175690077172.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> > > Drives the point but the ready paradigm of violence doesnt help your case ;) > But it did catch your attention. > >You mean to say the real world of el cheapo crank triggering methods. > Unfortunately, millions of people are stuck with el-cheapo crankwheels. We agree that its not optimal, but for many its the situation they are in. >Ah ha, you might well use a Kalman like technique to arrive at rotational acceleration as a factor >to use (perhaps) for additional injection in the same vein as an accelerator pump for carby systems... > >ie. its "Kalman" like because you use the previous time samples between pulses but you are not >using it to change a filter coefficient etc. Your a-b-g filter is really a predictor isnt it ? > What happens if you have one source of data (namely the crakwheel sensor), thats all you have, that has the same statistical variance, and implement a Kalman configuration? There are no other sources of measurement data, other than the one sensor, yielding the exact same error distribution each and every sample. And a linear prediction of an event into the future as your model? The full Kalman reduces to a simple predictor-corrector method. This was done in the famous example in the Maybeck book, but even this example had a few different sources of measurement. To say that a tracking filter is not simply a reduced form of a Kalman filter is incorrect, and the literature is full of references to this effect. > >This raises a question, do you need to know instantaneous changes in rotational acceleration within >the 6 deg period of two adjacent crank pulses ? > You assume that there is always a high-density tooth count crankwheel available, it's siply not the case with many existing installs. Plenty of 12, 24, and tons of 36 (EDIS) setups out there. Again, they are not optimal, but they exist nontheless. >Is it not sufficient to measure the period of time between those 6deg pulses, other than to >inject a bit of extra fuel for acceleration, what else do you need it for ? A few places where Vdot is required. One is to maintain accurate dwell charging of an induction ignition coil. If a coil requires 2 ms to charge to a given energy level, it will always require this (given potenital, R and L are the same). The Vdot term is used to adjust the turn-on time of the coil such that when the coil discharges in the future it will have charged for the requisite 2 ms. Without this correction insufficient spark energy is delivered (fron real-world experience). Also, the placement of the actual spark event needs to be corrected for acceleration, otherwise there will be spark retard during acceleration due to incorrect placement of the event. Stated again, the amount of error depends on crankwheel configuration, and RPM. I am really not trying to sound like a jerk here, but we have spent over 7 years on the MS system and have researched/implemented many different algorithms. From the real world measured data, for low tooth count wheels a form of interpolation is desired. For high tooth counts it is not. We have settled on a tracking filter mainly because it is easy to implement and the data shows it performs as well as more complicated prediction methods, and is a trivial computation burden with the processor family we have chosen. - Bruce From klaus at Innovate-tech.com Wed Apr 4 10:36:50 2007 From: klaus at Innovate-tech.com (Klaus Allmendinger) Date: Wed, 4 Apr 2007 08:36:50 -0700 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <7.0.1.0.0.20070404130449.0275e510@iinet.net.au>> References: <5728756.1175632507122.JavaMail.root@elwamui-sweet.atl.sa.earthlink.net> <7.0.1.0.0.20070404130449.0275e510@iinet.net.au>> Message-ID: <2C71874F3C26374DB7DBC538FCF82AB2674A37@ITFC1.innovate.com> Mike wrote: - Well most engines (afaik these days) have just that level of resolution or even better. The Crank Angle sensor on a RB30ET motor and the later derivatives have a discrete pulse edge on each deg of its rotation and as its on the cam, then its equivalent to 0.5 degree of crank which is satisfactory. Actually with a cam sensor at 1 degree resolution the crank resolution would be 2 degrees, not 0.5, as the crank rotates twice as fast as the cam. - Klaus From j_holland at btopenworld.com Wed Apr 4 12:25:52 2007 From: j_holland at btopenworld.com (James Holland) Date: Wed, 4 Apr 2007 18:25:52 +0100 Subject: [Diy_efi] RE: 60-2 Toothwheel - Kalman Filter or ( EKF ) usage Message-ID: I only have a Camshaft Position Sensor giving 2 pulses per revolution (TBI). It sounds like this could be a very good implementation for me. However if I'm accelerating wouldn't this be reflected in the MAP value and therefore any ignition retardation would be at least partly accounted for within the timing look up table anyway? Cheers James From jimbutterfield at yahoo.com Wed Apr 4 13:56:04 2007 From: jimbutterfield at yahoo.com (Jim Butterfield) Date: Wed, 4 Apr 2007 11:56:04 -0700 (PDT) Subject: [Diy_efi] weatherpack connectors In-Reply-To: <4612C223.8030607@ieee.org> Message-ID: <350327.71882.qm@web36703.mail.mud.yahoo.com> AWESOME FIND.... Yea jim Jim Kyser wrote: MJM National sells weatherpack connectors on eBay. They sell both pre-packaged kits and smaller quantities. Here is a link to their eBay store. They have a 5 pack of those 4 pin connectors for $4 + $1sh and the a 5 pack of the shrouds for $2.50 + $1sh. Pins and terminals are like $2.50 + $1 for shipping for a package of 25. They combine shipping on multiple items. I have bought from them and they ship out quickly. http://stores.ebay.com/MJM-National-Inc_Weather-Pack_W0QQcolZ2QQdirZQ2d1QQfsubZ12QQftidZ2QQtZkm Jim Kyser 1946 Willys CJ-2A w/4.1 liter Buick V6 w/TBI in progress Rick McLeod wrote: > I am aware of Del-City for these, I ordered some, but they backordered them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I need to repair a cable ASAP and am up the proverbial backorder tree! > > I'm looking for 4-pin flat male housings and pins. > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > > _______________________________________________ Diy_efi mailing list Diy_efi at diy-efi.org Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi Main WWW page: http://www.diy-efi.org/diy_efi --------------------------------- Don't get soaked. Take a quick peek at the forecast with theYahoo! Search weather shortcut. From chris at ourtoyz.com Wed Apr 4 21:18:52 2007 From: chris at ourtoyz.com (Chris Walsh) Date: Wed, 4 Apr 2007 21:18:52 -0500 Subject: [Diy_efi] weatherpack connectors In-Reply-To: <001f01c7765e$8dba51f0$d1c2a5a6@yancey.com> Message-ID: Another place to check would be a heavy truck dealership. I work at a Peterbilt dealership & we stock that stuff all the time. Well except the 12ga terminals. Chris "If you just nee one or two, check your local Caterpillar dealer, or AGCO dealer. These OEM's use these connectors and dealers usually stock them. David" From niche at iinet.net.au Thu Apr 5 11:45:25 2007 From: niche at iinet.net.au (Mike) Date: Fri, 06 Apr 2007 00:45:25 +0800 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <19452011.1175690077172.JavaMail.root@elwamui-wigeon.atl.sa .earthlink.net> References: <19452011.1175690077172.JavaMail.root@elwamui-wigeon.atl.sa.earthlink.net> Message-ID: <7.0.1.0.0.20070405235048.026f5dd0@iinet.net.au>> At 08:34 PM 4/4/07, you wrote: >> >> Drives the point but the ready paradigm of violence doesnt help your case ;) >> > >But it did catch your attention. Explanation of the core issue would be quite sufficient thanks, Some ancient Sufi philosophy has something pertinent to report about the proclivity and type of analogies chosen by 'some' people to illustrate a specialised thought process in the assumption the intended is a complete ass driven more by shock and awe emotion and without cognition of the potentials, but then, I digress... Nuff said. :o) >>You mean to say the real world of el cheapo crank triggering methods. >> > >Unfortunately, millions of people are stuck with el-cheapo crankwheels. We agree that its not optimal, but for many its the situation they are in. Ok sure, there are many ways to approach this, some darwinian as you have no doubt observed over some 7 years and some rather more directed with precise knowledge of information theory and combinatorial methods of binary centric functions and relations ;) >>Ah ha, you might well use a Kalman like technique to arrive at rotational acceleration as a factor >>to use (perhaps) for additional injection in the same vein as an accelerator pump for carby systems... >> >>ie. its "Kalman" like because you use the previous time samples between pulses but you are not >>using it to change a filter coefficient etc. Your a-b-g filter is really a predictor isnt it ? > >What happens if you have one source of data (namely the crakwheel sensor), thats all you have, that has the same statistical variance, and implement a Kalman configuration? There are no other sources of measurement data, other than the one sensor, yielding the exact same error distribution each and every sample. And a linear prediction of an event into the future as your model? The full Kalman reduces to a simple predictor-corrector method. This was done in the famous example in the Maybeck book, but even this example had a few different sources of measurement. To say that a tracking filter is not simply a reduced form of a Kalman filter is incorrect, and the literature is full of references to this effect. Its interesting you have brought this up as I have considerable experience of statistical variance in measurement methods in respect of nucleonic mass flow ore gauges, back then foxboro controllers didnt like much hence the need for an intermediate step, but if I elaborated on that I might be accused of saying "size does matter" and I'm not in a boasting mood today ;) Suffice it to say, that assuming best attention to physical layer, then comms layer will have miniscule statistical variance in a (mostly) deterministic process such as an internal combustion engine and the instantaneous changes in rotational velocity of the crank tooth gear assembly which forms the core of our attention. In other words, the 6 deg toothed gear pulse is adequate to gauge engine state or rather impending engine 'change' of state. The rush and it appears an overly complex rush to the notion of a Kalman filter as the base reference is tangential to a really simple algorithm to interpolate the best guess for the start of dwell for an ignition event, ie I stand by my earlier comment, its needlessly complex and I will add that a simple binary interpolation will do and easy to add a accel add/sub factor. Its not as esoteric as a "predictor" implies, its a simple term in a bit of late high school algebra, lets not make it sound like its a basis for a fields medal... >>This raises a question, do you need to know instantaneous changes in rotational acceleration within >>the 6 deg period of two adjacent crank pulses ? >> > >You assume that there is always a high-density tooth count crankwheel available, it's siply not the case with many existing installs. Plenty of 12, 24, and tons of 36 (EDIS) setups out there. Again, they are not optimal, but they exist nontheless. Ok fine, these are conversions I am guessing from non-efi to efi type systems where performance in respect of power is ahead of that of emissions and as an experimental/educational basis for the participants not necessarily as a plan to take over the control systems of all lesser beasts for some commercial marketing plan to replace earlier analog controllers en masse ! >>Is it not sufficient to measure the period of time between those 6deg pulses, other than to >>inject a bit of extra fuel for acceleration, what else do you need it for ? > > >A few places where Vdot is required. One is to maintain accurate dwell charging of an induction ignition coil. If a coil requires 2 ms to charge to a given energy level, it will always require this (given potenital, R and L are the same). The Vdot term is used to adjust the turn-on time of the coil such that when the coil discharges in the future it will have charged for the requisite 2 ms. Without this correction insufficient spark energy is delivered (fron real-world experience). Few points, a. It cannot be accurate it is probabilistic and subject to jitter from one crank cycle to the next & subject to quality of algorithm b. If the progenitor is really interested in precision then throw away the 60+2 crank and use a 1deg or better reference, there is no point in stretching the asymptote of best design indefinitely if the core measurement method has low resolution and many unplanned events such as detonation/preignition/fuel type etc can upset any prediction and on a non deterministic basis too ! c. Do we want to be absorbed and engaged in others attempts to extract reliability from an inherently low resolution measurement method in concert with a fundamentally chaotic source of energy with potentially huge variance re long term issues such as wear, noise, owners treatment, value of ones intellectualizing where size of ones interest/ego is not relevant etc *grin* Therefore, if it was my engine, I would throw away, or rather not use the 60+2 crank timing except as private entertainment and great method to either create a mausoleum to my time on earth or enjoy the effect it has on further isolating me from non technical female company, no I do not fear success in that regard but I must observe it does affect many of my colleagues... So I would opt for either a different engine with inherently better EFI based sensors or cast aside the sentimentality of an older rotating piece of aluminium and steel in favour of said non technical female companionship. Thus solving the problem at both ends :) Sorry, to clarify, choose a better engine or attach a better sensor, Audi had something to say about if I recall 10 years ago ! >Also, the placement of the actual spark event needs to be corrected for acceleration, otherwise there will be spark retard during acceleration due to incorrect placement of the event. Stated again, the amount of error depends on crankwheel configuration, and RPM. No need for any kalman or kalman like *filter*, it is needlessly complex as it starts from the wrong end of the problem. Start with the issue of linear interpolation *and* add/subtract a factor based on y=mx+b from the graph of rotational velocity vs time for the last 3 "or so" 6 deg pulse events gated through a suitably high enough base clock and counter which almost all micros have in abundance. AND I might *add* that judicious selection of the clock rate, in concert with rpm range and mass of engine in respect of range of rotational acceleration acceptable might well, with the aid of optimised binary centric code allow ones timing "fudge" factor to pop out, as it were without regard to any notion of Kalman filtering or even reliance on any sort of complex and timing consuming maths, ie. Start with interpolation, add/sub rate of change factor and do a table lookup to save time, gawd knows table lookup is far more efficient and effective when granularity issues corrected than the time take in maths... ie I dont need a divide waster...! >I am really not trying to sound like a jerk here, but we have spent over 7 years on the MS system and have researched/implemented many different algorithms. From the real world measured data, for low tooth count wheels a form of interpolation is desired. For high tooth counts it is not. We have settled on a tracking filter mainly because it is easy to implement and the data shows it performs as well as more complicated prediction methods, and is a trivial computation burden with the processor family we have chosen. Sorry I probably sound like a smug jerk already but what you really mean in above para is its taken 6.9 years to talk about and identify the problem for old crank style timing and 0.1 years to act on it, though it might have been attempted at various levels prior to precise identifications resulting in a usable outcome, such darwinian approach is interesting if you have a fundamentalist approach to the philosophy of technical knowledge but my interest in mystical anthropology gets in the way ;) In other words religious literalism in defiance of darwinianism is a lost cause in relation to diversity of technical methods... In my (commercial) experience and that means having to clearly identify the issue and think it through solidly over a couple of days means it should take a month or so of real effort to arrive at a practical (prototype) outcome allowing for coding, testing and critical judgement in respect of market suitability. 7 years seems like a political problem and has never been approached (as if) a strict commercial outcome was any sort of intention... I could have shortcutted the above diatribe by saying:- 1. Test the system with basic linear interpolation in a non anthropic environment. ie NO placebo possible effect. 2. Switch on the acceleration add/sub factor as per y=mx+b and test again, re 1 above. 3. Compare results and please forget using the word Kalman - in this case it will lead you astray and take up time... Settle on it as an experience and move on to something more interesting and challenging, and if you really want to make things work well on an ICE, then remove any basic imprecise measurement methods such as 60+2 and use better sensors to the CPU time can attend it self o goal seeking behavioous both short and long term for emissions and fuel economy, in other words get a handle on information theory and maybe Godel if you have the patience ;) ie. ICE's have chaotic source of energy by first principle, to remove the potential for such core chaotic behaviour to ripple through a sampled data system and cause discontinuities affecting control system stabilities one must focus on highest resolution sensors, CPU's with sufficient power for crank by crank goal seeking and sufficient memory for logging and long term goal seeking driver related responses, interfaces etc... I'll go back to sleep now for easter, cheers Regards from Mike Massen Network Power Systems Lab 08 9444 8961 Mb 0438 048961 Perth, Western Australia * VL/VK & VN/VP/VR GMH Commodore Fuse Rail that wont warp or melt ! * RB30 Skyline/Nissan/VL Milspec ignition drivers with diagnostic features now in economy trials * Twin tyres for most sedans, trikes and motorcycle sidecars * Industrial grade PolyVinyliDeneChloride (PVDC Copolymer) in bulk, the best oxygen and water protective barrier you can find for circuit boards. * Special equipment on offer, 60KVA UPS with large battery cabinet - AUD$12K Web site under construction http://niche.iinet.net.au From niche at iinet.net.au Thu Apr 5 11:46:52 2007 From: niche at iinet.net.au (Mike) Date: Fri, 06 Apr 2007 00:46:52 +0800 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <2C71874F3C26374DB7DBC538FCF82AB2674A37@ITFC1.innovate.com> References: <5728756.1175632507122.JavaMail.root@elwamui-sweet.atl.sa.earthlink.net> <7.0.1.0.0.20070404130449.0275e510@iinet.net.au> <2C71874F3C26374DB7DBC538FCF82AB2674A37@ITFC1.innovate.com> Message-ID: <7.0.1.0.0.20070406004530.026ff4d0@iinet.net.au>> You are quite right of course, I had it tother way round, As it happens the crank sensor has 0.5 deg resolution as it uses rising and falling edges which means 1deg crank, interesting, thanks for the observation, well taken :) Cheers Mike At 11:36 PM 4/4/07, you wrote: >Mike wrote: >- Well most engines (afaik these days) have just that level of >resolution or even better. >The Crank Angle sensor on a RB30ET motor and the later derivatives have >a discrete pulse edge on each deg of its rotation and as its on the cam, >then its equivalent to 0.5 degree of crank which is satisfactory. > > >Actually with a cam sensor at 1 degree resolution the crank resolution >would be 2 degrees, not 0.5, as the crank rotates twice as fast as the >cam. > >- Klaus > > > >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi Regards from Mike Perth, Western Australia VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! Twin tyres for most sedans, trikes and motorcycle sidecars http://niche.iinet.net.au From niche at iinet.net.au Thu Apr 5 11:48:06 2007 From: niche at iinet.net.au (Mike) Date: Fri, 06 Apr 2007 00:48:06 +0800 Subject: [Diy_efi] RE: 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <5klkl8$o4892e@iinet-mail.icp-qv1-irony2.iinet.net.au> References: <5klkl8$o4892e@iinet-mail.icp-qv1-irony2.iinet.net.au> Message-ID: <7.0.1.0.0.20070406004712.026f6450@iinet.net.au>> At 01:25 AM 4/5/07, you wrote: >I only have a Camshaft Position Sensor giving 2 pulses per revolution (TBI). >It sounds like this could be a very good implementation for me. However if >I'm accelerating wouldn't this be reflected in the MAP value and therefore >any ignition retardation would be at least partly accounted for within the >timing look up table anyway? 2 ppr ! Er no, Do you have a ring gear, can you rig up a hall effect on it ? What does your ignition now, why not just finesse that side ? Cheers Mike >Cheers >James > >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi Regards from Mike Perth, Western Australia VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! Twin tyres for most sedans, trikes and motorcycle sidecars http://niche.iinet.net.au From bbowling at earthlink.net Thu Apr 5 14:03:09 2007 From: bbowling at earthlink.net (Bruce A Bowling) Date: Thu, 5 Apr 2007 15:03:09 -0400 (EDT) Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage Message-ID: <26046889.1175799789373.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> >Its interesting you have brought this up as I have considerable experience of statistical variance in measurement methods >in respect of nucleonic mass flow ore gauges, back then foxboro controllers didnt like much hence the need for an >intermediate step, but if I elaborated on that I might be accused of saying "size does matter" and I'm not in a boasting mood today ;) > I also have considerable experience in stochasic estimation and robust control, both in my graduate work and direct implementation in particle beam accelerator trajectory control with 10,000 control elements and measurement points, with results published in numerous physics journals. The thing about electron-beam accelerators is that you have only one chance to get it right, otherwise you will destroy a multi-billon dollar facility. But again, size does not matter.... >In other words, the 6 deg toothed gear pulse >is adequate to gauge engine state or rather impending engine 'change' of state. The rush and it appears an overly complex >rush to the notion of a Kalman filter as the base reference is tangential to a really simple algorithm to interpolate the best >guess for the start of dwell for an ignition event, ie I stand by my earlier comment, its needlessly complex and I will add >that a simple binary interpolation will do and easy to add a accel add/sub factor. Its not as esoteric as a "predictor" implies, >its a simple term in a bit of late high school algebra, lets not make it sound like its a basis for a fields medal... > Going back to the original answer to request for information on Kalman filtering, the response was to look at a tracking filter. Take a look at this link: http://www.acfr.usyd.edu.au/teaching/4th-year/mech4721-Signals/material/lecture%20notes/16%20Range%20Tracking.pdf At the top of page 413 (actually page 5 in the pdf), the statement "The alpha-beta tracker is a fixed gain formulation of the Kalman filter and is still widely used because it is easy to implement [and] performs well in general" I will forgo the medal, I will take the cash instead.... Another paper: http://www.ee.ucl.ac.uk/lcs/papers2002/LCS078.pdf (see the end of the first page..) Another one: http://code.eng.buffalo.edu/tracking/papers/tenne_optimalFilter2000.pdf >Few points, >a. It cannot be accurate it is probabilistic and subject to jitter from one crank cycle to the next & subject to quality of algorithm >b. If the progenitor is really interested in precision then throw away the 60+2 crank and use a 1deg or better reference, > there is no point in stretching the asymptote of best design indefinitely if the core measurement method has low resolution > and many unplanned events such as detonation/preignition/fuel type etc can upset any prediction and on a non deterministic basis too ! >c. Do we want to be absorbed and engaged in others attempts to extract reliability from an inherently low resolution measurement > method in concert with a fundamentally chaotic source of energy with potentially huge variance re long term issues such as > wear, noise, owners treatment, value of ones intellectualizing where size of ones interest/ego is not relevant etc > Actually, this is correct. As stated before, higher tooth densities are desired. When interpolation is involved, its just guesswork between the tooth positions. And if there are rotational rates of change then there will be error. If I guess with a tracking filter, linear/quadratic interpolation, etc. its just a guess. I will say that if I was also to implement a crankwheel I would use as high a tooth count as possible. In fact, I find it interesting to see ignition controller specs that advertise "0.1 degree timing accuracy". And at crank tooth update points this may be close (probably not so for other reasons). But you will never see this stated as "0.1 degree timing accuracy over all engine operating ranges". What I need to do is dig up the mathematical error analysis we performed on crank position estimation a while back (posted on the MS forums), alomg with real measurement results, compared to linear last interval and rate-of-change of last interval (which was originally performed in the code). Also the fact that the tracking filter takes under 4 usec to totally complete on aq 24 MHz HCS12 (contrast this to the fact that at 10,000 RPM a one-degree crank angle takes 16.6 usec). Again, for high tooth count wheels the code defaults to last interval and does not use this calculation. And, everyone running MS-IIs right has the capability of performing their own experiment right now. One runtime variable available is the "TimingErr" variable. This is the subtraction of the predicted next-tooth time from the actual next-tooth arrival time, converted to crankshaft degrees. The coefficients alpha,beta,gamma can be adjusted in real time. The gamma value is the one that introduces feed-forward for rotational acceleration prediction. All they have to do is turn on a datalog, run the engine, then plot the results in MLV. Do not be surprised when you see +/- 10 degrees of error in timing for low tooth count wheels at low RPM.... The one thing I have dropped a few times here but no one has questioned is why is there more error at low RPMs? - Bruce From tsokorai at gmail.com Thu Apr 5 14:24:23 2007 From: tsokorai at gmail.com (Tomas Sokorai) Date: Thu, 5 Apr 2007 15:24:23 -0400 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <26046889.1175799789373.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> References: <26046889.1175799789373.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Message-ID: <8634c6d70704051224h1cc36827t32180b86ead9b786@mail.gmail.com> On 4/5/07, Bruce A Bowling wrote: > The one thing I have dropped a few times here but no one has questioned is why is there more error at low RPMs? Very non-linear deceleration/acceleration from the compression and combustion events? And the rotational inertia (flywheel/rotational assy.) is too low at these RPMs to dampen these accel/decel pulses ? -- Tomas J. Sokorai Sch. From bbowling at earthlink.net Thu Apr 5 15:48:52 2007 From: bbowling at earthlink.net (Bruce A Bowling) Date: Thu, 5 Apr 2007 16:48:52 -0400 (EDT) Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage Message-ID: <10224151.1175806132490.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> > >I will forgo the medal, I will take the cash instead.... > Lookee what I just found: http://www.mstarlabs.com/software/engine/engspeed.html entitled "Engine Speed Monitoring: The Alpha-Beta Filter. What a great idea..... - Bruce From espresso_doppio at yahoo.com Thu Apr 5 19:57:58 2007 From: espresso_doppio at yahoo.com (Adam Wade) Date: Thu, 5 Apr 2007 17:57:58 -0700 (PDT) Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <26046889.1175799789373.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Message-ID: <905946.52997.qm@web32214.mail.mud.yahoo.com> --- Bruce A Bowling wrote: > The one thing I have dropped a few times here but no > one has questioned is why is there more error at low > RPMs? I'll give that one a shot. :) It's largely the same reason that using speed density at idle without a lot of signal conditioning is a bad idea. Dynamic compression is at its lowest at idle, and spark is at its most retarded as well. Small variances in the homogeneity of the intake mixture can turn into much larger variances in power transmitted to the crank during a power stroke; further, those variances are a much larger percentage of the power output of the engine at idle than the same variances would be if the engine was under load (even as little load as freeway cruise, although then you also have issues with the low manifold pressure and what that does to homogeneity and flame front propagation). AND, if you are using a reluctor as your pickup, you not only have lower peak voltage as signal out, but you have a shallower (slower) voltage rise/fall on the leading/trailing edge of the tooth passing the reluctor. You'd need to do a really nice job of figuring out where the crossover is made from non-triggered to triggered (and any minute changes in crank speed because of inconsistencies with idle power from cylinder to cylinder will change the slope as well as the peak, and you have to have some way to determine when the signal indicates the tooth has actually passed its trigger point). So that too (and it would be wonderful to make a Hall-effect rig with a wheel that had about 100 tiny magnets on it, but I don't know if that would be feasible or not). I could use the cash, but I'll settle for the medal you don't want -- assuming I got it right. ;) | Kawasaki Zephyr 615 (Daphne) Kawasaki Zephyr 550 (Velma)| | "It was like an emergency ward after a great catastrophe; it | | didn't matter what race or class the victims belonged to. | | They were all given the same miracle drug, which was coffee. | | The catastrophe in this case, of course, was that the sun | | had come up again." -Kurt Vonnegut | | M/C Fuel Inj. Hndbk. @ Amazon.com - http://tinyurl.com/6o3ze | ____________________________________________________________________________________ Sucker-punch spam with award-winning protection. Try the free Yahoo! Mail Beta. http://advision.webevents.yahoo.com/mailbeta/features_spam.html From gpbeau at cox.net Thu Apr 5 21:51:36 2007 From: gpbeau at cox.net (Garrett P. Beauregard) Date: Thu, 5 Apr 2007 19:51:36 -0700 Subject: [Diy_efi] weatherpack connectors In-Reply-To: <318231.23925.qm@web80515.mail.mud.yahoo.com> Message-ID: Most NAPA auto parts stores carry the Weatherpack connectors. In case your counterman isn't familiar with them, they are in their Packard Electric catalog. If the store doesn't have them, their local warehouse does. Prices are reasonable for same-day availability. Garrett -----Original Message----- From: diy_efi-bounces at diy-efi.org [mailto:diy_efi-bounces at diy-efi.org]On Behalf Of Rick McLeod Sent: Tuesday, April 03, 2007 1:43 PM To: diyefi Subject: [Diy_efi] weatherpack connectors I am aware of Del-City for these, I ordered some, but they backordered them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I need to repair a cable ASAP and am up the proverbial backorder tree! I'm looking for 4-pin flat male housings and pins. _______________________________________________ Diy_efi mailing list Diy_efi at diy-efi.org Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi Main WWW page: http://www.diy-efi.org/diy_efi From niche at iinet.net.au Fri Apr 6 00:42:12 2007 From: niche at iinet.net.au (Mike) Date: Fri, 06 Apr 2007 13:42:12 +0800 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <26046889.1175799789373.JavaMail.root@elwamui-hound.atl.sa. earthlink.net> References: <26046889.1175799789373.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Message-ID: <7.0.1.0.0.20070406131004.026f9990@iinet.net.au>> At 03:03 AM 4/6/07, you wrote: >I also have considerable experience in stochasic estimation and robust control, both in my graduate work and direct implementation in particle beam accelerator trajectory control with 10,000 control elements and measurement points, with results published in numerous physics journals. The thing about electron-beam accelerators is that you have only one chance to get it right, otherwise you will destroy a multi-billon dollar facility. But again, size does not matter.... Excellent, since we both have direct experience of systems and techniques far more complex than that required by a 60 tooth crank wheel trigger then it must be clear that references to Kalman like filtering are needlessly complex... >>In other words, the 6 deg toothed gear pulse >>is adequate to gauge engine state or rather impending engine 'change' of state. The rush and it appears an overly complex >>rush to the notion of a Kalman filter as the base reference is tangential to a really simple algorithm to interpolate the best >>guess for the start of dwell for an ignition event, ie I stand by my earlier comment, its needlessly complex and I will add >>that a simple binary interpolation will do and easy to add a accel add/sub factor. Its not as esoteric as a "predictor" implies, >>its a simple term in a bit of late high school algebra, lets not make it sound like its a basis for a fields medal... >> > >Going back to the original answer to request for information on Kalman filtering, the response was to look at a tracking filter. Although the initial poster thought that a Kalman filter 'might' be suitable, the more appropriate response might be to steer him or rather rotate the paradigm away from Kalman ;) and just start with linear interpolation and when that works and he is comfortable with it that he then add a term to fit change of velocity over time to obtain a y=mx+b form which he can apply to the next interval to calculate the ignition point. ie No need for any filter. >http://www.acfr.usyd.edu.au/teaching/4th-year/mech4721-Signals/material/lecture%20notes/16%20Range%20Tracking.pdf > >At the top of page 413 (actually page 5 in the pdf), the statement "The alpha-beta tracker is a fixed gain formulation of the Kalman filter and is still widely used because it is easy to implement [and] performs well in general" > >I will forgo the medal, I will take the cash instead.... Link is of some interest. But its still way over the top of whats needed and isnt necessary to entertain any Kalman keywords at all for the purpose of name dropping ;-) Like Customs Brokers, they make things so overly complex and charge $200 (mostly) for finding an HTS... >Another paper: http://www.ee.ucl.ac.uk/lcs/papers2002/LCS078.pdf (see the end of the first page..) > >Another one: http://code.eng.buffalo.edu/tracking/papers/tenne_optimalFilter2000.pdf Yes mostly really nice links of an academic ilk, way over that needed for the 60 tooth crank 'problem'... I would have thought... Though interesting reading, tah :) >Actually, this is correct. As stated before, higher tooth densities are desired. When interpolation is involved, its just guesswork between the tooth positions. And if there are rotational rates of change then there will be error. If I guess with a tracking filter, linear/quadratic interpolation, etc. its just a guess. The thing is the type of instantaneous change of rotational acceleration wont be high enough to be a factor at all unless there is detonation I would expect, or is there any data log from an MS to suggest it will that such a 3rd order might be relevant, 2nd order would be ok though, and grabbing the previous 3 samples of counts between the teeth will either be a (rough) straight line or a parabola etc with some minimal potential other curves in between but the need for a filter seems to add if anything a complexity of terminology to a detail which will absorb a huge amount of time with doubtful practical import. >I will say that if I was also to implement a crankwheel I would use as high a tooth count as possible. In fact, I find it interesting to see ignition controller specs that advertise "0.1 degree timing accuracy". And at crank tooth update points this may be close (probably not so for other reasons). But you will never see this stated as "0.1 degree timing accuracy over all engine operating ranges". mmmm, me think sales speak has probably got into those specs or the dot on the line isnt a decimal.... ;) Or the interpolator is a salesman since its easier to sell then design a good interpolator or is a simplistic division of background cycle rate with roational speed to acquire knowledge of engine state at 0.1 deg intervals etc ! >What I need to do is dig up the mathematical error analysis we performed on crank position estimation a while back (posted on the MS forums), alomg with real measurement results, compared to linear last interval and rate-of-change of last interval (which was originally performed in the code). Also the fact that the tracking filter takes under 4 usec to totally complete on aq 24 MHz HCS12 (contrast this to the fact that at 10,000 RPM a one-degree crank angle takes 16.6 usec). Again, for high tooth count wheels the code defaults to last interval and does not use this calculation. mmm, I am guessing that a linear interpolation and table lookup for accel/decel add/sub would be far quicker and use less register space & memory etc ? >And, everyone running MS-IIs right has the capability of performing their own experiment right now. One runtime variable available is the "TimingErr" variable. This is the subtraction of the predicted next-tooth time from the actual next-tooth arrival time, converted to crankshaft degrees. The coefficients alpha,beta,gamma can be adjusted in real time. The gamma value is the one that introduces feed-forward for rotational acceleration prediction. All they have to do is turn on a datalog, run the engine, then plot the results in MLV. Do not be surprised when you see +/- 10 degrees of error in timing for low tooth count wheels at low RPM.... mmmm, yes understood and has anyone done any blind trials re drivability, ie classic experimental trial. Eg. Driver ONE is faced with 4 buttons on console, button 1 selects just linear, button 2 selects accel/decel, button 3 turns on a light and selects linear button 4 turns on a different light and selects accel/decel. then a course is traversed, cruise, hill, start, stop, gentle drive, hard acceleration etc etc Then buttons are randomised (but recorded separately) and Driver TWO does same course Maybe if time do again for Driver THREE and FOUR. Map qualitative perceptions and any quantitative results like fuel consumption, number of engine cycles etc and prepare a stat table of all drivers, their buttons, the actual resulting software setting of linear interpolation vs accel/decel. amendment etc Thus gaining a perspective on the practical value of such a correction and its effect on fuel, drivability, engine wear etc >The one thing I have dropped a few times here but no one has questioned is why is there more error at low RPMs? Saw a few other comments, all make sense re static compression, good thing Adam didnt slap his forehead that time ;) *grin* Have a nice easter everyone, Regards from Mike Perth, Western Australia VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! Twin tyres for most sedans, trikes and motorcycle sidecars http://niche.iinet.net.au From bernie at innovative.iinet.net.au Fri Apr 6 01:31:52 2007 From: bernie at innovative.iinet.net.au (Bernd Felsche) Date: Fri, 6 Apr 2007 14:31:52 +0800 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <7.0.1.0.0.20070406131004.026f9990@iinet.net.au> References: <26046889.1175799789373.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> <7.0.1.0.0.20070406131004.026f9990@iinet.net.au>> Message-ID: <200704061431.52086@death.2.spammers> On Friday 06 April 2007 13:42, Mike wrote: > Bruce A Bowling wrote: > >Going back to the original answer to request for information on > >Kalman filtering, the response was to look at a tracking filter. > Although the initial poster thought that a Kalman filter 'might' > be suitable, the more appropriate response might be to steer him > or rather rotate the paradigm away from Kalman ;) and just start > with linear interpolation and when that works and he is > comfortable with it that he then add a term to fit change of > velocity over time to obtain a y=mx+b form which he can apply to > the next interval to calculate the ignition point. ie No need for > any filter. I tend to agree. The necessary resolution isn't that fine especially given the variability of the actual ignition event and taht of actual injected fuel and ingested air quantities. My perception of the problem however digresses from the norm in that I consider the events to be triggered at a particular time relative to a datum. An ignition event is largely determined by time; and not by crank angle. (*) In order to maximise BMEP, the pressure profile of the combustion/expansion is at a particular time after the datum (e.g. TDC) for a given engine speed. (*) complications occur due to changes in mixture, airflow and other detected events. Some time ago, when I thought that I had much more time on my hands, (Though not 7 years!) I drafted http://bernd.felsche.org/tech/EFI/vapour/Resources.html based on a simple, 8-bit RISC microcontroller. Event timing is explained under Timer/Counter utilisation. Ignition and timing events are by comparison registers the cause interrupts when they match the main system free-running 16-bit timer/counter. The advantage of this is that the crank "resolution" at low engine speeds is very high, but in reality, due to compression, combustion, crankshaft vibrations, distributor drive flexibility, etc, the quality of the resolution isn't as high as the counter numbers would have one wish... The values are only a straight linear interpolation to expected events. They get "updated" every half crank revolution but that is not sufficient to determine a usable velocity profile; given only the one pulse (with up and down edges) per half rev. -- /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | "If we let things terrify us, X against HTML mail | life will not be worth living." / \ and postings | Lucius Annaeus Seneca, c. 4BC - 65AD. From j_holland at btopenworld.com Fri Apr 6 11:54:45 2007 From: j_holland at btopenworld.com (James Holland) Date: Fri, 6 Apr 2007 17:54:45 +0100 Subject: [Diy_efi] RE: 60-2 Toothwheel - Kalman Filter or ( EKF ) Message-ID: > >I only have a Camshaft Position Sensor giving 2 pulses per revolution > (TBI). > >It sounds like this could be a very good implementation for me. However > if > >I'm accelerating wouldn't this be reflected in the MAP value and > therefore > >any ignition retardation would be at least partly accounted for within > the > >timing look up table anyway? > > 2 ppr ! Well that's the stock set up, Suzuki Vitara 1.6 8V with TBI. The distributor has a hall effect sensor with four cut outs on the vane. The 16V engine had the same distributor set up but with a Crank Sensor(1ppr) to enable the injection to be synchronized. > > Er no, > Well its not a performance engine, however your current debate raised a few interesting points and got me wondering whether there was any noticeable improvement that could be effected. > > Do you have a ring gear, can you rig up a hall effect on it ? > Later Zuks have a distributorless set up with a different sensor arrangement, I may be able to adapt that. > What does your ignition now, why not just finesse that side ? > Well on the Vit is currently the stock DSM ECU. I also have an earlier Zuk with an 8V carb engine, that's pretty much electronic points - VR sensor and Schmitt trigger, advance is mechanical/vacuum. I intend to experiment a bit with that engine. The ignition I'm intending to use will use the 2 ppr distributor from the Vit. I have a 16 x 16 look up table and use linear interpolation. That should get me started, of course I did just pick up 4 COP units very cheaply :-) Cheers James From bbowling at earthlink.net Fri Apr 6 15:34:21 2007 From: bbowling at earthlink.net (Bruce A Bowling) Date: Fri, 6 Apr 2007 16:34:21 -0400 (GMT-04:00) Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage Message-ID: <32557244.1175891662044.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> > >mmm, I am guessing that a linear interpolation and table lookup for accel/decel add/sub would be far quicker and use less >register space & memory etc ? > Guess again. Here is the actual implementation: errt = dt3[ICint] - dtpred; .... // alpha-beta-gamma filter prediction dts = dtpred + ((inpram.alpha * errt)); tddts = tddtpred + ((inpram.beta * errt)); t2dddts = t2dddts + ((inpram.gamma * errt)); dtpred = dts + tddts + t2dddts ; tddtpred = tddts + t2dddts; Three multiplies, 6 additions, one subtraction. One temporary storage location. No division. The 'alternative' method is to use a Mx + B form, with a table search lookup to find a acceleration factor to apply. First build up "M" (time derivative). Can be done with time period calculation subtaction, current point from previous. Save result. Next, take another subtraction to determine the change between the last delta_t and this one, and use to perform table lookup function. This means a loop and comparing a value against a list of values (note that this list lives in memory, taking up space). When the value is bracketed, grab the factor and either add or multiply, depending on implementation. This "list" needs to be sufficiently populated to deal with the wide range of possible correction values required for the range of delta-t's experienced. Anywhere from a few microseconds up. The more values the more potential checks and the more memory space required to hold the compared values and the factors. Go ahead and implement this. Then deal with the fact that either the "factors" are coarsely-spaced to save memory and hence the acceleration error will build up (integral windup, been there, done that), or the table becomes huge with lots of comparisons. Also - in an earlier you stated that a predictor-corrector setup was not needed. Guess what? The "Mx + B" is really an linear interpolation, using two measured points to predict an event into the future. And the two last obtained points are the correction update. You have just come up with a predictor-corrector scheme. But then you said it is not needed. But here it is nonetheless. - Bruce From bbowling at earthlink.net Fri Apr 6 15:46:09 2007 From: bbowling at earthlink.net (Bruce A Bowling) Date: Fri, 6 Apr 2007 16:46:09 -0400 (GMT-04:00) Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage Message-ID: <13504503.1175892369779.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> This is a great response, and when I posed the question I was not even thinking about how intertial effects change the shape of the crank rate-of-change time profile. It does, and it makes things even more sticky. You do win the medal! The part I was honing in came out when we did the error analysis some time back. The simple analysis was to assume that there was a constant crankshaft rotational speed in which a future prediction was made. At this point the crankshaft undergoes a constant accleleration (or decel) factor. What is the error in the predicted vs. actual arrival time? What comes out of the analysis is that the error term (it is a constant in this example) that comes from this grows with time. A slower RPM yields longer time periods, and the error simply grows over time. Throw in the inertial effects will simply change the error magnitude, but the error will still compound as time goes on. >From this analysis it is easy to see that more crankwheel teeth yield shorter time deltas for the same RPM, hence less error. We'll let Mike come up with the derivation - after all he's has the credentials.... Or it is up over on the MS forum. - Bruce -----Original Message----- >From: Adam Wade >Sent: Apr 5, 2007 8:57 PM >To: Bruce A Bowling , diy_efi at diy-efi.org >Subject: Re: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage > >--- Bruce A Bowling wrote: > >> The one thing I have dropped a few times here but no >> one has questioned is why is there more error at low >> RPMs? > >I'll give that one a shot. :) > >It's largely the same reason that using speed density >at idle without a lot of signal conditioning is a bad >idea. Dynamic compression is at its lowest at idle, >and spark is at its most retarded as well. Small >variances in the homogeneity of the intake mixture can >turn into much larger variances in power transmitted >to the crank during a power stroke; further, those >variances are a much larger percentage of the power >output of the engine at idle than the same variances >would be if the engine was under load (even as little >load as freeway cruise, although then you also have >issues with the low manifold pressure and what that >does to homogeneity and flame front propagation). > >AND, if you are using a reluctor as your pickup, you >not only have lower peak voltage as signal out, but >you have a shallower (slower) voltage rise/fall on the >leading/trailing edge of the tooth passing the >reluctor. You'd need to do a really nice job of >figuring out where the crossover is made from >non-triggered to triggered (and any minute changes in >crank speed because of inconsistencies with idle power >from cylinder to cylinder will change the slope as >well as the peak, and you have to have some way to >determine when the signal indicates the tooth has >actually passed its trigger point). So that too (and >it would be wonderful to make a Hall-effect rig with a >wheel that had about 100 tiny magnets on it, but I >don't know if that would be feasible or not). > >I could use the cash, but I'll settle for the medal >you don't want -- assuming I got it right. ;) > >| Kawasaki Zephyr 615 (Daphne) Kawasaki Zephyr 550 (Velma)| >| "It was like an emergency ward after a great catastrophe; it | >| didn't matter what race or class the victims belonged to. | >| They were all given the same miracle drug, which was coffee. | >| The catastrophe in this case, of course, was that the sun | >| had come up again." -Kurt Vonnegut | >| M/C Fuel Inj. Hndbk. @ Amazon.com - http://tinyurl.com/6o3ze | > > > >____________________________________________________________________________________ >Sucker-punch spam with award-winning protection. >Try the free Yahoo! Mail Beta. >http://advision.webevents.yahoo.com/mailbeta/features_spam.html From bernie at innovative.iinet.net.au Fri Apr 6 23:15:50 2007 From: bernie at innovative.iinet.net.au (Bernd Felsche) Date: Sat, 7 Apr 2007 12:15:50 +0800 Subject: [Diy_efi] RE: 60-2 Toothwheel - Kalman Filter or ( EKF ) In-Reply-To: <20070406165636.6B008E78@clutch.innovative.iinet.net.au> References: <20070406165636.6B008E78@clutch.innovative.iinet.net.au> Message-ID: <200704071215.50429@death.2.spammers> On Saturday 07 April 2007 00:54, James Holland wrote: > > >I only have a Camshaft Position Sensor giving 2 pulses per > > >revolution (TBI). > > >It sounds like this could be a very good implementation for me. > > >However if I'm accelerating wouldn't this be reflected in the > > >MAP value and therefore any ignition retardation would be at > > >least partly accounted for within the timing look up table > > >anyway? > > 2 ppr ! Probably 4 "edges". > Well that's the stock set up, Suzuki Vitara 1.6 8V with TBI. The > distributor has a hall effect sensor with four cut outs on the > vane. The 16V engine had the same distributor set up but with a > Crank Sensor(1ppr) to enable the injection to be synchronized. If the distributor is "static", i.e. no mechanical or other "advance" built in, then you have 8 edges to use for timing in one engine cycle (2 crank revs). Backlash and flexibility in the distributor drive can cause some "interesting" errors. I gather that the 16V had a camshaft sensor as that would allow the injection to be sequential. A single pulse off the crank doesn't make a lot of sense as the distributor is already providing 4 edges per crank revolution. Maybe the distributor drive became too flexible for reliable timing; perhaps by driving a DOHC?. > Well its not a performance engine, however your current debate > raised a few interesting points and got me wondering whether there > was any noticeable improvement that could be effected. This is the key question. And it applies to a performance engines. How quickly could an engine accelerate under control and how quickly would you want it to? If you went from 900 to 6000 rpm in 2 seconds (it makes the numbers easier), then that represents 15 revs/sec to 100 revs/sec in 2 seconds; or an average acceleration of 42.5 revs/sec/sec. The "mis-timing", the error in not detecting a speed change is worst at low speeds, so resolution is important to detect the actual speed as soon as possible. But the engine's speed cannot change instantaneously without some operating parameter also changing; load, air, ignition or injection. The change in speed is detected by comparing the expected time to the detected time and then anticipating the next event correspondingly earlier/later than for constant speed. (I will avoid diverging into how the _expected_ times for constant speed may be calculated.) If there is again an error in the same direction when the next event actually happens, then there is continued acceleration. Which may be nice to know... the angular acceleration can be detected from just one "mis-anticipated" event; though it requires at least half a rev with so few marks (*) and minimal ECU resources to get a useful average, taking into account compression, etc -based angular velocity changes. (*) In theory one full cycle; but you get one full cycle in half a rev of a 4-cylinder, 4-stroke. Going back to the numbers, the average acceleration of 42.5 revs/sec/sec is equivalent to an average of 170 edges/sec/sec if the edges were evenly-spaced. (*) With the engine turning at 15 rev/sec, or 120 edges/sec, the initial timing error would be from edges are expected to appear about every 8.333 ms on average, but the first accelerated edge could be detected sooner. At 8.265 ms on average (if I've solved the quadratic equation correctly). (*) Edges are typically at 78 and 6 degrees BTDC, giving 72 and 108-degree crank intervals. That appears to be somewhat detectable, being an error of about 68 microseconds (us). In the previous draft design, the timer resolution was 8 us, so it would be detected 7 (or 8) ticks before anticipated. Any subsequent event can be anticipated and outputs scheduled to occur that much earlier (as) if the engine were at a constant speed. At higher (max) engine speeds, the acceleration becomes "undetectable" (@ ~2 us) because of the 8 us timer resolution. So one "cheats" by sampling/detecting on fewer edges. :-) Strictly speaking, that cheat is "not correct" but keep in mind that the things being controlled have comparatively slow responses; e.g. spark ignition takes of the order of a millisecond and varies by about +/- 200 microseconds. So how much of a difference do and can the "esoterics" like Kalman filtering make to the operation of the engine in the real world? -- /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | "If we let things terrify us, X against HTML mail | life will not be worth living." / \ and postings | Lucius Annaeus Seneca, c. 4BC - 65AD. From niche at iinet.net.au Sat Apr 7 02:18:32 2007 From: niche at iinet.net.au (Mike) Date: Sat, 07 Apr 2007 15:18:32 +0800 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage Message-ID: <7.0.1.0.0.20070407151824.026f7030@iinet.net.au>> At 04:34 AM 4/7/07, you wrote: >> >>mmm, I am guessing that a linear interpolation and table lookup for accel/decel add/sub would be far quicker and use less >>register space & memory etc ? >> > >Guess again. Here is the actual implementation: >errt = dt3[ICint] - dtpred; > .... >// alpha-beta-gamma filter prediction >dts = dtpred + ((inpram.alpha * errt)); >tddts = tddtpred + ((inpram.beta * errt)); >t2dddts = t2dddts + ((inpram.gamma * errt)); >dtpred = dts + tddts + t2dddts ; >tddtpred = tddts + t2dddts; > >Three multiplies, 6 additions, one subtraction. One temporary storage location. No division. Would be good if you defined the labels precisely, see note at bottom of email I feel there is an even easier way to do it - start by keeping it binary centric, ie perhaps 4 samples instead of three, lookup table in need not be any more than 16 entries, I doubt if any driver would know whether its 16 or 4 or if the acccel "predictor/corrector" scheme was even active. >The 'alternative' method is to use a Mx + B form, with a table search lookup to find a acceleration factor to apply. First build up "M" (time derivative). Can be done with time period calculation subtaction, current point from previous. Save result. Next, take another subtraction to determine the change between the last delta_t and this one, and use to perform table lookup function. This means a loop and comparing a value against a list of values (note that this list lives in memory, taking up space). When the value is bracketed, grab the factor and either add or multiply, depending on implementation. This "list" needs to be sufficiently populated to deal with the wide range of possible correction values required for the range of delta-t's experienced. Anywhere from a few microseconds up. The more values the more potential checks and the more memory space required to hold the compared values and the factors. What I am suggesting is do a blind trial as per previous email, I dont expect this complexity is necessary to handle instantaneous acceleration - perhaps, except with some acceptable granularity which wouldnt use up much processing time in relation to the driveability metric, >Go ahead and implement this. Then deal with the fact that either the "factors" are coarsely-spaced to save memory and hence the acceleration error will build up (integral windup, been there, done that), or the table becomes huge with lots of comparisons. Well sure you can tell me to "go ahead" but frankly I'm not interested in that I dont have the equipment, I dare say if I did and some spare time in lab then I could well flex the intellect, I do that sort of thing for a living and hobby engines that I am dealing with have 1deg crank resolution already. What I am interested in is getting a feel for the problem and getting to grips with why people go down a particular track and clearing the deadwood, in that respect most things are so easy to simplify by clearing through the keywords. Sorry to sound like a smug jerk but I implemented a fuel injection controller in a ford escort kent motor around 1982 for my Engineering Thesis final year, we had a console between driver and passenger running a Z80 with the CP/M operating system. The Non Maskable interrupt was the sync from the distributor which simultaneously switched memory so the o/s could continue in background as if it was a standalone computer. Trouble was we couldnt write to floppy if engine over 1000rpms but that was a minor headache. In that environment with limited processor power, memory and register space we routinely arranged maths in a binary centric way to absolutely minimise multiply and divides and the type of problem you describe is so akin that our experience. In respect of your solution to the 60 crank tooth problem, I'm really interested to know if the driver can feel if its on or off - in a proper experimental trial ? >Also - in an earlier you stated that a predictor-corrector setup was not needed. Guess what? The "Mx + B" is really an linear interpolation, using two measured points to predict an event into the future. And the two last obtained points are the correction update. You have just come up with a predictor-corrector scheme. But then you said it is not needed. But here it is nonetheless. Really Bruce, you dont need to complicate the maths by using phrases/keywords to add a sense of mystery ;) y=mx+b is fine for me :P mmmm, Actually the "corrector" keyword you use has me puzzled, isnt it just applying the estimate to the next impending ignition event, on the next full cycle you should be careful what terms are carried through as you might have any number of events unsettling the algorithm, therefore keep it simple... ie. I dont see the value of retaining much except the previous 4 timing crank tooth periods to gauge the speed and acceleration and only for the expected *one* ignition event... note: I cant see from your psuedo code above if you do retain much cycle to cycle, can you clarify ? Regards from Mike Perth, Western Australia VK/VL Commodore Fuse Rail panel that wont warp, twist or melt, guaranteed ! Twin tyres for most sedans, trikes and motorcycle sidecars http://niche.iinet.net.au From bbowling at earthlink.net Sat Apr 7 06:17:17 2007 From: bbowling at earthlink.net (Bruce A Bowling) Date: Sat, 7 Apr 2007 07:17:17 -0400 (GMT-04:00) Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage Message-ID: <31791571.1175944637789.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> >note: > I cant see from your psuedo code above if you do retain much cycle to cycle, can you clarify ? > Absolutely. You want cycle-to-cycle? Just set alpha to 1, beta and gamma to zero. Result is last-interval predition. Remember your "M" is the subtraction of the two tooth arrival times (errt). To see, assume a steady state (no angular accelerations), then errt will be the same value each and every time a new tooth comes in, this is added to the running sum (dts). If there is acceleration then the arrival time of the next tooth will be shorter, hence errt will be a smaller number, and the running sum will be updated with a smaller number. - Bruce From j_holland at btopenworld.com Sat Apr 7 12:46:42 2007 From: j_holland at btopenworld.com (James Holland) Date: Sat, 7 Apr 2007 18:46:42 +0100 Subject: [Diy_efi] RE: 60-2 Toothwheel - Kalman Filter or ( EKF ) Message-ID: > On Saturday 07 April 2007 00:54, James Holland wrote: > > > >I only have a Camshaft Position Sensor giving 2 pulses per > > > >revolution (TBI). > > > > >It sounds like this could be a very good implementation for me. > > > >However if I'm accelerating wouldn't this be reflected in the > > > >MAP value and therefore any ignition retardation would be at > > > >least partly accounted for within the timing look up table > > > >anyway? > > > > 2 ppr ! > > Probably 4 "edges". > > > Well that's the stock set up, Suzuki Vitara 1.6 8V with TBI. The > > distributor has a hall effect sensor with four cut outs on the > > vane. The 16V engine had the same distributor set up but with a > > Crank Sensor(1ppr) to enable the injection to be synchronized. > > If the distributor is "static", i.e. no mechanical or other > "advance" built in, then you have 8 edges to use for timing in one > engine cycle (2 crank revs). Backlash and flexibility in the > distributor drive can cause some "interesting" errors. > > I gather that the 16V had a camshaft sensor as that would allow the > injection to be sequential. A single pulse off the crank doesn't > make a lot of sense as the distributor is already providing 4 edges > per crank revolution. Maybe the distributor drive became too > flexible for reliable timing; perhaps by driving a DOHC?. > > > Well its not a performance engine, however your current debate > > raised a few interesting points and got me wondering whether there > > was any noticeable improvement that could be effected. > > This is the key question. And it applies to a performance engines. > > How quickly could an engine accelerate under control and how quickly > would you want it to? > > If you went from 900 to 6000 rpm in 2 seconds (it makes the numbers > easier), then that represents 15 revs/sec to 100 revs/sec in 2 > seconds; or an average acceleration of 42.5 revs/sec/sec. > > The "mis-timing", the error in not detecting a speed change is worst > at low speeds, so resolution is important to detect the actual speed > as soon as possible. But the engine's speed cannot change > instantaneously without some operating parameter also changing; > load, air, ignition or injection. > > The change in speed is detected by comparing the expected > time to the detected time and then anticipating the next event > correspondingly earlier/later than for constant speed. (I will > avoid diverging into how the _expected_ times for constant speed may > be calculated.) > > If there is again an error in the same direction when the next event > actually happens, then there is continued acceleration. Which may be > nice to know... the angular acceleration can be detected from just > one "mis-anticipated" event; though it requires at least half a rev > with so few marks (*) and minimal ECU resources to get a useful > average, taking into account compression, etc -based angular > velocity changes. > > (*) In theory one full cycle; but you get one full cycle in half a > rev of a 4-cylinder, 4-stroke. > > Going back to the numbers, the average acceleration of 42.5 > revs/sec/sec is equivalent to an average of 170 edges/sec/sec if the > edges were evenly-spaced. (*) With the engine turning at 15 rev/sec, > or 120 edges/sec, the initial timing error would be from edges are > expected to appear about every 8.333 ms on average, but the first > accelerated edge could be detected sooner. At 8.265 ms on average > (if I've solved the quadratic equation correctly). > > (*) Edges are typically at 78 and 6 degrees BTDC, giving 72 and > 108-degree crank intervals. > > That appears to be somewhat detectable, being an error of about 68 > microseconds (us). In the previous draft design, the timer > resolution was 8 us, so it would be detected 7 (or 8) ticks before > anticipated. Any subsequent event can be anticipated and outputs > scheduled to occur that much earlier (as) if the engine were at a > constant speed. > > At higher (max) engine speeds, the acceleration becomes > "undetectable" (@ ~2 us) because of the 8 us timer resolution. > So one "cheats" by sampling/detecting on fewer edges. :-) > > Strictly speaking, that cheat is "not correct" but keep in mind that > the things being controlled have comparatively slow responses; e.g. > spark ignition takes of the order of a millisecond and varies by > about +/- 200 microseconds. > > So how much of a difference do and can the "esoterics" like Kalman > filtering make to the operation of the engine in the real world? > First off I hope I'm not thread hi-jacking but this does seem to be on topic. The early 8V EFI used a VR sensor that had a very short pulse width. Using the later dizzy and using both edges will give 4 timing points. That's a good point and an easy way to improve accuracy, maybe that's why Suzuki/DSM made the change. The crank sensor on the 16V tells the ECU where the crank is. It has no way of telling which pulse is which from the cam sensor. While it isn't a performance engine it is an off road vehicle and therefore has a transfer case effectively giving 4 very low ratio gears. The engine can spin up very quickly in the low ratios. I have designed a dsPIC based ignition that I shall be trying out in a Suzuki SJ413 that I'm currently transplanting a Vitara engine into. I'm convinced now that I should add in some correction for acceleration to my ignition. I'm using one of the Output Double Compare channels with a resolution IIRC of 0.5uS. Cheers James From bbowling at earthlink.net Sat Apr 7 14:18:54 2007 From: bbowling at earthlink.net (Bruce A Bowling) Date: Sat, 7 Apr 2007 15:18:54 -0400 (EDT) Subject: [Diy_efi] RE: 60-2 Toothwheel - Kalman Filter or ( EKF ) Message-ID: <3562105.1175973535219.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> > >So how much of a difference do and can the "esoterics" like Kalman >filtering make to the operation of the engine in the real world? > I think I can help lend an answer to this, based on observation and measurement. First, I will eliminate the Kalman name and esoterics (since this is just an implementation scheme) and work more fundamentally to the general question of is a higher order correction compared to simple interpolation of crank location pulse times based on two events. First, a little history, based on MS experience, particularly MS-II. The ignition operation in MS-II is pretty much the same as you outlined earlier, utilizing input-capture and output compare hardware based on a 16-bit free-running timer. In order to maintain a high accuracy for high tooth count wheels the decision was made to go with a 1 usec timer click. Of course, by doing this timer rollover becomes something to keep track of, otherwise there is insufficient cranking time available. Note that the 1 usec is a bit arbitrary, slower tic rates will also work. Using 1 usec kept some of the conversion math simpler, and it allowed to maintain use of integer artthmetic. First implementation was with what is called last interval interpolation. Just take the last two time points, subtract, and use to scale future time events. After a period of time, there were numerous incidents of timing error jitter being reported. This was most prevalent in installations where they were using distributor setups where they had fixed the mechanical and vacuum advance and let the MS-II control timing. A very popular setup. But there was an apparent scatter that was visible with a timing light. In particular, off idle acceleration events caused instant spikes which quickly jumped back. Reports were that this often was associated with off-idle hesitation. This is what prompted the investigation into spark stability, and the whole error analysis during acceleration. Since the most popular setup was a four cylinder, 4-cycle distributor replacement setup we used this for the analysis. Thus, a tach pulse every 180 degrees of crank. The setup for analysis was to assume that for the first 180 degrees the crank was at a steady angular velocity, no accel component. Use the 0 and 180-degree point to generate a prediction. An acceleration is imparted on the crank right at 0 degrees. To make this total worst case we assume the crank (non-physically) increases at the rate of 8000 RPM/sec. We have seen many datalogs of small engines exceeding this rate by a large margin in unloaded situations. Here is part of what we posted on the MS forums: "As far as equations, Assume wheel spinning at RPM0 with constant acceleration, RPM_dot. Then from the previous eqs calculate the time to get from 0 180 deg(T180) and from 0 to 360 deg(T360). Then use the time from 0-180 deg (measured in the IC ISR) to represent the predicted time for the next tach input and compare this with the calculated T360 - T180. The prediction error = T180 - (T360 - T180). T180 = [ -RPM0 + Sqrt(RPM0**2 + 60 *RPM_dot) ] / RPM_dot T360 = [ -RPM0 + Sqrt(RPM0**2 + 120 *RPM_dot) ] / RPM_dot Use RPM_dot as 8000 rpm/sec, and calculate the error for an RPM0 = 1000 and an RPM0 = 8000. The numbers come out to be 4125 us (~25 deg error) for 1000 rpm and 14 us (~0.7 deg error) for 8000 rpm." The analysis then progresses with the use of first and second time derivatives on the last interval calc in order to help with the overall prediction. Other than the first point where the acceleration is first noted (causality) applying higher corrections were helpful. But there were new issues. First, when an acceleration event ceases there is overshoot. Second, at steady state, the higher-order derivatives would introduce very small corrections that tended to stack up over time and cause jitter. So during steady-state conditions higher-order corrections were not applied. Back to the real engine, with the higher-order corrections the observed timing scatter at idle was reduced. Also, the timing error (the error between the next tooth prediction time and actual arrival time) was also reduced. The different correction modes (last interval, alpha-beta-gamma, derivative) are switchable in the code at runtime so the effect is immediate. Now, the question of "is it needed". This is from observation from what I have learned from actual implementations. In an absolute sense the lack of having a higher order correction will not provent an engine from running, or even running better than a mechanical distributor setup. The best axample of this is MS1, which has 0.1 ms injector resolution, 100 RPM resolution, 8-bit ADC resolution, etc, probably one of the most resolution-lacking setups out there. Yet it has been used to break land-speed records, run chainsaws, etc. The coarse nature does not hinder engine tuning, but the lack of resolution does show up when from time to time. More than once I have chased down an issue that was the result of a lack of resolution. And enyone who has run huge injectors with idle pulsewidths of 1 ms will attest that tuning in 0.1ms steps (10%) is not optimal. When we did MS-II, we increased resolution on everything. 1 usec injector timing, 1 usec timer for ignition, etc. The increase in resolution is noticeable while tuning, signition/fuel steps are much smoother compared to MS1. The way we look at it is that if it is possible to easily increase a resolution, calculation dynamic range, etc then lets do it, as long as it does not affect any other system. Any place there is an opportunity to decrease errors it is worth investigating. And introducing alternate algorithms (such as x-tau transient fuel compensation) to evaluate is worthwhile - as long as there are the more fundamental methods in place to use if required. - Bruce From cobraman at insightbb.com Mon Apr 9 13:03:26 2007 From: cobraman at insightbb.com (cobraman at insightbb.com) Date: Mon, 09 Apr 2007 13:03:26 -0500 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: <32557244.1175891662044.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> References: <32557244.1175891662044.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Message-ID: Bruce, I'm off the wall again. Is it feasable to fudge the correction factors from throttle position or TPS and intake vacuum? or delta TPS? Accel enrichment? Steady state could use 0 factors and others estimate acceleration rate. Whadayathink? Tom ----- Original Message ----- From: Bruce A Bowling Date: Friday, April 6, 2007 15:35 Subject: Re: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage To: Mike , diy_efi at diy-efi.org > > > >mmm, I am guessing that a linear interpolation and table lookup > for accel/decel add/sub would be far quicker and use less > >register space & memory etc ? > > > > Guess again. Here is the actual implementation: > errt = dt3[ICint] - dtpred; > .... > // alpha-beta-gamma filter prediction > dts = dtpred + ((inpram.alpha * errt)); > tddts = tddtpred + ((inpram.beta * errt)); > t2dddts = t2dddts + ((inpram.gamma * errt)); > dtpred = dts + tddts + t2dddts ; > tddtpred = tddts + t2dddts; > > Three multiplies, 6 additions, one subtraction. One temporary > storage location. No division. > > > The 'alternative' method is to use a Mx + B form, with a table > search lookup to find a acceleration factor to apply. > First build up "M" (time derivative). Can be done with time > period calculation subtaction, current point from previous. Save > result. Next, take another subtraction to determine the change > between the last delta_t and this one, and use to perform table > lookup function. This means a loop and comparing a value against > a list of values (note that this list lives in memory, taking up > space). When the value is bracketed, grab the factor and either > add or multiply, depending on implementation. This "list" needs > to be sufficiently populated to deal with the wide range of > possible correction values required for the range of delta-t's > experienced. Anywhere from a few microseconds up. The more > values the more potential checks and the more memory space > required to hold the compared values and the factors. > > Go ahead and implement this. Then deal with the fact that either > the "factors" are coarsely-spaced to save memory and hence the > acceleration error will build up (integral windup, been there, > done that), or the table becomes huge with lots of comparisons. > > Also - in an earlier you stated that a predictor-corrector setup > was not needed. Guess what? The "Mx + B" is really an linear > interpolation, using two measured points to predict an event > into the future. And the two last obtained points are the > correction update. You have just come up with a predictor- > corrector scheme. But then you said it is not needed. But here > it is nonetheless. > > - Bruce > > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > From bernie at innovative.iinet.net.au Mon Apr 9 21:25:39 2007 From: bernie at innovative.iinet.net.au (Bernd Felsche) Date: Tue, 10 Apr 2007 10:25:39 +0800 Subject: [Diy_efi] RE: 60-2 Toothwheel - Kalman Filter or ( EKF ) In-Reply-To: <3562105.1175973535219.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> References: <3562105.1175973535219.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Message-ID: <200704101025.39547@death.2.spammers> On Sunday 08 April 2007 03:18, Bruce A Bowling wrote: > >So how much of a difference do and can the "esoterics" like Kalman > >filtering make to the operation of the engine in the real world? > I think I can help lend an answer to this, based on observation > and measurement. First, I will eliminate the Kalman name and > esoterics (since this is just an implementation scheme) and work > more fundamentally to the general question of is a higher order > correction compared to simple interpolation of crank location > pulse times based on two events. The word is _extrapolation_. You can only interpolate between known points. :-) > First, a little history, based on MS experience, particularly > MS-II. The ignition operation in MS-II is pretty much the same as > you outlined earlier, utilizing input-capture and output compare > hardware based on a 16-bit free-running timer. In order to > maintain a high accuracy for high tooth count wheels the decision > was made to go with a 1 usec timer click. Of course, by doing > this timer rollover becomes something to keep track of, otherwise > there is insufficient cranking time available. Note that the 1 > usec is a bit arbitrary, slower tic rates will also work. Using 1 > usec kept some of the conversion math simpler, and it allowed to > maintain use of integer artthmetic. As a side issue, although desirable, there's no need to maintain "human units" inside the machine, especially once a timebase has been settled. Obviously it requires good documentations and subsequent programmers to be able to "think the machine". Note that when between two points as with input capture against a free-running counter, that one already has an angular "velocity" (well, period, actually) for the crankshaft. The first difference to expected that is captured is a measure of the acceleration when taken in proportion to the period. The problem is the resolution and the mechanical effects that may cause the captured value to be incorrect. Also, because of the timer resolution and the need to add/subtract two values based on that resolution, the error of the result doubles so the notional error of any derived result is also doubled. This introduces an error that may creep (accumulate) in one direction for a few cycles until the feedback of the measurement "clicks over" and the error can start again, perhaps from as far as the other end of the error bounds. The error bounds need to be kept narrow enough so that that effect doesn't matter on the real engine. The effect may still be measurable with sufficient instrumentation but should small enough to be undetectable. > First implementation was with what is called last interval > interpolation. Just take the last two time points, subtract, and > use to scale future time events. > After a period of time, there were numerous incidents of timing > error jitter being reported. This was most prevalent in > installations where they were using distributor setups where they > had fixed the mechanical and vacuum advance and let the MS-II > control timing. A very popular setup. But there was an apparent > scatter that was visible with a timing light. In particular, off > idle acceleration events caused instant spikes which quickly > jumped back. Reports were that this often was associated with > off-idle hesitation. This is to be expected. That as well as "over-run" when the engine slows... > This is what prompted the investigation into spark stability, and > the whole error analysis during acceleration. Since the most > popular setup was a four cylinder, 4-cycle distributor replacement > setup we used this for the analysis. Thus, a tach pulse every 180 > degrees of crank. The setup for analysis was to assume that for > the first 180 degrees the crank was at a steady angular velocity, > no accel component. Use the 0 and 180-degree point to generate a > prediction. An acceleration is imparted on the crank right at 0 > degrees. To make this total worst case we assume the crank > (non-physically) increases at the rate of 8000 RPM/sec. We have > seen many datalogs of small engines exceeding this rate by a large > margin in unloaded situations. That's a very rapid change of rpm, but of little *use*. :-) > Here is part of what we posted on the MS forums: > > "As far as equations, Assume wheel spinning at RPM0 with constant > acceleration, RPM_dot. Then from the previous eqs calculate the > time to get from 0 180 deg(T180) and from 0 to 360 deg(T360). Then > use the time from 0-180 deg (measured in the IC ISR) to represent > the predicted time for the next tach input and compare this with > the calculated T360 - T180. The prediction error = T180 - (T360 - > T180). > > T180 = [ -RPM0 + Sqrt(RPM0**2 + 60 *RPM_dot) ] / RPM_dot > T360 = [ -RPM0 + Sqrt(RPM0**2 + 120 *RPM_dot) ] / RPM_dot > > Use RPM_dot as 8000 rpm/sec, and calculate the error for an RPM0 = > 1000 and an RPM0 = 8000. > > The numbers come out to be 4125 us (~25 deg error) for 1000 rpm > and 14 us (~0.7 deg error) for 8000 rpm." Those errors are quite a bit larger than my calculations. I'll go back and check them in detail, then verify using other methods. I got about 0.3 degrees error from 900 rpm (68 us) using about a quarter of the acceleration and double the number of feedback interrupts, making it a ~3 degree error which is an order of magnitude different to your calculations. Back to the drawing board for me... > The analysis then progresses with the use of first and second time > derivatives on the last interval calc in order to help with the > overall prediction. Other than the first point where the > acceleration is first noted (causality) applying higher > corrections were helpful. But there were new issues. First, when > an acceleration event ceases there is overshoot. Second, at steady > state, the higher-order derivatives would introduce very small > corrections that tended to stack up over time and cause jitter. So > during steady-state conditions higher-order corrections were not > applied. You can't turn noise into signal :-) Small signals (differences) wrt error produce a lot of noise in the result. > Now, the question of "is it needed". This is from observation from > what I have learned from actual implementations. In an absolute > sense the lack of having a higher order correction will not > provent an engine from running, or even running better than a > mechanical distributor setup. The best axample of this is MS1, > which has 0.1 ms injector resolution, 100 RPM resolution, 8-bit > ADC resolution, etc, probably one of the most resolution-lacking > setups out there. Yet it has been used to break land-speed > records, run chainsaws, etc. The coarse nature does not hinder > engine tuning, but the lack of resolution does show up when from > time to time. More than once I have chased down an issue that was > the result of a lack of resolution. And enyone who has run huge > injectors with idle pulsewidths of 1 ms will attest that tuning in > 0.1ms steps (10%) is not optimal. In terms of guessing the position of the crankshaft, the injector duty cycle only becomes significant with direct injection; especially compression-ignition as injection is ignition timing. 0.1ms would be borderline for ignition timing, spark or compression, especially at idle and at higher rpm. > When we did MS-II, we increased resolution on everything. 1 usec > injector timing, 1 usec timer for ignition, etc. The increase in > resolution is noticeable while tuning, signition/fuel steps are > much smoother compared to MS1. The way we look at it is that if it > is possible to easily increase a resolution, calculation dynamic > range, etc then lets do it, as long as it does not affect any > other system. Any place there is an opportunity to decrease errors > it is worth investigating. And introducing alternate algorithms > (such as x-tau transient fuel compensation) to evaluate is > worthwhile - as long as there are the more fundamental methods in > place to use if required. Decreasing the noise introduced by coarse resolution is a good thing. It may allow for _less_ filtering to be used to get a nicely-responsive engine. But a coarse resolution also means that you are less likely to even detect such things as torsional vibration effects as their "signal" could be well within the resolution of the measurement. Knowing the resolution of the "instrumentation" is also important. e.g. hysteresis of sensors, and their time/temperature response. When times get down to microseconds, the sensor transients may become bothersome. -- /"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | "If we let things terrify us, X against HTML mail | life will not be worth living." / \ and postings | Lucius Annaeus Seneca, c. 4BC - 65AD. From arsoftware at gmail.com Tue Apr 10 08:34:01 2007 From: arsoftware at gmail.com (Alex Ruiz) Date: Tue, 10 Apr 2007 11:34:01 -0200 Subject: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage In-Reply-To: References: <32557244.1175891662044.JavaMail.root@elwamui-hound.atl.sa.earthlink.net> Message-ID: <7b372cc90704100634u2ea16860v13392f1654c30610@mail.gmail.com> Thanks for all the links and experience related to this subject. I'm convinced that Kalman filtering is a really powerful tool but, it's something that I better apply in "future" applications. SIMULINK has a Kalman filter block that I feel like playing with, automatic code generation can also be used on that block. Without filter implementation, the controller works pretty nasty when noise is added into the cam or crank line ( that goes straight into the capture/compare unit ), specially in low RPM. Now I must work on this filtering process you described. Looking forward to run simulation with the filter algorithm. I have about 97% of the system fully functional on simulation. Regards, Alex 2007/4/9, cobraman at insightbb.com : > > Bruce, > > I'm off the wall again. Is it feasable to fudge the correction factors > from throttle position or TPS and intake vacuum? or delta TPS? Accel > enrichment? Steady state could use 0 factors and others estimate > acceleration rate. Whadayathink? Tom > > ----- Original Message ----- > From: Bruce A Bowling > Date: Friday, April 6, 2007 15:35 > Subject: Re: [Diy_efi] 60-2 Toothwheel - Kalman Filter or ( EKF ) usage > To: Mike , diy_efi at diy-efi.org > > > > > > >mmm, I am guessing that a linear interpolation and table lookup > > for accel/decel add/sub would be far quicker and use less > > >register space & memory etc ? > > > > > > > Guess again. Here is the actual implementation: > > errt = dt3[ICint] - dtpred; > > .... > > // alpha-beta-gamma filter prediction > > dts = dtpred + ((inpram.alpha * errt)); > > tddts = tddtpred + ((inpram.beta * errt)); > > t2dddts = t2dddts + ((inpram.gamma * errt)); > > dtpred = dts + tddts + t2dddts ; > > tddtpred = tddts + t2dddts; > > > > Three multiplies, 6 additions, one subtraction. One temporary > > storage location. No division. > > > > > > The 'alternative' method is to use a Mx + B form, with a table > > search lookup to find a acceleration factor to apply. > > First build up "M" (time derivative). Can be done with time > > period calculation subtaction, current point from previous. Save > > result. Next, take another subtraction to determine the change > > between the last delta_t and this one, and use to perform table > > lookup function. This means a loop and comparing a value against > > a list of values (note that this list lives in memory, taking up > > space). When the value is bracketed, grab the factor and either > > add or multiply, depending on implementation. This "list" needs > > to be sufficiently populated to deal with the wide range of > > possible correction values required for the range of delta-t's > > experienced. Anywhere from a few microseconds up. The more > > values the more potential checks and the more memory space > > required to hold the compared values and the factors. > > > > Go ahead and implement this. Then deal with the fact that either > > the "factors" are coarsely-spaced to save memory and hence the > > acceleration error will build up (integral windup, been there, > > done that), or the table becomes huge with lots of comparisons. > > > > Also - in an earlier you stated that a predictor-corrector setup > > was not needed. Guess what? The "Mx + B" is really an linear > > interpolation, using two measured points to predict an event > > into the future. And the two last obtained points are the > > correction update. You have just come up with a predictor- > > corrector scheme. But then you said it is not needed. But here > > it is nonetheless. > > > > - Bruce > > > > _______________________________________________ > > Diy_efi mailing list > > Diy_efi at diy-efi.org > > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > > Main WWW page: http://www.diy-efi.org/diy_efi > > > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > From bbowling at earthlink.net Tue Apr 10 08:54:41 2007 From: bbowling at earthlink.net (Bruce A Bowling) Date: Tue, 10 Apr 2007 09:54:41 -0400 (EDT) Subject: [Diy_efi] RE: 60-2 Toothwheel - Kalman Filter or ( EKF ) Message-ID: <3172443.1176213281362.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> > >The word is _extrapolation_. You can only interpolate between known >points. :-) You are correct, being a bit lax on terminology. > >As a side issue, although desirable, there's no need to maintain >"human units" inside the machine, especially once a timebase has >been settled. Obviously it requires good documentations and >subsequent programmers to be able to "think the machine". > Yes, its just an implementation decision. Luckly, processing power is becoming such that it is possible to maintain desired units while getting the embedded task accomplished. >Note that when between two points as with input capture against a >free-running counter, that one already has an angular "velocity" >(well, period, actually) for the crankshaft. The first difference to >expected that is captured is a measure of the acceleration when >taken in proportion to the period. > This is the key point to all of this. The calculation shows that it is not enough to simply take the last two time events to extrapolate into the future under an acceleration, rate-of-change of the time events should be included, and even rate-of-change of this is useful. >The problem is the resolution and the mechanical effects that may >cause the captured value to be incorrect. > These are other error sources indeed, and all contribute, there is no question. >Also, because of the timer resolution and the need to add/subtract >two values based on that resolution, the error of the result doubles >so the notional error of any derived result is also doubled. This >introduces an error that may creep (accumulate) in one direction for >a few cycles until the feedback of the measurement "clicks over" and >the error can start again, perhaps from as far as the other end of >the error bounds. > Yep, and this is an effect that becomes noticeable very rapidly. To add, one needs to maintain precision in intermediate calculations. >> degrees. To make this total worst case we assume the crank >> (non-physically) increases at the rate of 8000 RPM/sec. We have >> seen many datalogs of small engines exceeding this rate by a large >> margin in unloaded situations. > >That's a very rapid change of rpm, but of little *use*. :-) > It's of total use if you happen to have an engine like this :). The real data we worked against was taken from an operational jet ski, where it experienced revs approaching 10,000 RPM/sec. >Those errors are quite a bit larger than my calculations. I'll go >back and check them in detail, then verify using other methods. The derivation was from a physical standpoint: First, to convert rpm to degrees/sec: theta_dot(deg/sec) = (revs/sec)*360 = (RPM/60) * 360 =6*RPM For example, the time to go from 0 to 180 deg with no acceleration is: T180 = 180 deg / theta_dot = (30 / RPM) sec With constant acceleration we have: theta_dot_dot = 6 * RPM_dot theta(T) = theta(0) + $ theta_dot(t) * delta_t, (1) With the synbol $ being integral from 0 to T Also, theta_dot(t) = theta_dot(0) + theta_dot_dot * t. (2) Combining these: theta(T) = theta(0) + theta_dot(0)*T + $ theta_dot_dot* t * delta_t = 0 + 6 * RPM(0)*T + theta_dot_dot * (T**2)/2. For theta(T) = 180 deg, we get: 6*RPM_dot * (T**2)/2 + 6 * RPM(0) * T - 180 = 0. This is a quadratic eq in T (= T180 since we took theta(T) = 180.) Divide both sides by 6 and we can write the solution as: T180 = [ -RPM(0) + Sqrt(RPM(0)**2 + 60 * RPM_dot) ] / RPM_dot, in sec. > >You can't turn noise into signal :-) > >Small signals (differences) wrt error produce a lot of noise in the >result. > Absolutely. As does other factors, such as the resolution of the comparative timebase, etc. One has to be aware of all error sources. > >In terms of guessing the position of the crankshaft, the injector >duty cycle only becomes significant with direct injection; >especially compression-ignition as injection is ignition timing. True. > >0.1ms would be borderline for ignition timing, spark or compression, >especially at idle and at higher rpm. It is borderline. The extra code uses 50 usec for timing resolution which is also a bit coarse but the limitation is in the implementation on the existing hardware. > >Decreasing the noise introduced by coarse resolution is a good >thing. It (lack of resolution) really helped the MS1 box a lot. The increased resolution in MSII ended up creating some control loop stabilization issues in the beginning. - Bruce From espresso_doppio at yahoo.com Wed Apr 11 05:21:55 2007 From: espresso_doppio at yahoo.com (Adam Wade) Date: Wed, 11 Apr 2007 03:21:55 -0700 (PDT) Subject: [Diy_efi] RE: 60-2 Toothwheel - Kalman Filter or ( EKF ) In-Reply-To: <3172443.1176213281362.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: <172746.57392.qm@web32205.mail.mud.yahoo.com> --- Bruce A Bowling wrote: >> In terms of guessing the position of the >> crankshaft, the injector duty cycle only becomes >> significant with direct injection > True. I'm curious, since you obviously have done a great deal of testing and implemented workable solutions using both the MS I and II hardware and runtime: How much of a difference does injector timing make at idle? And in practice, where did any differences show themselves? Obviously, if you have a really big cam and idle is very "lope"-y, with a lot of intake reversion and charge dilution with exhaust gases, you're going to make things a little more tolerable at idle by using timed sequential injection, but I have a sneaking suspicion that there is a small but noticeable difference at idle, and possibly at small throttle opening cruise (high gear, low road speed). If you've previously made this info available elsewhere, just point me at where I can find it; I don't want to make extra work for you. You sound like a damned busy guy! ;) | Kawasaki Zephyr 615 (Daphne) Kawasaki Zephyr 550 (Velma)| | "It was like an emergency ward after a great catastrophe; it | | didn't matter what race or class the victims belonged to. | | They were all given the same miracle drug, which was coffee. | | The catastrophe in this case, of course, was that the sun | | had come up again." -Kurt Vonnegut | | M/C Fuel Inj. Hndbk. @ Amazon.com - http://tinyurl.com/6o3ze | ____________________________________________________________________________________ Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 From bbowling at earthlink.net Wed Apr 11 12:51:21 2007 From: bbowling at earthlink.net (Bruce A Bowling) Date: Wed, 11 Apr 2007 13:51:21 -0400 (EDT) Subject: [Diy_efi] RE: 60-2 Toothwheel - Kalman Filter or ( EKF ) Message-ID: <5576287.1176313881876.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> > >How much of a difference does injector timing make at >idle? And in practice, where did any differences show >themselves? Obviously, if you have a really big cam >and idle is very "lope"-y, with a lot of intake >reversion and charge dilution with exhaust gases, >you're going to make things a little more tolerable at >idle by using timed sequential injection, but I have a >sneaking suspicion that there is a small but >noticeable difference at idle, and possibly at small >throttle opening cruise (high gear, low road speed). I should have done a bit of qualification on the statement on injection timing relative to crank position at idle. >From what we have found on MS installs, one can obtain a decent and reproduciable idle quality. That is, for a steady-state situation at idle, a tune based on AFR will reproduce if all other parameters are in line - and the batch injection phase is the same. Now, is this tune the most optimal with respect to fuel consumption and emission output? In other words, batch injection over a properly phased sequential injection? Go to www.sae.org and purchase the following paper, SAE 800467, by O Glockler, H. Knapp and H. Manger (1980). I cannot reproduce here due to copyright laws, but I will speak to it (from my memory as I do not have the paper in front of me). This was a paper outlining testing that Bosch performed in the late 1970s in regards to injection phase relative to intake valve position. What they did was to move the injection event thru a full 720-degree engine cycle and monitor the engine torque, HC and CO out, at a idle situation. For the most part the measured parameters are pretty constant. But, at the point where the injection event corresponds to an open intake valve there is a change in CO and unburned HC output and torque dropped off a slight amount. IIRC, the torque dropoff was under a few percent. So, you suspiction jives with the data presented in this paper. Also, this paper is referenced in Heywood (pg. 299)and the following comment appears: "Sequential injection timing, where the phasing of each injection pulse relative to intake valve lift profile is the same is another option. Engine performance and emissions do change as the timing of the start of injection relative to inlet valve opening is varied. Injection with valve lift at maximum, or decreasing, is least desirable." - Bruce From niche at iinet.net.au Thu Apr 12 02:39:21 2007 From: niche at iinet.net.au (Mike) Date: Thu, 12 Apr 2007 15:39:21 +0800 Subject: [Diy_efi] RE: 60-2 Toothwheel - Kalman Filter or ( EKF ) In-Reply-To: <5576287.1176313881876.JavaMail.root@elwamui-mouette.atl.sa .earthlink.net> References: <5576287.1176313881876.JavaMail.root@elwamui-mouette.atl.sa.earthlink.net> Message-ID: <7.0.1.0.0.20070412152902.026f41d0@iinet.net.au>> At 01:51 AM 4/12/07, Bruce wrote: >I should have done a bit of qualification on the statement on injection timing relative to crank position at idle. Bruce, Where is this missing tooth (btw, is it just one tooth or two) in relation to the TDC of cylinder 1 or is there another reference, please elaborate ? and is this for a 4 cylinder, 6 or 8 etc ? Reason I ask is, in relation ot binary centric register manipulations, I have an idea for a dead simple extrapolator - sorry Bernd I said interpolation before, I was using that term in reference to interpolating time or acceleration between teeth (or rather deriving a rate and/or rate of change figure etc) which then would (of course) be applied to subsequently extrapolate for ignition... And other than an average rpm figure I cant see any value of keeping any last values of previous cycle (ie Full crank rotation). It should be possible to asses rate of change of velocity and even rate of change of acceleration from the counts between say the last 4 teeth without need for the prevous ignition cycle provided the granularity is low and the determination of trigger point by interpolation of the position of the missing tooth/teeth is repeatable/stable/jitter free etc ie. Is there another reason - other than an average (perhaps damped 'filtered' value) figure for rpms for the tables... ? Such as, Is it for the purpose of poles and zeros for classic stability criteria ? Regards from Mike Massen Network Power Systems Lab 08 9444 8961 Mb 0438 048961 Perth, Western Australia * VL/VK & VN/VP/VR GMH Commodore Fuse Rail that wont warp or melt ! * RB30 Skyline/Nissan/VL Milspec ignition drivers with diagnostic features now in economy trials * Twin tyres for most sedans, trikes and motorcycle sidecars * Industrial grade PolyVinyliDeneChloride (PVDC Copolymer) in bulk, the best oxygen and water protective barrier you can find for circuit boards. * Special equipment on offer, 60KVA UPS with large battery cabinet - AUD$12K Web site under construction http://niche.iinet.net.au From dunvegan at sbcglobal.net Sun Apr 15 10:55:51 2007 From: dunvegan at sbcglobal.net (Rick McLeod) Date: Sun, 15 Apr 2007 08:55:51 -0700 (PDT) Subject: [Diy_efi] weatherpack connectors or something like them Message-ID: <307993.82290.qm@web80512.mail.mud.yahoo.com> Well, evidently what I'm looking for is NOT a traditional 'weatherpack' connector, although it's on a GM auto! I'm looking for the 5-conductor connector that mates to the Bosch MAF sensor on early GM TPI systems. The only 'weatherpack' connectors I can locate are 6 pin or 4 pin, and are somewhat larger pin size. This is a very similar to the weatherpack, but smaller or higher density. I'm sure someone else has run across this challenge, so your help is appreciated. and yes, the obvious is the GM dealer, but they don't have the 'male' connector that would mimic the MAF end, only the female end that is actually on the cable. The female end is not the challenge, as I've got a salvaged harness that I could butcher one off of, but I'm looking to keep in intact unless necessary to butcher it. Therefore, I'm looking for both M and F, what I'm trying to do is create a diag cable that I can insert inline to a MAF to monitor the signals to diagnose either bad MAF's or the control circuits such as the burn-off power and airflow signals. Thanks as always. ----- Original Message ---- From: Jim Kyser To: diy_efi at diy-efi.org Sent: Tuesday, April 3, 2007 4:07:47 PM Subject: Re: [Diy_efi] weatherpack connectors MJM National sells weatherpack connectors on eBay. They sell both pre-packaged kits and smaller quantities. Here is a link to their eBay store. They have a 5 pack of those 4 pin connectors for $4 + $1sh and the a 5 pack of the shrouds for $2.50 + $1sh. Pins and terminals are like $2.50 + $1 for shipping for a package of 25. They combine shipping on multiple items. I have bought from them and they ship out quickly. http://stores.ebay.com/MJM-National-Inc_Weather-Pack_W0QQcolZ2QQdirZQ2d1QQfsubZ12QQftidZ2QQtZkm Jim Kyser 1946 Willys CJ-2A w/4.1 liter Buick V6 w/TBI in progress Rick McLeod wrote: > I am aware of Del-City for these, I ordered some, but they backordered them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I need to repair a cable ASAP and am up the proverbial backorder tree! > > I'm looking for 4-pin flat male housings and pins. > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > > _______________________________________________ Diy_efi mailing list Diy_efi at diy-efi.org Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi Main WWW page: http://www.diy-efi.org/diy_efi From gassr at charter.net Sun Apr 15 12:13:49 2007 From: gassr at charter.net (gassr) Date: Sun, 15 Apr 2007 12:13:49 -0500 Subject: [Diy_efi] weatherpack connectors or something like them References: <307993.82290.qm@web80512.mail.mud.yahoo.com> Message-ID: <000801c77f81$6f63f900$34147544@homedesktop> A lot of people confuse weather-pack with metri-pack. FAIK, GM OEM is largely metri-pack. Two sources to check for metri-pack are Waytek or Del City. Power and Signal, a delphi supplier, is an excellent source for just about any metri-pack component on GM vehicles, along with GT series, micro-pack, and Ducon. They require a minimum quantity however. For those that keep a stockroom of various connectors, they would be my first choice. As you have discovered, GM itself has a spotty selection. Rick, first would be to correctly identify your OEM MAF, then compare that with the popular metri-pack specs, and go from there. I'm confident it is not weather-pack. Hoped this helped some. GAS ----- Original Message ----- From: "Rick McLeod" To: Sent: Sunday, April 15, 2007 10:55 AM Subject: [Diy_efi] weatherpack connectors or something like them > Well, evidently what I'm looking for is NOT a traditional 'weatherpack' > connector, although it's on a GM auto! > > I'm looking for the 5-conductor connector that mates to the Bosch > MAF sensor on early GM TPI systems. > > The only 'weatherpack' connectors I can locate are 6 pin or 4 pin, and > are somewhat larger pin size. This is a very similar to the weatherpack, > but smaller or higher density. > > I'm sure someone else has run across this challenge, so your help is > appreciated. > > and yes, the obvious is the GM dealer, but they don't have the 'male' > connector that would mimic the MAF end, only the female end that is > actually on the cable. The female end is not the challenge, as I've got > a salvaged harness that I could butcher one off of, but I'm looking to > keep in intact unless necessary to butcher it. > > Therefore, I'm looking for both M and F, what I'm trying to do is > create a diag cable that I can insert inline to a MAF to monitor the > signals to diagnose either bad MAF's or the control circuits such as > the burn-off power and airflow signals. From b_the_j at hotmail.com Sun Apr 15 14:09:42 2007 From: b_the_j at hotmail.com (Ben Heidorn) Date: Sun, 15 Apr 2007 15:09:42 -0400 Subject: [Diy_efi] weatherpack connectors or something like them In-Reply-To: <307993.82290.qm@web80512.mail.mud.yahoo.com> Message-ID: Why are you restricting yourself to plug in to the MAF, go 4-6inches down the harness using a duesche style 6 pin, blanking one of the holes. you can pick these up at Crown lift trucks or OKI, probably hyster or yale too but these are or competitors so im not sure. >From: Rick McLeod >Reply-To: diy_efi at diy-efi.org >To: diy_efi at diy-efi.org >Subject: [Diy_efi] weatherpack connectors or something like them >Date: Sun, 15 Apr 2007 08:55:51 -0700 (PDT) > >Well, evidently what I'm looking for is NOT a traditional 'weatherpack' >connector, although it's on a GM auto! > >I'm looking for the 5-conductor connector that mates to the Bosch MAF >sensor on early GM TPI systems. > >The only 'weatherpack' connectors I can locate are 6 pin or 4 pin, and are >somewhat larger pin size. This is a very similar to the weatherpack, but >smaller or higher density. > >I'm sure someone else has run across this challenge, so your help is >appreciated. > >and yes, the obvious is the GM dealer, but they don't have the 'male' >connector that would mimic the MAF end, only the female end that is >actually on the cable. The female end is not the challenge, as I've got a >salvaged harness that I could butcher one off of, but I'm looking to keep >in intact unless necessary to butcher it. > >Therefore, I'm looking for both M and F, what I'm trying to do is create a >diag cable that I can insert inline to a MAF to monitor the signals to >diagnose either bad MAF's or the control circuits such as the burn-off >power and airflow signals. > >Thanks as always. > > >----- Original Message ---- >From: Jim Kyser >To: diy_efi at diy-efi.org >Sent: Tuesday, April 3, 2007 4:07:47 PM >Subject: Re: [Diy_efi] weatherpack connectors > > >MJM National sells weatherpack connectors on eBay. They sell both >pre-packaged kits and smaller quantities. Here is a link to their eBay >store. They have a 5 pack of those 4 pin connectors for $4 + $1sh and >the a 5 pack of the shrouds for $2.50 + $1sh. Pins and terminals are >like $2.50 + $1 for shipping for a package of 25. They combine shipping >on multiple items. I have bought from them and they ship out quickly. > >http://stores.ebay.com/MJM-National-Inc_Weather-Pack_W0QQcolZ2QQdirZQ2d1QQfsubZ12QQftidZ2QQtZkm > >Jim Kyser >1946 Willys CJ-2A w/4.1 liter Buick V6 w/TBI in progress > >Rick McLeod wrote: > > I am aware of Del-City for these, I ordered some, but they backordered >them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I need >to repair a cable ASAP and am up the proverbial backorder tree! > > > > I'm looking for 4-pin flat male housings and pins. > > _______________________________________________ > > Diy_efi mailing list > > Diy_efi at diy-efi.org > > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > > Main WWW page: http://www.diy-efi.org/diy_efi > > > > > >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi _________________________________________________________________ Exercise your brain! Try Flexicon. http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglineapril07 From clair.davis at charter.net Sun Apr 15 13:55:33 2007 From: clair.davis at charter.net (Clair Davis) Date: Sun, 15 Apr 2007 13:55:33 -0500 Subject: [Diy_efi] weatherpack connectors or something like them References: <307993.82290.qm@web80512.mail.mud.yahoo.com> Message-ID: <005701c77f8f$a60a6b20$03000004@davis> Check with (as in, give a call to) Painless Performance http://www.painlessperformance.com/ and ask if they've got something like that sitting around. When I needed to adapt a 2x2 Weatherpak to a 1x4 Metripack connector for my AIS swap, they had just that on the shelf. IIRC, it was about $20 shipped, but I didn't have to lift a finger to get it. Clair ----- Original Message ----- From: "Rick McLeod" To: Sent: Sunday, April 15, 2007 10:55 AM Subject: [Diy_efi] weatherpack connectors or something like them > Well, evidently what I'm looking for is NOT a traditional 'weatherpack' connector, although it's on a GM auto! > > I'm looking for the 5-conductor connector that mates to the Bosch MAF sensor on early GM TPI systems. > > The only 'weatherpack' connectors I can locate are 6 pin or 4 pin, and are somewhat larger pin size. This is a very similar to the weatherpack, but smaller or higher density. > > I'm sure someone else has run across this challenge, so your help is appreciated. > > and yes, the obvious is the GM dealer, but they don't have the 'male' connector that would mimic the MAF end, only the female end that is actually on the cable. The female end is not the challenge, as I've got a salvaged harness that I could butcher one off of, but I'm looking to keep in intact unless necessary to butcher it. > > Therefore, I'm looking for both M and F, what I'm trying to do is create a diag cable that I can insert inline to a MAF to monitor the signals to diagnose either bad MAF's or the control circuits such as the burn-off power and airflow signals. > > Thanks as always. > > > ----- Original Message ---- > From: Jim Kyser > To: diy_efi at diy-efi.org > Sent: Tuesday, April 3, 2007 4:07:47 PM > Subject: Re: [Diy_efi] weatherpack connectors > > > MJM National sells weatherpack connectors on eBay. They sell both > pre-packaged kits and smaller quantities. Here is a link to their eBay > store. They have a 5 pack of those 4 pin connectors for $4 + $1sh and > the a 5 pack of the shrouds for $2.50 + $1sh. Pins and terminals are > like $2.50 + $1 for shipping for a package of 25. They combine shipping > on multiple items. I have bought from them and they ship out quickly. > > http://stores.ebay.com/MJM-National-Inc_Weather-Pack_W0QQcolZ2QQdirZQ2d1QQfsubZ12QQftidZ2QQtZkm > > Jim Kyser > 1946 Willys CJ-2A w/4.1 liter Buick V6 w/TBI in progress > > Rick McLeod wrote: > > I am aware of Del-City for these, I ordered some, but they backordered them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I need to repair a cable ASAP and am up the proverbial backorder tree! > > > > I'm looking for 4-pin flat male housings and pins. > > _______________________________________________ > > Diy_efi mailing list > > Diy_efi at diy-efi.org > > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > > Main WWW page: http://www.diy-efi.org/diy_efi > > > > > > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > From dunvegan at sbcglobal.net Sun Apr 15 14:39:51 2007 From: dunvegan at sbcglobal.net (Rick McLeod) Date: Sun, 15 Apr 2007 12:39:51 -0700 (PDT) Subject: [Diy_efi] weatherpack connectors or something like them Message-ID: <759104.22255.qm@web80501.mail.mud.yahoo.com> Well, I didn't realize there was a pigtail here, I'll look further at the harness now and see if I can do that, sure would be easier. I'm not familiar w/ what you're calling a 'duesche' connector, but I'm sure I'll recognize it when I see it. Thanks for jumping in. BTW, if I don't have that on my car, does anyone know if the MAF connector is a 150 series, or 280 series. Waytek doesn't list a 5 pin (nor have I found elsewhere) in 150 except 150-GT and all I find there is a kit of all different sizes for over $80, pircey for what I'm trying to do. as always, all help appreciated. ----- Original Message ---- From: Ben Heidorn To: diy_efi at diy-efi.org Sent: Sunday, April 15, 2007 2:09:42 PM Subject: RE: [Diy_efi] weatherpack connectors or something like them Why are you restricting yourself to plug in to the MAF, go 4-6inches down the harness using a duesche style 6 pin, blanking one of the holes. you can pick these up at Crown lift trucks or OKI, probably hyster or yale too but these are or competitors so im not sure. >From: Rick McLeod >Reply-To: diy_efi at diy-efi.org >To: diy_efi at diy-efi.org >Subject: [Diy_efi] weatherpack connectors or something like them >Date: Sun, 15 Apr 2007 08:55:51 -0700 (PDT) > >Well, evidently what I'm looking for is NOT a traditional 'weatherpack' >connector, although it's on a GM auto! > >I'm looking for the 5-conductor connector that mates to the Bosch MAF >sensor on early GM TPI systems. > >The only 'weatherpack' connectors I can locate are 6 pin or 4 pin, and are >somewhat larger pin size. This is a very similar to the weatherpack, but >smaller or higher density. > >I'm sure someone else has run across this challenge, so your help is >appreciated. > >and yes, the obvious is the GM dealer, but they don't have the 'male' >connector that would mimic the MAF end, only the female end that is >actually on the cable. The female end is not the challenge, as I've got a >salvaged harness that I could butcher one off of, but I'm looking to keep >in intact unless necessary to butcher it. > >Therefore, I'm looking for both M and F, what I'm trying to do is create a >diag cable that I can insert inline to a MAF to monitor the signals to >diagnose either bad MAF's or the control circuits such as the burn-off >power and airflow signals. > >Thanks as always. > > >----- Original Message ---- >From: Jim Kyser >To: diy_efi at diy-efi.org >Sent: Tuesday, April 3, 2007 4:07:47 PM >Subject: Re: [Diy_efi] weatherpack connectors > > >MJM National sells weatherpack connectors on eBay. They sell both >pre-packaged kits and smaller quantities. Here is a link to their eBay >store. They have a 5 pack of those 4 pin connectors for $4 + $1sh and >the a 5 pack of the shrouds for $2.50 + $1sh. Pins and terminals are >like $2.50 + $1 for shipping for a package of 25. They combine shipping >on multiple items. I have bought from them and they ship out quickly. > >http://stores.ebay.com/MJM-National-Inc_Weather-Pack_W0QQcolZ2QQdirZQ2d1QQfsubZ12QQftidZ2QQtZkm > >Jim Kyser >1946 Willys CJ-2A w/4.1 liter Buick V6 w/TBI in progress > >Rick McLeod wrote: > > I am aware of Del-City for these, I ordered some, but they backordered >them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I need >to repair a cable ASAP and am up the proverbial backorder tree! > > > > I'm looking for 4-pin flat male housings and pins. > > _______________________________________________ > > Diy_efi mailing list > > Diy_efi at diy-efi.org > > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > > Main WWW page: http://www.diy-efi.org/diy_efi > > > > > >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi _________________________________________________________________ Exercise your brain! Try Flexicon. http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglineapril07 _______________________________________________ Diy_efi mailing list Diy_efi at diy-efi.org Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi Main WWW page: http://www.diy-efi.org/diy_efi From five10man at commspeed.net Sun Apr 15 22:18:14 2007 From: five10man at commspeed.net (Tom Visel) Date: Sun, 15 Apr 2007 20:18:14 -0700 Subject: [Diy_efi] weatherpack connectors or something like them In-Reply-To: <759104.22255.qm@web80501.mail.mud.yahoo.com> References: <759104.22255.qm@web80501.mail.mud.yahoo.com> Message-ID: <4622EAF6.2070905@commspeed.net> It's actually Deutsch, and they supply Caterpillar, and they did (do?) supply Ford - those rounded connectors with the red inserts to lock the terminals in are Deutsch. For the receptacle side, you could call CarQuest. I don't have my wire and cable catalog next to me at the moment, but they have a surprisingly good selection of repair pigtails available if you still want to go with one that fits the MAF. I have gotten 3-terminal Bosch receptacles (Mitsubishi power transistor/ignition module connectors) from them when Mitsubishi, Chrysler, and Hyundai couldn't get them. If weatherproofing isn't so critical, Molex connectors are in every Radio Snacks and they are cheap. They can be made mostly waterproof if you use double-layered shrink tubing with mastic on the cable end and fill the connector with grease on the terminal end. Also, since they are so cheap, it is a no-brainer to make your test circuits unpluggable. HTH, TomV Rick McLeod wrote: > Well, I didn't realize there was a pigtail here, I'll look further at the harness now and see if I can do that, sure would be easier. > > I'm not familiar w/ what you're calling a 'duesche' connector, but I'm sure I'll recognize it when I see it. > > Thanks for jumping in. > > BTW, if I don't have that on my car, does anyone know if the MAF connector is a 150 series, or 280 series. Waytek doesn't list a 5 pin (nor have I found elsewhere) in 150 except 150-GT and all I find there is a kit of all different sizes for over $80, pircey for what I'm trying to do. > > as always, all help appreciated. > > > ----- Original Message ---- > From: Ben Heidorn > To: diy_efi at diy-efi.org > Sent: Sunday, April 15, 2007 2:09:42 PM > Subject: RE: [Diy_efi] weatherpack connectors or something like them > > > Why are you restricting yourself to plug in to the MAF, go 4-6inches down > the harness using a duesche style 6 pin, blanking one of the holes. you can > pick these up at Crown lift trucks or OKI, probably hyster or yale too but > these are or competitors so im not sure. > > > >> From: Rick McLeod >> Reply-To: diy_efi at diy-efi.org >> To: diy_efi at diy-efi.org >> Subject: [Diy_efi] weatherpack connectors or something like them >> Date: Sun, 15 Apr 2007 08:55:51 -0700 (PDT) >> >> Well, evidently what I'm looking for is NOT a traditional 'weatherpack' >> connector, although it's on a GM auto! >> >> I'm looking for the 5-conductor connector that mates to the Bosch MAF >> sensor on early GM TPI systems. >> >> The only 'weatherpack' connectors I can locate are 6 pin or 4 pin, and are >> somewhat larger pin size. This is a very similar to the weatherpack, but >> smaller or higher density. >> >> I'm sure someone else has run across this challenge, so your help is >> appreciated. >> >> and yes, the obvious is the GM dealer, but they don't have the 'male' >> connector that would mimic the MAF end, only the female end that is >> actually on the cable. The female end is not the challenge, as I've got a >> salvaged harness that I could butcher one off of, but I'm looking to keep >> in intact unless necessary to butcher it. >> >> Therefore, I'm looking for both M and F, what I'm trying to do is create a >> diag cable that I can insert inline to a MAF to monitor the signals to >> diagnose either bad MAF's or the control circuits such as the burn-off >> power and airflow signals. >> >> Thanks as always. >> >> >> ----- Original Message ---- >> From: Jim Kyser >> To: diy_efi at diy-efi.org >> Sent: Tuesday, April 3, 2007 4:07:47 PM >> Subject: Re: [Diy_efi] weatherpack connectors >> >> >> MJM National sells weatherpack connectors on eBay. They sell both >> pre-packaged kits and smaller quantities. Here is a link to their eBay >> store. They have a 5 pack of those 4 pin connectors for $4 + $1sh and >> the a 5 pack of the shrouds for $2.50 + $1sh. Pins and terminals are >> like $2.50 + $1 for shipping for a package of 25. They combine shipping >> on multiple items. I have bought from them and they ship out quickly. >> >> http://stores.ebay.com/MJM-National-Inc_Weather-Pack_W0QQcolZ2QQdirZQ2d1QQfsubZ12QQftidZ2QQtZkm >> >> Jim Kyser >> 1946 Willys CJ-2A w/4.1 liter Buick V6 w/TBI in progress >> >> Rick McLeod wrote: >> >>> I am aware of Del-City for these, I ordered some, but they backordered >>> >> them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I need >> to repair a cable ASAP and am up the proverbial backorder tree! >> >>> I'm looking for 4-pin flat male housings and pins. >>> _______________________________________________ >>> Diy_efi mailing list >>> Diy_efi at diy-efi.org >>> Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >>> Main WWW page: http://www.diy-efi.org/diy_efi >>> >>> >>> >> _______________________________________________ >> Diy_efi mailing list >> Diy_efi at diy-efi.org >> Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >> Main WWW page: http://www.diy-efi.org/diy_efi >> _______________________________________________ >> Diy_efi mailing list >> Diy_efi at diy-efi.org >> Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >> Main WWW page: http://www.diy-efi.org/diy_efi >> > > _________________________________________________________________ > Exercise your brain! Try Flexicon. > http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglineapril07 > > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > > > From bill.washington at nec.com.au Sun Apr 15 23:24:06 2007 From: bill.washington at nec.com.au (Bill Washington) Date: Mon, 16 Apr 2007 14:24:06 +1000 Subject: [Diy_efi] 5 pin connector In-Reply-To: <20070415170014.DD2313B6A2@ns2.nec.com.au> References: <20070415170014.DD2313B6A2@ns2.nec.com.au> Message-ID: <4622FA66.3010900@nec.com.au> Rick, Are these flat or round pins, in a line or an array? If they are flat, in a line, with a metal spring retainer around the outside of the female housing - they are probably an AMP "Junior Timer"connector look at the following web pages. Do you see the correct type there? I believe that Bosch used these connectors on many of their systems. Regards Bill > > Subject: > [Diy_efi] weatherpack connectors or something like them > From: > Rick McLeod > Date: > Sun, 15 Apr 2007 08:55:51 -0700 (PDT) > To: > diy_efi at diy-efi.org > > To: > diy_efi at diy-efi.org > > > Well, evidently what I'm looking for is NOT a traditional 'weatherpack' connector, although it's on a GM auto! > > I'm looking for the 5-conductor connector that mates to the Bosch MAF sensor on early GM TPI systems. > > The only 'weatherpack' connectors I can locate are 6 pin or 4 pin, and are somewhat larger pin size. This is a very similar to the weatherpack, but smaller or higher density. > > I'm sure someone else has run across this challenge, so your help is appreciated. > > and yes, the obvious is the GM dealer, but they don't have the 'male' connector that would mimic the MAF end, only the female end that is actually on the cable. The female end is not the challenge, as I've got a salvaged harness that I could butcher one off of, but I'm looking to keep in intact unless necessary to butcher it. > > Therefore, I'm looking for both M and F, what I'm trying to do is create a diag cable that I can insert inline to a MAF to monitor the signals to diagnose either bad MAF's or the control circuits such as the burn-off power and airflow signals. > > Thanks as always. > > > From mfrels at ix.netcom.com Mon Apr 16 06:35:03 2007 From: mfrels at ix.netcom.com (Mike Frels) Date: Mon, 16 Apr 2007 06:35:03 -0500 (GMT-05:00) Subject: [Diy_efi] weatherpack connectors or something like them Message-ID: <4479040.1176723304039.JavaMail.root@elwamui-hybrid.atl.sa.earthlink.net> You could also do like those of us did for out MAF to MAP conversions that we wanted to be reversible. For the MAP sensor we made a small harness that had a jack on one end made from an old MAF Sensor. We got busy with a hacksaw and soldering iron and butchered the old MAF for just its Metri-Pak jack. That's IF you have access to an old MAF. -----Original Message----- >From: Rick McLeod >Sent: Apr 15, 2007 2:39 PM >To: diy_efi at diy-efi.org >Subject: Re: [Diy_efi] weatherpack connectors or something like them > >Well, I didn't realize there was a pigtail here, I'll look further at the harness now and see if I can do that, sure would be easier. > >I'm not familiar w/ what you're calling a 'duesche' connector, but I'm sure I'll recognize it when I see it. > >Thanks for jumping in. > >BTW, if I don't have that on my car, does anyone know if the MAF connector is a 150 series, or 280 series. Waytek doesn't list a 5 pin (nor have I found elsewhere) in 150 except 150-GT and all I find there is a kit of all different sizes for over $80, pircey for what I'm trying to do. > >as always, all help appreciated. > > >----- Original Message ---- >From: Ben Heidorn >To: diy_efi at diy-efi.org >Sent: Sunday, April 15, 2007 2:09:42 PM >Subject: RE: [Diy_efi] weatherpack connectors or something like them > > >Why are you restricting yourself to plug in to the MAF, go 4-6inches down >the harness using a duesche style 6 pin, blanking one of the holes. you can >pick these up at Crown lift trucks or OKI, probably hyster or yale too but >these are or competitors so im not sure. > > >>From: Rick McLeod >>Reply-To: diy_efi at diy-efi.org >>To: diy_efi at diy-efi.org >>Subject: [Diy_efi] weatherpack connectors or something like them >>Date: Sun, 15 Apr 2007 08:55:51 -0700 (PDT) >> >>Well, evidently what I'm looking for is NOT a traditional 'weatherpack' >>connector, although it's on a GM auto! >> >>I'm looking for the 5-conductor connector that mates to the Bosch MAF >>sensor on early GM TPI systems. >> >>The only 'weatherpack' connectors I can locate are 6 pin or 4 pin, and are >>somewhat larger pin size. This is a very similar to the weatherpack, but >>smaller or higher density. >> >>I'm sure someone else has run across this challenge, so your help is >>appreciated. >> >>and yes, the obvious is the GM dealer, but they don't have the 'male' >>connector that would mimic the MAF end, only the female end that is >>actually on the cable. The female end is not the challenge, as I've got a >>salvaged harness that I could butcher one off of, but I'm looking to keep >>in intact unless necessary to butcher it. >> >>Therefore, I'm looking for both M and F, what I'm trying to do is create a >>diag cable that I can insert inline to a MAF to monitor the signals to >>diagnose either bad MAF's or the control circuits such as the burn-off >>power and airflow signals. >> >>Thanks as always. >> >> >>----- Original Message ---- >>From: Jim Kyser >>To: diy_efi at diy-efi.org >>Sent: Tuesday, April 3, 2007 4:07:47 PM >>Subject: Re: [Diy_efi] weatherpack connectors >> >> >>MJM National sells weatherpack connectors on eBay. They sell both >>pre-packaged kits and smaller quantities. Here is a link to their eBay >>store. They have a 5 pack of those 4 pin connectors for $4 + $1sh and >>the a 5 pack of the shrouds for $2.50 + $1sh. Pins and terminals are >>like $2.50 + $1 for shipping for a package of 25. They combine shipping >>on multiple items. I have bought from them and they ship out quickly. >> >>http://stores.ebay.com/MJM-National-Inc_Weather-Pack_W0QQcolZ2QQdirZQ2d1QQfsubZ12QQftidZ2QQtZkm >> >>Jim Kyser >>1946 Willys CJ-2A w/4.1 liter Buick V6 w/TBI in progress >> >>Rick McLeod wrote: >> > I am aware of Del-City for these, I ordered some, but they backordered >>them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I need >>to repair a cable ASAP and am up the proverbial backorder tree! >> > >> > I'm looking for 4-pin flat male housings and pins. >> > _______________________________________________ >> > Diy_efi mailing list >> > Diy_efi at diy-efi.org >> > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >> > Main WWW page: http://www.diy-efi.org/diy_efi >> > >> > >> >>_______________________________________________ >>Diy_efi mailing list >>Diy_efi at diy-efi.org >>Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >>Main WWW page: http://www.diy-efi.org/diy_efi >>_______________________________________________ >>Diy_efi mailing list >>Diy_efi at diy-efi.org >>Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >>Main WWW page: http://www.diy-efi.org/diy_efi > >_________________________________________________________________ >Exercise your brain! Try Flexicon. >http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglineapril07 > >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi From dunvegan at sbcglobal.net Mon Apr 16 07:44:44 2007 From: dunvegan at sbcglobal.net (Rick McLeod) Date: Mon, 16 Apr 2007 05:44:44 -0700 (PDT) Subject: [Diy_efi] 5 pin connector Message-ID: <594838.55007.qm@web80514.mail.mud.yahoo.com> Bill, thanks very much for the reply, from the pictures all I can say is this is NOT a Juinior Timer connector, as there is no metal push clip, but uses the traditional plastic tab retainer. But, I'll definately archive the sites, as running across this type of quality resource is rare. Thanks again, more mail to read. cheers ----- Original Message ---- From: Bill Washington To: diy_efi at diy-efi.org Sent: Sunday, April 15, 2007 11:24:06 PM Subject: [Diy_efi] 5 pin connector Rick, Are these flat or round pins, in a line or an array? If they are flat, in a line, with a metal spring retainer around the outside of the female housing - they are probably an AMP "Junior Timer"connector look at the following web pages. Do you see the correct type there? I believe that Bosch used these connectors on many of their systems. Regards Bill > > Subject: > [Diy_efi] weatherpack connectors or something like them > From: > Rick McLeod > Date: > Sun, 15 Apr 2007 08:55:51 -0700 (PDT) > To: > diy_efi at diy-efi.org > > To: > diy_efi at diy-efi.org > > > Well, evidently what I'm looking for is NOT a traditional 'weatherpack' connector, although it's on a GM auto! > > I'm looking for the 5-conductor connector that mates to the Bosch MAF sensor on early GM TPI systems. > > The only 'weatherpack' connectors I can locate are 6 pin or 4 pin, and are somewhat larger pin size. This is a very similar to the weatherpack, but smaller or higher density. > > I'm sure someone else has run across this challenge, so your help is appreciated. > > and yes, the obvious is the GM dealer, but they don't have the 'male' connector that would mimic the MAF end, only the female end that is actually on the cable. The female end is not the challenge, as I've got a salvaged harness that I could butcher one off of, but I'm looking to keep in intact unless necessary to butcher it. > > Therefore, I'm looking for both M and F, what I'm trying to do is create a diag cable that I can insert inline to a MAF to monitor the signals to diagnose either bad MAF's or the control circuits such as the burn-off power and airflow signals. > > Thanks as always. > > > _______________________________________________ Diy_efi mailing list Diy_efi at diy-efi.org Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi Main WWW page: http://www.diy-efi.org/diy_efi From frankmccracken at shaw.ca Mon Apr 16 10:55:45 2007 From: frankmccracken at shaw.ca (Frank McCracken) Date: Mon, 16 Apr 2007 08:55:45 -0700 Subject: [Diy_efi] O2 sensor mounting Message-ID: <002401c7803f$b1f7cad0$6401a8c0@flamingo> I am installing my Hooker side exhaust on my '65 Corvette. I would like to mount my O2 sensor at about 5:o'clock in the 4" tube so that it will be not hanging out there. The collector with this system is outside of the fender. My choices would be on top or down low on the inside to hide it. I hear that it should be pointing down so condensation will run off. The sensor has been at about 4:o'clock in my old system for the last 2 years will no ill efects. If it's gotta hang out so be it. What should I do, anyone? Frank From tmc_mike_yates at sbcglobal.net Mon Apr 16 11:03:19 2007 From: tmc_mike_yates at sbcglobal.net (Mike Yates) Date: Mon, 16 Apr 2007 09:03:19 -0700 Subject: [Diy_efi] O2 sensor mounting In-Reply-To: <002401c7803f$b1f7cad0$6401a8c0@flamingo> References: <002401c7803f$b1f7cad0$6401a8c0@flamingo> Message-ID: <8g772319jq21islavbkk7vr60d82p79ma2@4ax.com> It's a '65 Vette hide the prick so what if you have to replace it every 6-months or so. you're dealing with a classic not a track beater. Mike On Mon, 16 Apr 2007 08:55:45 -0700, you wrote: >I am installing my Hooker side exhaust on my '65 Corvette. I would like to mount my O2 sensor at about 5:o'clock in the 4" tube so that it will be not hanging out there. The collector with this system is outside of the fender. My choices would be on top or down low on the inside to hide it. I hear that it should be pointing down so condensation will run off. The sensor has been at about 4:o'clock in my old system for the last 2 years will no ill efects. If it's gotta hang out so be it. What should I do, anyone? >Frank >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi From dunvegan at sbcglobal.net Mon Apr 16 11:11:47 2007 From: dunvegan at sbcglobal.net (Rick McLeod) Date: Mon, 16 Apr 2007 09:11:47 -0700 (PDT) Subject: [Diy_efi] weatherpack connectors or something like them Message-ID: <765636.19181.qm@web80515.mail.mud.yahoo.com> Well, this one's a dead end, but was worth a shot. The no longer will entertain any kind of custom?? work, even to adapt to their cables, per their tech support staff. Bummer, as one of these vehicles is a Painless wired Jag refitted w/ a Camaro Z/28 TPI, and it's a tire burner! Oh, well, thanks Clari for the idea, all help appreciated. ----- Original Message ---- From: Clair Davis To: diy_efi at diy-efi.org Sent: Sunday, April 15, 2007 1:55:33 PM Subject: Re: [Diy_efi] weatherpack connectors or something like them Check with (as in, give a call to) Painless Performance http://www.painlessperformance.com/ and ask if they've got something like that sitting around. When I needed to adapt a 2x2 Weatherpak to a 1x4 Metripack connector for my AIS swap, they had just that on the shelf. IIRC, it was about $20 shipped, but I didn't have to lift a finger to get it. Clair ----- Original Message ----- From: "Rick McLeod" To: Sent: Sunday, April 15, 2007 10:55 AM Subject: [Diy_efi] weatherpack connectors or something like them > Well, evidently what I'm looking for is NOT a traditional 'weatherpack' connector, although it's on a GM auto! > > I'm looking for the 5-conductor connector that mates to the Bosch MAF sensor on early GM TPI systems. > > The only 'weatherpack' connectors I can locate are 6 pin or 4 pin, and are somewhat larger pin size. This is a very similar to the weatherpack, but smaller or higher density. > > I'm sure someone else has run across this challenge, so your help is appreciated. > > and yes, the obvious is the GM dealer, but they don't have the 'male' connector that would mimic the MAF end, only the female end that is actually on the cable. The female end is not the challenge, as I've got a salvaged harness that I could butcher one off of, but I'm looking to keep in intact unless necessary to butcher it. > > Therefore, I'm looking for both M and F, what I'm trying to do is create a diag cable that I can insert inline to a MAF to monitor the signals to diagnose either bad MAF's or the control circuits such as the burn-off power and airflow signals. > > Thanks as always. > > > ----- Original Message ---- > From: Jim Kyser > To: diy_efi at diy-efi.org > Sent: Tuesday, April 3, 2007 4:07:47 PM > Subject: Re: [Diy_efi] weatherpack connectors > > > MJM National sells weatherpack connectors on eBay. They sell both > pre-packaged kits and smaller quantities. Here is a link to their eBay > store. They have a 5 pack of those 4 pin connectors for $4 + $1sh and > the a 5 pack of the shrouds for $2.50 + $1sh. Pins and terminals are > like $2.50 + $1 for shipping for a package of 25. They combine shipping > on multiple items. I have bought from them and they ship out quickly. > > http://stores.ebay.com/MJM-National-Inc_Weather-Pack_W0QQcolZ2QQdirZQ2d1QQfsubZ12QQftidZ2QQtZkm > > Jim Kyser > 1946 Willys CJ-2A w/4.1 liter Buick V6 w/TBI in progress > > Rick McLeod wrote: > > I am aware of Del-City for these, I ordered some, but they backordered them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I need to repair a cable ASAP and am up the proverbial backorder tree! > > > > I'm looking for 4-pin flat male housings and pins. > > _______________________________________________ > > Diy_efi mailing list > > Diy_efi at diy-efi.org > > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > > Main WWW page: http://www.diy-efi.org/diy_efi > > > > > > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > _______________________________________________ Diy_efi mailing list Diy_efi at diy-efi.org Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi Main WWW page: http://www.diy-efi.org/diy_efi From dunvegan at sbcglobal.net Mon Apr 16 11:21:42 2007 From: dunvegan at sbcglobal.net (Rick McLeod) Date: Mon, 16 Apr 2007 09:21:42 -0700 (PDT) Subject: [Diy_efi] O2 sensor mounting Message-ID: <931658.22909.qm@web80515.mail.mud.yahoo.com> I personally would hide the sensor, and as for the condensation thing, I'm not too sure I buy that rational, as there isn't going to be a major temp difference when running at normal op temp, in all the reading on these I've done I've never see or read anything that directly discusses position vs. longevity, which is what I believe the condensation theory is based on. Furthermore, if that is a major concern, maybe using a heated element would also minimize the concern, works when they're mounted significant distance from the exhaust port during cool weather, but from my experience w/ good 4>1 headers the temp at the collector tube is still reasonably high, so I can't imagine you're gonna see any problems. good luck, just my 2 C worth, cheers ----- Original Message ---- From: Frank McCracken To: diy_efi at diy-efi.org Sent: Monday, April 16, 2007 10:55:45 AM Subject: [Diy_efi] O2 sensor mounting I am installing my Hooker side exhaust on my '65 Corvette. I would like to mount my O2 sensor at about 5:o'clock in the 4" tube so that it will be not hanging out there. The collector with this system is outside of the fender. My choices would be on top or down low on the inside to hide it. I hear that it should be pointing down so condensation will run off. The sensor has been at about 4:o'clock in my old system for the last 2 years will no ill efects. If it's gotta hang out so be it. What should I do, anyone? Frank _______________________________________________ Diy_efi mailing list Diy_efi at diy-efi.org Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi Main WWW page: http://www.diy-efi.org/diy_efi From frankmccracken at shaw.ca Mon Apr 16 13:18:55 2007 From: frankmccracken at shaw.ca (Frank McCracken) Date: Mon, 16 Apr 2007 11:18:55 -0700 Subject: [Diy_efi] O2 sensor mounting References: <931658.22909.qm@web80515.mail.mud.yahoo.com> Message-ID: <004701c78053$b297c440$6401a8c0@flamingo> Thanks guys, it is a heated sensor. And it is a bit of a function over form machine..... not quite a track beater tho. ----- Original Message ----- From: "Rick McLeod" To: Sent: Monday, April 16, 2007 9:21 AM Subject: Re: [Diy_efi] O2 sensor mounting > I personally would hide the sensor, and as for the condensation thing, I'm not too sure I buy that rational, as there isn't going to be a major temp difference when running at normal op temp, in all the reading on these I've done I've never see or read anything that directly discusses position vs. longevity, which is what I believe the condensation theory is based on. Furthermore, if that is a major concern, maybe using a heated element would also minimize the concern, works when they're mounted significant distance from the exhaust port during cool weather, but from my experience w/ good 4>1 headers the temp at the collector tube is still reasonably high, so I can't imagine you're gonna see any problems. > > good luck, just my 2 C worth, cheers > > > ----- Original Message ---- > From: Frank McCracken > To: diy_efi at diy-efi.org > Sent: Monday, April 16, 2007 10:55:45 AM > Subject: [Diy_efi] O2 sensor mounting > > > I am installing my Hooker side exhaust on my '65 Corvette. I would like to mount my O2 sensor at about 5:o'clock in the 4" tube so that it will be not hanging out there. The collector with this system is outside of the fender. My choices would be on top or down low on the inside to hide it. I hear that it should be pointing down so condensation will run off. The sensor has been at about 4:o'clock in my old system for the last 2 years will no ill efects. If it's gotta hang out so be it. What should I do, anyone? > Frank > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.446 / Virus Database: 269.4.0/761 - Release Date: 4/14/2007 9:36 PM > > From frankmccracken at shaw.ca Mon Apr 16 15:48:56 2007 From: frankmccracken at shaw.ca (Frank McCracken) Date: Mon, 16 Apr 2007 13:48:56 -0700 Subject: [Diy_efi] O2 sensor mounting References: <931658.22909.qm@web80515.mail.mud.yahoo.com> <004701c78053$b297c440$6401a8c0@flamingo> Message-ID: <005501c78068$a6a5db30$6401a8c0@flamingo> So that makes me think, Is it just the non-heated O2 sensors that need to be mounted pointing downwards? Frank. ----- Original Message ----- From: "Frank McCracken" To: Sent: Monday, April 16, 2007 11:18 AM Subject: Re: [Diy_efi] O2 sensor mounting > Thanks guys, it is a heated sensor. And it is a bit of a function over form > machine..... not quite a track beater tho. > > > ----- Original Message ----- > From: "Rick McLeod" > To: > Sent: Monday, April 16, 2007 9:21 AM > Subject: Re: [Diy_efi] O2 sensor mounting > > > > I personally would hide the sensor, and as for the condensation thing, I'm > not too sure I buy that rational, as there isn't going to be a major temp > difference when running at normal op temp, in all the reading on these I've > done I've never see or read anything that directly discusses position vs. > longevity, which is what I believe the condensation theory is based on. > Furthermore, if that is a major concern, maybe using a heated element would > also minimize the concern, works when they're mounted significant distance > from the exhaust port during cool weather, but from my experience w/ good > 4>1 headers the temp at the collector tube is still reasonably high, so I > can't imagine you're gonna see any problems. > > > > good luck, just my 2 C worth, cheers > > > > > > ----- Original Message ---- > > From: Frank McCracken > > To: diy_efi at diy-efi.org > > Sent: Monday, April 16, 2007 10:55:45 AM > > Subject: [Diy_efi] O2 sensor mounting > > > > > > I am installing my Hooker side exhaust on my '65 Corvette. I would like to > mount my O2 sensor at about 5:o'clock in the 4" tube so that it will be not > hanging out there. The collector with this system is outside of the fender. > My choices would be on top or down low on the inside to hide it. I hear that > it should be pointing down so condensation will run off. The sensor has been > at about 4:o'clock in my old system for the last 2 years will no ill efects. > If it's gotta hang out so be it. What should I do, anyone? > > Frank > > _______________________________________________ > > Diy_efi mailing list > > Diy_efi at diy-efi.org > > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > > Main WWW page: http://www.diy-efi.org/diy_efi > > _______________________________________________ > > Diy_efi mailing list > > Diy_efi at diy-efi.org > > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > > Main WWW page: http://www.diy-efi.org/diy_efi > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.446 / Virus Database: 269.4.0/761 - Release Date: 4/14/2007 > 9:36 PM > > > > > > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.446 / Virus Database: 269.4.0/761 - Release Date: 4/14/2007 9:36 PM > > From galaxiecustom500 at sbcglobal.net Mon Apr 16 16:57:13 2007 From: galaxiecustom500 at sbcglobal.net (Jason M.) Date: Mon, 16 Apr 2007 17:57:13 -0400 Subject: [Diy_efi] O2 sensor mounting References: <931658.22909.qm@web80515.mail.mud.yahoo.com><004701c78053$b297c440$6401a8c0@flamingo> <005501c78068$a6a5db30$6401a8c0@flamingo> Message-ID: <002701c78072$31e8b5b0$6901a8c0@BILLYBOB> You want the heated sensors pointing down. Also the aftermarket wide band sensors/controllers will also instruct you to leave the heater off for a few seconds so any condensation in the exhaust can be blown out. Hot ceramic + relatively cool water = dead sensor. At least this is what they say. Maybe you can get away with more with a narrow band sensor? ----- Original Message ----- From: "Frank McCracken" To: Sent: Monday, April 16, 2007 4:48 PM Subject: Re: [Diy_efi] O2 sensor mounting > So that makes me think, Is it just the non-heated O2 sensors that need to > be > mounted pointing downwards? > Frank. > > > ----- Original Message ----- > From: "Frank McCracken" > To: > Sent: Monday, April 16, 2007 11:18 AM > Subject: Re: [Diy_efi] O2 sensor mounting > > >> Thanks guys, it is a heated sensor. And it is a bit of a function over > form >> machine..... not quite a track beater tho. >> >> >> ----- Original Message ----- >> From: "Rick McLeod" >> To: >> Sent: Monday, April 16, 2007 9:21 AM >> Subject: Re: [Diy_efi] O2 sensor mounting >> >> >> > I personally would hide the sensor, and as for the condensation thing, > I'm >> not too sure I buy that rational, as there isn't going to be a major temp >> difference when running at normal op temp, in all the reading on these > I've >> done I've never see or read anything that directly discusses position vs. >> longevity, which is what I believe the condensation theory is based on. >> Furthermore, if that is a major concern, maybe using a heated element > would >> also minimize the concern, works when they're mounted significant >> distance >> from the exhaust port during cool weather, but from my experience w/ good >> 4>1 headers the temp at the collector tube is still reasonably high, so I >> can't imagine you're gonna see any problems. >> > >> > good luck, just my 2 C worth, cheers >> > >> > >> > ----- Original Message ---- >> > From: Frank McCracken >> > To: diy_efi at diy-efi.org >> > Sent: Monday, April 16, 2007 10:55:45 AM >> > Subject: [Diy_efi] O2 sensor mounting >> > >> > >> > I am installing my Hooker side exhaust on my '65 Corvette. I would like > to >> mount my O2 sensor at about 5:o'clock in the 4" tube so that it will be > not >> hanging out there. The collector with this system is outside of the > fender. >> My choices would be on top or down low on the inside to hide it. I hear > that >> it should be pointing down so condensation will run off. The sensor has > been >> at about 4:o'clock in my old system for the last 2 years will no ill > efects. >> If it's gotta hang out so be it. What should I do, anyone? >> > Frank >> > _______________________________________________ >> > Diy_efi mailing list >> > Diy_efi at diy-efi.org >> > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >> > Main WWW page: http://www.diy-efi.org/diy_efi >> > _______________________________________________ >> > Diy_efi mailing list >> > Diy_efi at diy-efi.org >> > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >> > Main WWW page: http://www.diy-efi.org/diy_efi >> > >> > >> > -- >> > No virus found in this incoming message. >> > Checked by AVG Free Edition. >> > Version: 7.5.446 / Virus Database: 269.4.0/761 - Release Date: >> > 4/14/2007 >> 9:36 PM >> > >> > >> >> _______________________________________________ >> Diy_efi mailing list >> Diy_efi at diy-efi.org >> Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >> Main WWW page: http://www.diy-efi.org/diy_efi >> >> >> -- >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.446 / Virus Database: 269.4.0/761 - Release Date: 4/14/2007 > 9:36 PM >> >> > > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > From dunvegan at sbcglobal.net Mon Apr 16 16:57:20 2007 From: dunvegan at sbcglobal.net (Rick McLeod) Date: Mon, 16 Apr 2007 14:57:20 -0700 (PDT) Subject: [Diy_efi] O2 sensor mounting Message-ID: <33904.6488.qm@web80503.mail.mud.yahoo.com> I honestly don't believe it matters, as I've an Z/28 that original equip was about a 30* upward angle, unheated and w/ that arrangement it never did 'eat' sensors. But there again, better than normal factory manifolds, not perfect, but also a hi-perf tuned mill, so that may make a difference over a lethargic Buick Century. ----- Original Message ---- From: Frank McCracken To: diy_efi at diy-efi.org Sent: Monday, April 16, 2007 3:48:56 PM Subject: Re: [Diy_efi] O2 sensor mounting So that makes me think, Is it just the non-heated O2 sensors that need to be mounted pointing downwards? Frank. ----- Original Message ----- From: "Frank McCracken" To: Sent: Monday, April 16, 2007 11:18 AM Subject: Re: [Diy_efi] O2 sensor mounting > Thanks guys, it is a heated sensor. And it is a bit of a function over form > machine..... not quite a track beater tho. > > > ----- Original Message ----- > From: "Rick McLeod" > To: > Sent: Monday, April 16, 2007 9:21 AM > Subject: Re: [Diy_efi] O2 sensor mounting > > > > I personally would hide the sensor, and as for the condensation thing, I'm > not too sure I buy that rational, as there isn't going to be a major temp > difference when running at normal op temp, in all the reading on these I've > done I've never see or read anything that directly discusses position vs. > longevity, which is what I believe the condensation theory is based on. > Furthermore, if that is a major concern, maybe using a heated element would > also minimize the concern, works when they're mounted significant distance > from the exhaust port during cool weather, but from my experience w/ good > 4>1 headers the temp at the collector tube is still reasonably high, so I > can't imagine you're gonna see any problems. > > > > good luck, just my 2 C worth, cheers > > > > > > ----- Original Message ---- > > From: Frank McCracken > > To: diy_efi at diy-efi.org > > Sent: Monday, April 16, 2007 10:55:45 AM > > Subject: [Diy_efi] O2 sensor mounting > > > > > > I am installing my Hooker side exhaust on my '65 Corvette. I would like to > mount my O2 sensor at about 5:o'clock in the 4" tube so that it will be not > hanging out there. The collector with this system is outside of the fender. > My choices would be on top or down low on the inside to hide it. I hear that > it should be pointing down so condensation will run off. The sensor has been > at about 4:o'clock in my old system for the last 2 years will no ill efects. > If it's gotta hang out so be it. What should I do, anyone? > > Frank > > _______________________________________________ > > Diy_efi mailing list > > Diy_efi at diy-efi.org > > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > > Main WWW page: http://www.diy-efi.org/diy_efi > > _______________________________________________ > > Diy_efi mailing list > > Diy_efi at diy-efi.org > > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > > Main WWW page: http://www.diy-efi.org/diy_efi > > > > > > -- > > No virus found in this incoming message. > > Checked by AVG Free Edition. > > Version: 7.5.446 / Virus Database: 269.4.0/761 - Release Date: 4/14/2007 > 9:36 PM > > > > > > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi > > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.446 / Virus Database: 269.4.0/761 - Release Date: 4/14/2007 9:36 PM > > _______________________________________________ Diy_efi mailing list Diy_efi at diy-efi.org Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi Main WWW page: http://www.diy-efi.org/diy_efi From b_the_j at hotmail.com Mon Apr 16 20:24:10 2007 From: b_the_j at hotmail.com (Ben Heidorn) Date: Mon, 16 Apr 2007 21:24:10 -0400 Subject: [Diy_efi] weatherpack connectors or something like them In-Reply-To: <759104.22255.qm@web80501.mail.mud.yahoo.com> Message-ID: There is no pigtail there i was refering to making you own >From: Rick McLeod >Reply-To: diy_efi at diy-efi.org >To: diy_efi at diy-efi.org >Subject: Re: [Diy_efi] weatherpack connectors or something like them >Date: Sun, 15 Apr 2007 12:39:51 -0700 (PDT) > >Well, I didn't realize there was a pigtail here, I'll look further at the >harness now and see if I can do that, sure would be easier. > >I'm not familiar w/ what you're calling a 'duesche' connector, but I'm sure >I'll recognize it when I see it. > >Thanks for jumping in. > >BTW, if I don't have that on my car, does anyone know if the MAF connector >is a 150 series, or 280 series. Waytek doesn't list a 5 pin (nor have I >found elsewhere) in 150 except 150-GT and all I find there is a kit of all >different sizes for over $80, pircey for what I'm trying to do. > >as always, all help appreciated. > > >----- Original Message ---- >From: Ben Heidorn >To: diy_efi at diy-efi.org >Sent: Sunday, April 15, 2007 2:09:42 PM >Subject: RE: [Diy_efi] weatherpack connectors or something like them > > >Why are you restricting yourself to plug in to the MAF, go 4-6inches down >the harness using a duesche style 6 pin, blanking one of the holes. you can >pick these up at Crown lift trucks or OKI, probably hyster or yale too but >these are or competitors so im not sure. > > > >From: Rick McLeod > >Reply-To: diy_efi at diy-efi.org > >To: diy_efi at diy-efi.org > >Subject: [Diy_efi] weatherpack connectors or something like them > >Date: Sun, 15 Apr 2007 08:55:51 -0700 (PDT) > > > >Well, evidently what I'm looking for is NOT a traditional 'weatherpack' > >connector, although it's on a GM auto! > > > >I'm looking for the 5-conductor connector that mates to the Bosch MAF > >sensor on early GM TPI systems. > > > >The only 'weatherpack' connectors I can locate are 6 pin or 4 pin, and >are > >somewhat larger pin size. This is a very similar to the weatherpack, but > >smaller or higher density. > > > >I'm sure someone else has run across this challenge, so your help is > >appreciated. > > > >and yes, the obvious is the GM dealer, but they don't have the 'male' > >connector that would mimic the MAF end, only the female end that is > >actually on the cable. The female end is not the challenge, as I've got a > >salvaged harness that I could butcher one off of, but I'm looking to keep > >in intact unless necessary to butcher it. > > > >Therefore, I'm looking for both M and F, what I'm trying to do is create >a > >diag cable that I can insert inline to a MAF to monitor the signals to > >diagnose either bad MAF's or the control circuits such as the burn-off > >power and airflow signals. > > > >Thanks as always. > > > > > >----- Original Message ---- > >From: Jim Kyser > >To: diy_efi at diy-efi.org > >Sent: Tuesday, April 3, 2007 4:07:47 PM > >Subject: Re: [Diy_efi] weatherpack connectors > > > > > >MJM National sells weatherpack connectors on eBay. They sell both > >pre-packaged kits and smaller quantities. Here is a link to their eBay > >store. They have a 5 pack of those 4 pin connectors for $4 + $1sh and > >the a 5 pack of the shrouds for $2.50 + $1sh. Pins and terminals are > >like $2.50 + $1 for shipping for a package of 25. They combine shipping > >on multiple items. I have bought from them and they ship out quickly. > > > >http://stores.ebay.com/MJM-National-Inc_Weather-Pack_W0QQcolZ2QQdirZQ2d1QQfsubZ12QQftidZ2QQtZkm > > > >Jim Kyser > >1946 Willys CJ-2A w/4.1 liter Buick V6 w/TBI in progress > > > >Rick McLeod wrote: > > > I am aware of Del-City for these, I ordered some, but they backordered > >them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I >need > >to repair a cable ASAP and am up the proverbial backorder tree! > > > > > > I'm looking for 4-pin flat male housings and pins. > > > _______________________________________________ > > > Diy_efi mailing list > > > Diy_efi at diy-efi.org > > > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > > > Main WWW page: http://www.diy-efi.org/diy_efi > > > > > > > > > >_______________________________________________ > >Diy_efi mailing list > >Diy_efi at diy-efi.org > >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > >Main WWW page: http://www.diy-efi.org/diy_efi > >_______________________________________________ > >Diy_efi mailing list > >Diy_efi at diy-efi.org > >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > >Main WWW page: http://www.diy-efi.org/diy_efi > >_________________________________________________________________ >Exercise your brain! Try Flexicon. >http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglineapril07 > >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi _________________________________________________________________ MSN is giving away a trip to Vegas to see Elton John.? Enter to win today. http://msnconcertcontest.com?icid-nceltontagline From dunvegan at sbcglobal.net Mon Apr 16 21:43:56 2007 From: dunvegan at sbcglobal.net (Rick McLeod) Date: Mon, 16 Apr 2007 19:43:56 -0700 (PDT) Subject: [Diy_efi] weatherpack connectors or something like them Message-ID: <743144.55825.qm@web80505.mail.mud.yahoo.com> Since one of these cars is an numbers matching vette, I'm trying to not butcher anything at all! the others I would not care about, but since the vette is really the most pesky problem, the reason for the test cable quest! thanks for the clarification, saves me searching for something that doesn't exist, which I thougth was the case, but my memory was the second thing to go and I can't remeber the first! cheers ----- Original Message ---- From: Ben Heidorn To: diy_efi at diy-efi.org Sent: Monday, April 16, 2007 8:24:10 PM Subject: Re: [Diy_efi] weatherpack connectors or something like them There is no pigtail there i was refering to making you own >From: Rick McLeod >Reply-To: diy_efi at diy-efi.org >To: diy_efi at diy-efi.org >Subject: Re: [Diy_efi] weatherpack connectors or something like them >Date: Sun, 15 Apr 2007 12:39:51 -0700 (PDT) > >Well, I didn't realize there was a pigtail here, I'll look further at the >harness now and see if I can do that, sure would be easier. > >I'm not familiar w/ what you're calling a 'duesche' connector, but I'm sure >I'll recognize it when I see it. > >Thanks for jumping in. > >BTW, if I don't have that on my car, does anyone know if the MAF connector >is a 150 series, or 280 series. Waytek doesn't list a 5 pin (nor have I >found elsewhere) in 150 except 150-GT and all I find there is a kit of all >different sizes for over $80, pircey for what I'm trying to do. > >as always, all help appreciated. > > >----- Original Message ---- >From: Ben Heidorn >To: diy_efi at diy-efi.org >Sent: Sunday, April 15, 2007 2:09:42 PM >Subject: RE: [Diy_efi] weatherpack connectors or something like them > > >Why are you restricting yourself to plug in to the MAF, go 4-6inches down >the harness using a duesche style 6 pin, blanking one of the holes. you can >pick these up at Crown lift trucks or OKI, probably hyster or yale too but >these are or competitors so im not sure. > > > >From: Rick McLeod > >Reply-To: diy_efi at diy-efi.org > >To: diy_efi at diy-efi.org > >Subject: [Diy_efi] weatherpack connectors or something like them > >Date: Sun, 15 Apr 2007 08:55:51 -0700 (PDT) > > > >Well, evidently what I'm looking for is NOT a traditional 'weatherpack' > >connector, although it's on a GM auto! > > > >I'm looking for the 5-conductor connector that mates to the Bosch MAF > >sensor on early GM TPI systems. > > > >The only 'weatherpack' connectors I can locate are 6 pin or 4 pin, and >are > >somewhat larger pin size. This is a very similar to the weatherpack, but > >smaller or higher density. > > > >I'm sure someone else has run across this challenge, so your help is > >appreciated. > > > >and yes, the obvious is the GM dealer, but they don't have the 'male' > >connector that would mimic the MAF end, only the female end that is > >actually on the cable. The female end is not the challenge, as I've got a > >salvaged harness that I could butcher one off of, but I'm looking to keep > >in intact unless necessary to butcher it. > > > >Therefore, I'm looking for both M and F, what I'm trying to do is create >a > >diag cable that I can insert inline to a MAF to monitor the signals to > >diagnose either bad MAF's or the control circuits such as the burn-off > >power and airflow signals. > > > >Thanks as always. > > > > > >----- Original Message ---- > >From: Jim Kyser > >To: diy_efi at diy-efi.org > >Sent: Tuesday, April 3, 2007 4:07:47 PM > >Subject: Re: [Diy_efi] weatherpack connectors > > > > > >MJM National sells weatherpack connectors on eBay. They sell both > >pre-packaged kits and smaller quantities. Here is a link to their eBay > >store. They have a 5 pack of those 4 pin connectors for $4 + $1sh and > >the a 5 pack of the shrouds for $2.50 + $1sh. Pins and terminals are > >like $2.50 + $1 for shipping for a package of 25. They combine shipping > >on multiple items. I have bought from them and they ship out quickly. > > > >http://stores.ebay.com/MJM-National-Inc_Weather-Pack_W0QQcolZ2QQdirZQ2d1QQfsubZ12QQftidZ2QQtZkm > > > >Jim Kyser > >1946 Willys CJ-2A w/4.1 liter Buick V6 w/TBI in progress > > > >Rick McLeod wrote: > > > I am aware of Del-City for these, I ordered some, but they backordered > >them. Does anyone know of another cheap vendor on 1sy-2sy quantity, I >need > >to repair a cable ASAP and am up the proverbial backorder tree! > > > > > > I'm looking for 4-pin flat male housings and pins. > > > _______________________________________________ > > > Diy_efi mailing list > > > Diy_efi at diy-efi.org > > > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > > > Main WWW page: http://www.diy-efi.org/diy_efi > > > > > > > > > >_______________________________________________ > >Diy_efi mailing list > >Diy_efi at diy-efi.org > >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > >Main WWW page: http://www.diy-efi.org/diy_efi > >_______________________________________________ > >Diy_efi mailing list > >Diy_efi at diy-efi.org > >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > >Main WWW page: http://www.diy-efi.org/diy_efi > >_________________________________________________________________ >Exercise your brain! Try Flexicon. >http://games.msn.com/en/flexicon/default.htm?icid=flexicon_hmemailtaglineapril07 > >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi >_______________________________________________ >Diy_efi mailing list >Diy_efi at diy-efi.org >Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >Main WWW page: http://www.diy-efi.org/diy_efi _________________________________________________________________ MSN is giving away a trip to Vegas to see Elton John. Enter to win today. http://msnconcertcontest.com?icid-nceltontagline _______________________________________________ Diy_efi mailing list Diy_efi at diy-efi.org Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi Main WWW page: http://www.diy-efi.org/diy_efi From efi at dyakron.com Mon Apr 16 21:58:15 2007 From: efi at dyakron.com (Mike V) Date: Mon, 16 Apr 2007 22:58:15 -0400 Subject: [Diy_efi] O2 sensor mounting References: <931658.22909.qm@web80515.mail.mud.yahoo.com><004701c78053$b297c440$6401a8c0@flamingo><005501c78068$a6a5db30$6401a8c0@flamingo> <002701c78072$31e8b5b0$6901a8c0@BILLYBOB> Message-ID: <003e01c7809c$3eefb9a0$0b01a8c0@IBMm> The GMC Syclones & Typhoons used the heated GM sensor just downstream of the turbo, pointing straight down. mv ----- Original Message ----- From: "Jason M." To: Sent: Monday, April 16, 2007 5:57 PM Subject: Re: [Diy_efi] O2 sensor mounting > You want the heated sensors pointing down. Also the aftermarket wide band > sensors/controllers will also instruct you to leave the heater off for a > few seconds so any condensation in the exhaust can be blown out. Hot > ceramic + relatively cool water = dead sensor. At least this is what > they say. Maybe you can get away with more with a narrow band sensor? > ----- Original Message ----- > From: "Frank McCracken" > To: > Sent: Monday, April 16, 2007 4:48 PM > Subject: Re: [Diy_efi] O2 sensor mounting > > >> So that makes me think, Is it just the non-heated O2 sensors that need to >> be >> mounted pointing downwards? >> Frank. >> >> >> ----- Original Message ----- >> From: "Frank McCracken" >> To: >> Sent: Monday, April 16, 2007 11:18 AM >> Subject: Re: [Diy_efi] O2 sensor mounting >> >> >>> Thanks guys, it is a heated sensor. And it is a bit of a function over >> form >>> machine..... not quite a track beater tho. >>> >>> >>> ----- Original Message ----- >>> From: "Rick McLeod" >>> To: >>> Sent: Monday, April 16, 2007 9:21 AM >>> Subject: Re: [Diy_efi] O2 sensor mounting >>> >>> >>> > I personally would hide the sensor, and as for the condensation thing, >> I'm >>> not too sure I buy that rational, as there isn't going to be a major >>> temp >>> difference when running at normal op temp, in all the reading on these >> I've >>> done I've never see or read anything that directly discusses position >>> vs. >>> longevity, which is what I believe the condensation theory is based on. >>> Furthermore, if that is a major concern, maybe using a heated element >> would >>> also minimize the concern, works when they're mounted significant >>> distance >>> from the exhaust port during cool weather, but from my experience w/ >>> good >>> 4>1 headers the temp at the collector tube is still reasonably high, so >>> I >>> can't imagine you're gonna see any problems. >>> > >>> > good luck, just my 2 C worth, cheers >>> > >>> > >>> > ----- Original Message ---- >>> > From: Frank McCracken >>> > To: diy_efi at diy-efi.org >>> > Sent: Monday, April 16, 2007 10:55:45 AM >>> > Subject: [Diy_efi] O2 sensor mounting >>> > >>> > >>> > I am installing my Hooker side exhaust on my '65 Corvette. I would >>> > like >> to >>> mount my O2 sensor at about 5:o'clock in the 4" tube so that it will be >> not >>> hanging out there. The collector with this system is outside of the >> fender. >>> My choices would be on top or down low on the inside to hide it. I hear >> that >>> it should be pointing down so condensation will run off. The sensor has >> been >>> at about 4:o'clock in my old system for the last 2 years will no ill >> efects. >>> If it's gotta hang out so be it. What should I do, anyone? >>> > Frank >>> > _______________________________________________ >>> > Diy_efi mailing list >>> > Diy_efi at diy-efi.org >>> > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >>> > Main WWW page: http://www.diy-efi.org/diy_efi >>> > _______________________________________________ >>> > Diy_efi mailing list >>> > Diy_efi at diy-efi.org >>> > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >>> > Main WWW page: http://www.diy-efi.org/diy_efi >>> > >>> > >>> > -- >>> > No virus found in this incoming message. >>> > Checked by AVG Free Edition. >>> > Version: 7.5.446 / Virus Database: 269.4.0/761 - Release Date: >>> > 4/14/2007 >>> 9:36 PM >>> > >>> > >>> >>> _______________________________________________ >>> Diy_efi mailing list >>> Diy_efi at diy-efi.org >>> Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >>> Main WWW page: http://www.diy-efi.org/diy_efi >>> >>> >>> -- >>> No virus found in this incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.5.446 / Virus Database: 269.4.0/761 - Release Date: 4/14/2007 >> 9:36 PM >>> >>> >> >> _______________________________________________ >> Diy_efi mailing list >> Diy_efi at diy-efi.org >> Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi >> Main WWW page: http://www.diy-efi.org/diy_efi >> > > > _______________________________________________ > Diy_efi mailing list > Diy_efi at diy-efi.org > Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi > Main WWW page: http://www.diy-efi.org/diy_efi From chris at chriswilson.tv Fri Apr 27 16:47:30 2007 From: chris at chriswilson.tv (Chris Wilson) Date: Fri, 27 Apr 2007 22:47:30 +0100 Subject: [Diy_efi] Greg Hermann??? Message-ID: <58754921.20070427224730@chriswilson.tv> 27/04/2007 22:45 Does anyone here remember Greg Hermann posting? It's a very long time since I caught on of his fascinating contributions, is he still around? Thanks. -- Best Regards, Chris Wilson. mailto: chris at chriswilson.tv From A6intruder at myo-p.com Sat Apr 28 16:22:24 2007 From: A6intruder at myo-p.com (Daniel Nicoson) Date: Sat, 28 Apr 2007 17:22:24 -0400 Subject: [Diy_efi] Greg Hermann??? In-Reply-To: <58754921.20070427224730@chriswilson.tv> Message-ID: Chris, I looked in my own archives, the last I see a post from Greg Herman was April 2005. Maybe he is just listening? Dan Nicoson -----Original Message----- From: diy_efi-bounces at diy-efi.org [mailto:diy_efi-bounces at diy-efi.org]On Behalf Of Chris Wilson Sent: Friday, April 27, 2007 5:48 PM To: diy_efi at diy-efi.org Subject: [Diy_efi] Greg Hermann??? 27/04/2007 22:45 Does anyone here remember Greg Hermann posting? It's a very long time since I caught on of his fascinating contributions, is he still around? Thanks. -- Best Regards, Chris Wilson. mailto: chris at chriswilson.tv _______________________________________________ Diy_efi mailing list Diy_efi at diy-efi.org Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi Main WWW page: http://www.diy-efi.org/diy_efi From ssealander at Stny.rr.com Sat Apr 28 19:49:37 2007 From: ssealander at Stny.rr.com (Scot Sealander) Date: Sat, 28 Apr 2007 20:49:37 -0400 Subject: [Diy_efi] Greg Hermann??? In-Reply-To: Message-ID: <200704290049.l3T0nbNx005953@ms-smtp-01.nyroc.rr.com> He last posted in January of this year, on the Donegan ECU. (bearbvd) Scot -----Original Message----- From: diy_efi-bounces at diy-efi.org [mailto:diy_efi-bounces at diy-efi.org] On Behalf Of Daniel Nicoson Sent: Saturday, April 28, 2007 5:22 PM To: Chris Wilson; diy_efi at diy-efi.org Subject: RE: [Diy_efi] Greg Hermann??? Chris, I looked in my own archives, the last I see a post from Greg Herman was April 2005. Maybe he is just listening? Dan Nicoson -----Original Message----- From: diy_efi-bounces at diy-efi.org [mailto:diy_efi-bounces at diy-efi.org]On Behalf Of Chris Wilson Sent: Friday, April 27, 2007 5:48 PM To: diy_efi at diy-efi.org Subject: [Diy_efi] Greg Hermann??? 27/04/2007 22:45 Does anyone here remember Greg Hermann posting? It's a very long time since I caught on of his fascinating contributions, is he still around? Thanks. -- Best Regards, Chris Wilson. mailto: chris at chriswilson.tv _______________________________________________ Diy_efi mailing list Diy_efi at diy-efi.org Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi Main WWW page: http://www.diy-efi.org/diy_efi _______________________________________________ Diy_efi mailing list Diy_efi at diy-efi.org Subscribe: http://lists.diy-efi.org/mailman/listinfo/diy_efi Main WWW page: http://www.diy-efi.org/diy_efi From bearbvd at mindspring.com Sun Apr 29 00:40:06 2007 From: bearbvd at mindspring.com (bearbvd at mindspring.com) Date: Sun, 29 Apr 2007 01:40:06 -0400 Subject: [Diy_efi] Greg Hermann??? Message-ID: <380-2200740295406246@M2W040.mail2web.com> Original Message: ----------------- From: Scot Sealander ssealander at Stny.rr.com Date: Sat, 28 Apr 2007 20:49:37 -0400 To: diy_efi at diy-efi.org Subject: RE: [Diy_efi] Greg Hermann??? He last posted in January of this year, on the Donegan ECU. (bearbvd) Scot -----Original Message----- From: diy_efi-bounces at diy-efi.org [mailto:diy_efi-bounces at diy-efi.org] On Behalf Of Daniel Nicoson Sent: Saturday, April 28, 2007 5:22 PM To: Chris Wilson; diy_efi at diy-efi.org Subject: RE: [Diy_efi] Greg Hermann??? Chris, I looked in my own archives, the last I see a post from Greg Herman was April 2005. Maybe he is just listening? Dan Nicoson -----Original Message----- From: diy_efi-bounces at diy-efi.org [mailto:diy_efi-bounces at diy-efi.org]On Behalf Of Chris Wilson Sent: Friday, April 27, 2007 5:48 PM To: diy_efi at diy-efi.org Subject: [Diy_efi] Greg Hermann??? 27/04/2007 22:45 Does anyone here remember Greg Hermann posting? It's a very long time since I caught on of his fascinating contributions, is he still around? Thanks. -- Best Regards, Chris Wilson. mailto: chris at chriswilson.tv Yep, I'm alive and been lurking. Greg -------------------------------------------------------------------- mail2web.com - Microsoft? Exchange solutions from a leading provider - http://link.mail2web.com/Business/Exchange From chris at ourtoyz.com Mon Apr 30 21:41:27 2007 From: chris at ourtoyz.com (Chris Walsh) Date: Mon, 30 Apr 2007 21:41:27 -0500 Subject: [Diy_efi] Autoprom for sale Message-ID: <000001c78b9a$37fb77c0$6e01a8c0@chris> I have for sale a used Autoprom1, APU1 Bluetooth adapter and a LC1. 1st: The autoprom is in great working order I just no longer need it. I should have gone a different route. Any way I am asking $275 for the used APU1, ALDL cable, USB cable, software CD and 2-512k chips 2nd: I have the bluetooth adapter so you can go wireless from the laptop to the APU1. I would like to get $50 for it. 3rd: Innovative Motorsports LC1 w/ WBO2 sensor. The sensor have never been used. The harness was installed in the car but never hooked up. It does NOT come with a bung. I used it :) I would like $175 for it. If some one would like to purchase all of these items at once I would make a deal at $475. All of these prices do include shipping. If you have any questions please ask. Chris Email me privately & I can send photos and answer questions you may have.