DIY_EFI Digest Saturday, 31 August 1996 Volume 01 : Number 254 In this issue: Re: speaking of displays & DPM FORTH Re: Newer VATS Vehicles Re: Bosch to Hitachi MAF [none] Sensor Wiring Re: Sensor Wiring Re: Corvette mounted coils on the GEN III engine Re: Newer VATS Vehicles See the end of the digest for information on subscribing to the DIY_EFI or DIY_EFI-Digest mailing lists. ---------------------------------------------------------------------- From: Jedc@xxx.au Date: 30 Aug 1996 21:20:40 EDT Subject: Re: speaking of displays & DPM DI>Fred Miranda wrote: DI>> DI>> Maybe I have an odd LCD pannel (2x20, I doubt it). Mine turns black when t DI>> car warms up in the sun. DI>Sounds more like the components used for adjusting contrast are changing DI>values DI>due to the heat... Not Thats pretty much standard behaviour for LCD displays , moral , keep em cool ! ------------------------------ From: cloud@xxx.edu (tom cloud) Date: Fri, 30 Aug 1996 09:48:01 -0500 Subject: FORTH On August 19, Darrell Norquay wrote: I've been thinking about learning FORTH for a long time, but that's as far as it ever got. There is a company called New Micros Inc. who specialize in FORTH embedded systems. They have compilers for all the 68HC*** processors, and possibly more as well. I don't have the address here, but I can dig it up if you want... regards dn dnorquay@xxx.com ============================================================ Don't know if anyone cares, but I was looking through some old postings and saw what dave wrote to me (above). So, here are some musings about FORTH. FORTH 'should' be as portable as 'C'. It 'should' be higher level, yet still allowing in-line assembly code where needed. It's fast, very compact. It allows 're-defining' functions on the fly. It is both an interpreter and a compiler (sorta like BASIC, except with BASIC you gotta buy the compiler and usually get stuck with someone's crummy run-time module -- or worse, P-code). I'd hope one could get an easily ROM-able product now, don't know. Basic concept: one writes a 'kernel' in the code of the particular processor. Then 'words' (or definitions of functions) are written using the basic functions of the kernel (spec. OR, AND, NOT, +, -, *, /, ^, SHIFT, ROTATE, etc). It's been probably 12 years since I've used it, so my bremembrance ain't so good. The neat thing to me was -- it could be used in an interpreter mode -- at any level of development (i.e., could 'compile' definitions to a certain level and then 'play' with it in interpretive mode) -- Each 'word' could have meaning (e.g. 'LIGHT_OFF', or 'INJ_PULSE') and, of course, parameters could be passed to it either on a stack or from a memory variable (the version I used could not implement a table, so had to load variables from a 'word'). -- as opposed to 'C', it uses 'real' words (ex. 'NOT' rather than '!'), not weird programmereze. -- and there's other reasons I liked it, I think (there's two things that go first as you get older, I just can't remember either of them at the moment). The main reasons I didn't like it: -- No one made a product (I used a Z-80 product called StackWorks Forth) that really worked like I wanted. Seems many are stuck in what I call the 'Pascal' mode. I.E.: By God we're gonna force you to write structured code or abide by some other stupid rule. [To my notion, if I want to use my damned screwdriver as a chisel, I will!! And if I want to JUMP or GOTO, I will. Hell, if I want to execute a GOSUB without a RET, I will!!] ((Where's the fun if you can't execute multiple branches from 'variable' jump tables so that even you can't figure out why or where you are??)) I guess if it ain't the BATF, it's the dreaded Software Police. -- Secondly (if that's a real word), FORTH code is known as "write-only-code". You'd better document carefully, because even you won't be able to figure out what you did after the program gets large and some time goes by. (Sure, INJ_ON takes a parameter from the stack, signifying time in mS, and pulses the injector ON for that long, but how does it really do it -- and if you change one of the lower order definitions will it affect INJ_ON? It's 'threaded' code, which explains how it can do so much in so small a space, but the threads can get real convoluted and, if you're not careful, 'upgrades' can be deadly.) Oh well, just stirring the cauldron. tom cloud ------------------------------ From: Donald Whisnant Date: Fri, 30 Aug 1996 11:14:13 -0400 Subject: Re: Newer VATS Vehicles > > From: "John Faubion" > Date: Thu, 29 Aug 1996 22:01:00 -0500 > Subject: Re: Newer VATS Vehicles > > Technical knowledge is great but it doesn't necessarily give you time to > defeat it. The guys here that have cracked it have done it one of two ways. > Either by trying each of 15 resistor values until it unlocked (with a 3-4 > minute delay between each try) or by hacking the PROM which requires > removing the computer, pulling the CalPak, removing the PROM, downloading > it, editing it, blowing a new PROM and putting it all back together again. > A thief just doesn't have the time to do all of this. He might be able to > carry a spare CalPak with a modified PROM already in it but even if the > thief decides to concentrate on a Corvettes there are about 8 different > CalPaks he would have to carry. It still easier to use a tow truck or steal > the keys. > > John Faubion > jfaubion@xxx.net > Actually not... All you need to do is build a little 555 oscillator circuit with quick connect wire tap connectors --- 2 power leads and one output lead ... pop the hood, find the right wire on the PCM (assuming F-Body where the PCM is mounted under the hood) or find the right wire under the dash ... tap the circuit into the "fuel enable" lead and presto.. For those with a "starter enable" relay, just unplug the relay and plug in a "enable jumper pack" ... Donald Whisnant dewhisna@xxx.com ------------------------------ From: cloud@xxx.edu (tom cloud) Date: Fri, 30 Aug 1996 12:25:25 -0500 Subject: Re: Bosch to Hitachi MAF Andrew Rabbitt wrote: > >Like all other MAFs, the Hitachi unit (I presume it's a bypass unit >similar to that fitted to the previous model Taurus, and many other >Fords), is non-linear and therefore a 2-point calibration will not be >adequate. > I offered an op-amp solution. I know n-nothing about MAF's. But, if the two MAF's in question simply have inverted outputs and different ranges, then (maybe) the non-linearity for one occurs similarly to the other (except inverted) -- maybe. If so, the ECU already corrects for the stock unit and the simple op-amp circuit that makes the different one 'look' like the stock will work. Looks like one needs data sheets on the sensors. tom cloud ------------------------------ From: Todd King Date: Fri, 30 Aug 96 12:52:00 PDT Subject: [none] <<< train it to drive >the car for you. It'd get great repeatable 1/4 mile times, and would >probably be great on the road course also. Yeah, all you need is a few Intel Hexium Processors, a Gig of RAM, and a terabyte hard disk or two... regards dn dnorquay@xxx.com >>> Got a server system with 4 PPro's @ 200MHz, 4GB RAM, plus racks of SCSI hard disks; when do we start? :-) Todd Todd_King@xxx.com ------------------------------ From: "John C. Alsina" Date: Fri, 30 Aug 1996 17:22:34 -0400 Subject: Sensor Wiring I want to use an LM34 three-terminal temperature sensor to measure engine coolant temperature. The sensor can drive about 50pF. Let's assume 3 to 6 feet of wire between the sensor and the A/D input on the CPU board. That makes a nice antenna to pick up ignition and other noise and trash my sensor reading and maybe damage the processor. What's the drill for wiring/conditioning such a (slow-moving) input? Use resistance in series and capacitance across the sensor and the A/D input? Should I use shielded cable? If so, how/where do I ground it? Need a practical solution to a practical problem. Thanks for your input. John Alsina ------------------------------ From: Dirk Wright Date: Fri, 30 Aug 1996 20:29:20 -0400 (EDT) Subject: Re: Sensor Wiring On Fri, 30 Aug 1996, John C. Alsina wrote: Should I use shielded cable? If so, how/where do I > ground it? Need a practical solution to a practical problem. Thanks for your > input. Since you said three terminal, I would use shielded, twisted pair audio cable. It has very good noise rejection. I'm not sure about which, if any of your three wires is ground. The cable is used in balanced lines where the twisted pair are the + and -, and the shield is grounded, but doesn't provide any current. Hope this helps. **************************************************************************** Dirk Wright wright@xxx.gov "I speak for myself and not my employer." 1974 Porsche 914 2.0 "A real hifi glows in the dark and has horns." 1965 Goodman House **************************************************************************** ------------------------------ From: Daniel R Burk Date: Fri, 30 Aug 1996 22:47:54 -0700 Subject: Re: Corvette mounted coils on the GEN III engine The new Corvette Gen III engine has one coil per cylinder. Each coil is mounted in the composite valve covers, four per cover. A single plug wire extends from each coil to the spark plug. The length of the wire is about five inches. It seems like an interesting idea. - --- DRB ------------------------------ From: "John Faubion" Date: Fri, 30 Aug 1996 23:15:05 -0500 Subject: Re: Newer VATS Vehicles > Actually not... All you need to do is build a little 555 oscillator > circuit with quick connect wire tap connectors --- 2 power leads and > one output lead ... pop the hood, find the right wire on the PCM > (assuming F-Body where the PCM is mounted under the hood) or find > the right wire under the dash ... tap the circuit into the "fuel > enable" lead and presto.. For those with a "starter enable" relay, > just unplug the relay and plug in a "enable jumper pack" ... Donald I think it would still be easier with the tow truck than taking the time with the hood up. Most people don't even give a tow truck a second look. Someone picking around under the hood of a Corvette or under the dash in a F-body might be a bit more noticeable. John Faubion jfaubion@xxx.net ------------------------------ End of DIY_EFI Digest V1 #254 ***************************** To subscribe to DIY_EFI-Digest, send the command: subscribe diy_efi-digest in the body of a message to "Majordomo@xxx. A non-digest (direct mail) version of this list is also available; to subscribe to that instead, replace "diy_efi-digest" in the command above with "diy_efi".