superlen

Sarah, As Captain said, there are several unused pins on the ECU. Not only do you run into the harness wiring issues, but there is another hidden one as well. On the stock ECU, many of the unused pins aren't actually loaded on the connector. I'm assuming to save money, they just didn't mold those pins in. So while they are available in location, there's no physical connection down to the pcb. This is only a problem if I re-use the stock connector on the new PCB which is undecided at this point, but I think it's a good backup plan if the supply of Connectors becomes problematic. The missing pins aren't a problem for true plug-n-play, but one important pin is annoying. Pin 20 is a wire from the FI relay and +12V on this pin will fire the fuel pump. It's wired and ready to go in the harness so the ECU could control the fuel pump if it wanted to (and I want to). I have an option in the GUI to turn on a fuel pump prime pulse for 3-5sec (configurable) every time you turn the key on. This was to let those that have a leaky check valve (myself included) to ensure there is good pressure in the line before start. However, that pin isn't connected down to the pcb, so if we re-use the stock connector we have to move that wire in the harness. Not hard, but not plug-n-play if you want the new feature of Fuel Pump Prime. The same thing exists with the cold start valve. However, I don't care about controlling it. There will also be an auxiliary harness option so extra pins could be in it. This would be a short 6" harness that comes out the back and has a free-hanging connector. It's primarily for ignition IO connections for tying to the disty or even a crank angle sensor if someone wants to add a ring & sensor. A few GPIO will be in there as well for fan relays, or ??? This connector isn't defined fully yet. Thoughts anyone? Also, I should note, that the two inputs will be duplicated on both the ignition connector AND two spares on the ECU. These are earmarked for inputs from the disty. All the ECM needs is a reluctor input from the disty to completely take over spark control. By adding those two locations in the ECM harness, someone who wants a really clean stock look can add just two wires to the stock harness and run them 4' over to the ignition module under the glove box & connect to that harness. They won't even have to penetrate the firewall. Now, the stock ignition module can be pitched, and the ECM takes over with programmable ignition maps. Woot Woot! On the USB cable, I think the consensus is that a short pigtail (6" or so) that can hide no problem will work well. It will have a usb A female connector on it. That allows a common usb A-A extension cable to be used to connect to the laptop. I'll supply one with the unit, but they are common as dirt now so when the user loses it they can get another easily. If the user did want to get nifty, they could add their own extension cable with a nice plug in socket someplace else like glove box, console, ect. Lenny

Blue, If the bulkhead connector won't fit, I think that is the next best choice. I'll run a 6" pigtail out with a female usb a. It can still be right there where the current access hole is. Capt.. I thought about BTooth right off the bat, but held off. I did decide on using an injector driver IC like you had brought up earlier in the thread though. They are more common now and availability is good. I chose a MC33810. There will be two on there & this will allow us to have enough outputs to also do ignition timing. Lenny

Update & Opinion solicited: After quite a bit of work on the software, I've transitioned to finishing up the schematic and board layout. The software is taking shape nicely. I have the system responding to RPM, AFM, MAP, & Intake Air Temp and calculating pulse widths appropriately. I still need to add in the code to handle all the system enrichments, but the basic guts would now meter fuel correctly if I had hardware to test with. Thus the switch to schematic and layout. Due to the mechanicals of the factory case and mounting locations, I'm having trouble locating the usb connector where I want it. The usb port will be for updates and/or any tuning the user wishes to do. In a simple stock setup, it doesn't even need to be there. However, if someone upgrades to a hotter cam, or adds other goodies, eliminates the AFM, ect... they will need to get to it at least once during setup. My original plan was to have a panel mount connector in the housing & the user could plug into it. This connector was to be located in the top left of the case as there is already an access hole in the plastic toe kick panel that hides the ECU. For anyone familiar with looking at the ecus this is exactly where the model sticker is located. That's apparently what the hole in the toe kick is for, to allow someone to check the number without pulling the toe kick panel. This would be a really nice clean setup & the ideal spot for a usb bulkhead connector.... However, due to some other mechanical clearances, I don't know if I will be able to mount it there. I have some other options that I have considered. 1. Mount in in the bottom right of the ECU.. This would require the user to add another hole in their toe kick to get to the connector to plug in which I don't like at all. 2. Just have the usb cable itself come out of the box & dispense with the bulkhead connector altogether. This is better in that there is less cables/connectors. However, it has the downside that the cable is then attached to the ECU all the time & would need to be coiled up and hidden under the dash when not used. To tune, one would unroll the cable out and plug into the laptop. This is probably ok, but I'm not thrilled with it. 3. A modified approach to number 2. Use an extension cable that comes out of the ECU but has the bulkhead connector on the end. This connector could be then mounted under the dash much like an OBD connector is. The user would then connect the laptop via another typical USB A to B cable. I'm open to any thoughts or other ideas that anyone has. I haven't completely give up on the top left location, I'm waiting for the panel mount connector to come in so I can test how well it fits, but I'm not confident there is enough room. Lenny

Captain, You have done more investigating than I on the internals. My investigation was mostly just modeling up the enclosure in cad to make sure the new circuit board fits, & making the pinout match. Blue, I know the L-jet was in quite a few different vehicles, but I'm not sure how many still have enough followers to make any really huge market. Without any market analysis, my gut feel says I'll most likely break even after a year or so which is fine. If I start buying Porsches that may stretch to...forever. Lenny I

You can't be an engineer in Arkansas unless you do some project related to chickens. It may be a state law?? I've worked on poultry skinners, evisceration equipment, turkey baggers, popup timer inserters, automatic weighing systems, chicken house dimmers, curtain controllers....it's a good think I like chicken. If we can ever connect in the same city sometime, I'll buy beer...and or course chicken. I haven't reverse-engineering the analog ecu mutch, but it doesn't surprise me that they did some careful layout. I'm still constantly amazed at how well they made that system work with the technology they had. Of course, I was always in awe of my father rebuilding a carb & actually understanding them as well. He was an old school mechanic and owned a garage/body shop in the small town I grew up in. When the electronics began showing up in the late 70s, early 80's. He was in his early 50s and was quite annoyed with anything electronic controlling an engine. His theory on engine tuning was if you can't turn it, bend it, or drill it, it should just be set on fire and rolled into the creek. I was in my early teens at that time, loved electronics, & so naturally ended up debugging most electronic issues. That's what made me decide to become an EE. I have to fix a massive injector rail leak on the Z today, but once fixed I'm hoping to start characterizing the pulse widths at some know conditions and then compare them to some of my calculated values. I have several sets of wiring harnesses and extra sensors so I'll make a bench test setup as well...assuming I can find my bench. It's currently completely covered with parts, tools, the cat, ect. Lenny

Scott, Glad you're up and going again. I'm still wondering what path the current took to get though the links??? Captain I both typed the same thing. (Wrong of course. ) I may need to refresh on the schematics and wiring of those links, is one or more of the links in the ground path? Lenny

Captain, I too though the exact same.. just model the transfer function and knock it out....then damn feature creep. And, when I have the interrupts flaking out, I'll do more than tell you about, I'll put a scope in your hand and have you babysit/trigger on the event while I drink beer. haha. Loop time is no problem. All timing inputs/outputs are input capture & output compare timers accordingly. The only thing main does is check the serial, read the sensors, calculate the pulse start/stop times, set the timer registers. Plus, it's running at 100mhz & has a floating point unit so the "calculate the pulse start/stop" step should also be blazingly fast. That's why I thought about just using floats. I ended up NOT doing that; most are all integers. It makes the code a little less readable as units are sometimes 10x or 100x larger than displayed on screen. As for the injector drivers..I hate 'em. They work great, not too expensive, have lots of handy features for short circuit test/reporting ect, and are packaged well. However, the supply side of the equations sucks. Since they are primarily sold to the large OEMs, you are at the mercy of what the OEMs want. If they change to a newer style, your supply then drys up. Back in the 90s I had an industrial chicken skinner that I used one on to drive some external solenoids, and every 6 months they would go obsolete and be replaced by a newer/better part. Granted, that was early on in FI driver IC development, so designs and supply are more likely stabilized now, but it left a sour taste in my mouth. My plan was to use some discreet FETs so that there were multiple manufacturers to ensure a good supply & not be sole-sourced to one specific part. It would be easier to use a driver though (less design time, less testing, more features). I should look back into them again and see what the supply chain looks like now. It's possible that more than one manufacturer has adopted a common package/function. I didn't know that they were available with battery correction built in. I wonder how they accomodate different characteristics of injectors? Thanks for asking about these. I'll be able to support both low & high impedance injectors, but for now to get the plug and play going, I'll just use stock high impedance. You'll still need your resistor pack. Len

Scott, You're on the right track by making sure the fuel pump is working. Do you normally here it when you start up? Sometimes the sound of the starter covers it up. Don't worry about the ECU yet. It doesn't actually control the fuel pump at all. It may actually be dead, but I don't think it's likely. The fuel pump can be turned on by two things: 1. A switch in the Air Flow Meter that turns on anytime the flap is being pushed by air (or your finger) 2. turning the ignition switch to START. Our pumps don't do a timed prime when you just turn on the ignition. The easiest way to test is to pop the hood and pull the small solenoid wire going to your starter solenoid. It just plugs on so no tools needed. Now try to start the car with the key. You wont here the car crank as you just disconnected the starter solenoid, but the start signal should hit the FI relay and cause it to power the pump. You should definitely hear the fuel pump now with the engine quiet. Also look for mechanical issues from the event (assuming your battery was sliding around hitting things), and melted ground wires. When a battery + post grounds the frame the current is going to flow through the easiest path from the + post to the - post. Hopefully that is from the + post into the frame (where it just touched) through the frame to the nearest/best ground strap, into the ground strap, back to the - post. Notice, there are no fusible links/fuses anywhere in that path. You shorted *before* them. (right at the post) That's why you saw smoke instead of heard "poof" and then nothing as a fuse blew. The insulation on your wires was melting from the heat. The good thing is that this current path doesn't go through *ANY* components, not a switch, not a light bulb, not an ECU, so a massive current event didn't go through those. (Voltage spike is another critter I'll ignore for now). Check all your ground wires in the engine compartment and look for melted insulation and verify that they are still in fact grounded. I don't have a schematic handy, but I believe there is one specific ground wire for the EFI system up there near the battery.

RCB, That's hilarious on the K&N filter. The Zfuel in plug n play mode could not be detected unless someone: 1) pulled the drivers side kickplate off 2) Disconnected/removed your ecu 3) Opened the case to look at the printed circuit board 4) & knew the difference between late 70's electronics and modern electronics. The only thing that may make them curious is that your emissions should be lower than any Zcar they have every measured. I'm obviously not the one to condone tricking the 'man' in this manner, I'm just saying that it's possible. Lenny

Captain, WARNING: A bunch of geeky programmer stuff to follow for Captain's piqued interest. Others may get bored. You're buddy is right...you're out of touch..errr I mean today's compilers are way better/more predictable. I think what really killed assembly programming is speed. Chips today just run so damn fast that speedy assembly code isn't that critical for most applications. Even if the compiler does silly things & bloats the code, it still runs 100 times faster than it has too. I've noticed myself migrating my code style from effeciency -> readability. I'll code up a function now and make sure it's readable and understandable to whoever looks at it later & I don't worry about efficiency. Sometimes I have to go back and tweak it for performance, but it's getting more and more rare. On this project I find myself waffling between oldschool (optimizing variable sizes for sensor readings & upcoming math functions on them) vs newschool. (make 'em all floats and let the ALU do it's thing). For speed of development I probably should just make most floats, but so far I haven't. Many vars are integers with a resolution of tenths. Here's a copy of one of my structures. //Engine typedef struct { //fixed vars UINT16 Num_Cylinders; UINT16 Num_Injectors; float Bore; //in mm float Stroke; //in mm float Displacement; //in cc's float Degrees_Per_Cycle; //realtime vars UINT16 BAT; //in tenths of volts UINT16 RPM; //revs/min UINT16 MAP; //in tenths of kPascal UINT16 MAF; //mass airflow in g/s from aftermarket MAF UINT16 AFM; //mass airflow from stock AFM UINT16 IAT; //Intake Air Temp in tenths of deg F UINT16 CLT; //Coolant Temp in tenths of deg F UINT16 EGO; //EGO Narrow Band UINT16 AFR; //Wideband AFR tenths UINT16 BAR; //in tenths of kPascal - set at startup UINT16 TPS; //throttle position %- true analog if aftermarket is used //If stock system, 0=idle, 100.0 = WOT, UINT16 Pulse_Width; //cur pulse_width in uS UINT16 Status; //System Status - uses bit defines above //b.0 - b.15 } ENGINE_struct; It's a 32bit processor so it would be better if my UINT16's were 32, but I wanted to keep the size down so when I transfer to the PC, I can send it over the link faster. I want a nice snappy interface for feedback/tuning. I though about two different packets going back: One that has only a few vars that change the fastest: RPM, MAP, ICPW, TPS, AFM and then another that reports slow sensors such as CLT,IAT and such, but I think that's overkill. The link is 115200 & I can do all the above sensors (around 30bytes) in 2.5ms if I send in raw hex. If I send in ascii (which is more handy to debug/test) it's more like 10-12ms which is still plenty fast enough. The simulator I have updating at 100ms (10/sec) and it's still quite snappy and responsive on the graphs/gauges. The A/Ds by the way are all 16bit as well. The pic line would also make a good starting point. I've done several smaller pic projects, but never anything with their larger parts. Coming from a Motorola background, I could never get past their 'Not Bit test skip if not clear | the moon phase is waning' method of branching. It always made my head hurt. Lenny

Captain, I didn't read anything else into your post. I knew where you were coming from. I also happen to agree with most of it. (I would do the beer thing Icon if I were smarter). RCB, How do they define tampering? Such as my example of non Nissan factory vacuum lines? Obviously I think any sane person would agree that the ECU going from 1977 analog to 2012 digital *might* be considered tampering in the first degree. I'm just wondering how/where they draw the line. I'm not saying it's good/bad either way. Most laws/regulations have at their base a good reason (or at least they did when they started). I was just interested in how they determine if you are a "tamperer". It's quite the foreign concept here. We don't even have to have our car inspected to see if all the lights/horn/ect work. We did back in the 80s, but not now. You just go to the dmv, pay your money, prove you have insurance, and they give you tags. You can of course get a ticket if you are driving around with something broken. Lenny

Captain, You obviously have a lot of the same background as me from your comments. FYI, there's nothing open source, nor any RTOS. I personally really hate developing firmware within an RTOS environment. I understand that there are places where it's useful, handy, & faster to market....but I'm still a lil' old school. However, not so much that I still write everything in assembly. I did hold onto assembly as long as was feasible, but many of my clients don't care about C vs Assy & it just costs them more for me to write in Assy so I migrated to C quite a few years back. The original code I wrote for this in '93 in fact was 100% Motorola assembly. The firmware that runs in the car is written in straight C (not C++) with just a little bit of assembly at startup. It's also all my own C code so I do know exactly everything that's going on, no third party libraries or objects. Oh, and no fuzzy logic was harmed in it's creation. Side Note:We have a project going on at work that are the controls for large water treatment systems, such as cooling towers, industrial chillers, large public pools, ect. It is like Zfuel in that we read a bunch of inputs & flow rates & such, and then control pump deliveries of acid or similar chemicals to control the target. Much the same stuff as Zfuel, but way more boring. Anyhow, the customer requested a fuzzy logic loop for controlling PH is really large pools and OMG it makes your head hurt. And testing is all but impossible as we can't have an Olympic size pool in the shop, no matter how much I want one. The GUI is in C++ and of course has gobs of third party libraries/objects for graphic widgets and what not. Lenny

I hadn't realized how strict CA was but after fielding a few questions about Zfuel from CA owners, I am beginning to understand. Zfuel would work very well for you "race" application in California. I'm sure no one would leave it in place during testing at the smog shop. I'm in Arkansas and we have very few regulations on emissions. I'm sure there are some, but no one knows what they are. Out there, does the law state you can't have ANY modification to your fuel/emissions system at all that aren't factory? Even if it actually improves emissions greatly? Just thinking out loud, technically you could extrapolate that to disallow any vacuum hose that isn't from the Nissan factory. There is obviously quite a jump from vacuum hose to ECU, but both would be a form/fit/functional replacement. Lenny

Now you're just teasing. Cruel... I tell you. haha.

Here's another screen shot showing just a bunch of settings and calculations. Unless you're tweaking the system quite a bit, none of these will ever be touched, but they are needed to test the combinations. This screen needs a lot of work to make it easy to find the right option/configuration and understand what they do. For now, they are just lumped into one big scary screen of numbers. screenshot2 | Flickr - Photo Sharing! Lenny

Here's a quick screen shot. I tried to attach inline, but couldn't get the upload manager to be happy. It's not real pretty at the moment. It's mostly being used to test they system and I tend to splat buttons and crap all over the place just to test this or that. I'll clean it up and make it user friendly towards the end. For now, it's just a tool. screenshot1 | Flickr - Photo Sharing! This shows about a 7ms pulse being calculated at 4300rpm 100kpa so pretty much WOT. There is no enrichments enabled & the VE table is just total SWAG at this point so who knows if that is an accuate pulse. I'm betting no. The form at the bottom lets me fake out sensor settings, then the realtime code processes, calculates air mass->fuel mass->enrichments->fuel pulse width. After that it sends it back to the main form though the fake communication link and the GUI draws the pulse train & updates some gauges/icons/bar graphs ect. You can see the two 7ms fuel delivery pulses for this cycle, and the Speed Density cell is light blue in the 5000rpm and 100kpa col/row. For Stock AFM mode, air mass will be pulled from our Air flow meter instead of calculated via MAP/RPM. The map sensor in that mode will just be used to altitude correct. That will be handy for all of us that start our car in Death Valley and drive to the top of Pikes Peak in one shot, whining about our mileage & smoky tailpipe. Lenny

Madkaw, This one's primary goal is 100% plug and play....and then if you want you can start fiddling with it and tune it till the cows (kaws in this case) come home. I too would like to see the dyno diff & will have a few for sure before this is over with. Realistically, I don't think there will be a huge performance gain with the stock motor. At least if your ECU and AFM are both in spec. However, if you change one of our EFIs to even a mild cam you're basically screwed in getting everything back to perfect. The MS you have or Zfuel will be able to handle all that and more. I'm working on a screen shot to upload. I'll try that in just a bit. Lenny

Leon, Thanks. Yes, I'm writing the Windows Tuning software interface as well. That interface pretty much goes hand in hand with the firmware as it makes a handy real time debug interface, and in reality the guts of firmware that will ultimately run on the embedded board, have been written up on on the windows platform as well. The two processes just communicate directly through dummy function calls as opposed to the usb link. When simulating I just have a screen that lets me set things like RPM, MAP, IAT, CLT, ect. with sliders and up/down arrows and such. For now, the communication protocol is just a derivative on one that I use all the time for numerous projects. I'll publish it in case someone wants to write their own software interface. In the future (after the basic system is done) I will add in OBD2 so ANY tuning software can at least pull a majority of the sensors and display them. I'm not sure if OBD2 specifies a format for maps ( I don't think it does - someone please correct me or point me in the right direction if you know), or if there is a default communications protocol for this. I mostly thought the OBD2 would be nice for someone if they already had a digital dash type app that they liked using (plus I wanted to play with can some more). I saw in your tag line you have 2 260's. My first z when I was 14 as a 74-260. I miss it, but not those flat top carbs. grrrr... You need to take one of your 260's and add a Zfuel to it, then tune tune tune. Lenny

Just wanted to post an update for anyone interested. I've been working on the software and it's coming along well. The GUI is to a state that I can read/write all the control structures to/from the target hardware & view pulse timing & sensor readings, the communications between the two is in place, and the embedded firmware that runs on the hardware is in place and running as well. For now, I'm using hardware that I already have from another current project & it doesn't have any of the signal processing electronics on it, so I'm just using a potentiometer to simulate the AFM and a signal generator for RPM to test *extremely* basic functionality. I'll hard code the other variables until I have the actual hardware reading real world sensors. The test system has a Freescale Kinetis K60 processor on it which is a bit of overkill for a simple ECU, but it makes an easy test platform. The next few steps are: - Hook up one of my stock LJets on the bench and start testing to get a rough transfer function of it's AFM/RPM/IAC ->pulse width. - Finish the schematic (More realistically, just call it finished as I keep wanting to add more features for later options) - Layout the pcb I have been doing a crapload of research on EFI tuning of speed-density and MAF systems. For anyone interested, here are some pretty good books that have a lot of good information: "How to Tune and Modify Engine Management Systems" by Hartman "Engine Management - Advanced Tuning" & "Designing & Tuning High Performance Fuel Injection Systems" both by Greg Banish. When I first started this project in the 90s all I had was a book on the Bosh systems and it also had some great information, but I forget the title and have since loaned/gave the book to a friend. It covered L-Jet great, but of course was very dated in it's overall engine management overview. Of the above, all are good. Both the Banish books cover basically the same thing & are a little more current than Hartman. Hartman has a little more total information & some of the explanations in Hartman are really good. In particular, Hartman has some great info on intake manifold design/tuning & how it effects VE. (Not that this helps at all with Zfuel, but it's a nice rabbit trail to follow) One thing I'm anxious to do is see how my calculated pulse widths based on MAF & the Zcars Stock engine/injectors match the pulse widths measured on both the car and the test bench. In theory they should be very close, but bear in mind, the ECMs I have to compare to are 40yrs old, likewise for the AFMs. More to come, and as always any questions or comments are welcome. Feel free to critique, hassle, praise, call BS, encourage (a lot of that would be good), or ask technical details. Lenny

Just wanted to post an update for anyone interested. I've been working on the software and it's coming along well. The GUI is to a state that I can read/write all the control structures to/from the target hardware & view pulse timing & sensor readings, the communications between the two is in place, and the embedded firmware that runs on the hardware is in place and running as well. For now, I'm using hardware that I already have from another current project & it doesn't have any of the signal processing electronics on it, so I'm just using a potentiometer to simulate the AFM and a signal generator for RPM to test *extremely* basic functionality. I'll hard code the other variables until I have the actual hardware reading real world sensors. The test system has a Freescale Kinetis K60 processor on it which is a bit of overkill for a simple ECU, but it makes an easy test platform. The next few steps are: - Hook up one of my stock LJets on the bench and start testing to get a rough transfer function of it's AFM/RPM/IAC ->pulse width. - Finish the schematic (More realistically, just call it finished as I keep wanting to add more features for later options) - Layout the pcb I have been doing a crapload of research on EFI tuning of speed-density and MAF systems. For anyone interested, here are some pretty good books that have a lot of good information: "How to Tune and Modify Engine Management Systems" by Hartman "Engine Management - Advanced Tuning" & "Designing & Tuning High Performance Fuel Injection Systems" both by Greg Banish. When I first started this project in the 90s all I had was a book on the Bosh systems and it also had some great information, but I forget the title and have since loaned/gave the book to a friend. It covered L-Jet great, but of course was very dated in it's overall engine management overview. Of the above, all are good. Both the Banish books cover basically the same thing & are a little more current than Hartman. Hartman has a little more total information & some of the explanations in Hartman are really good. In particular, Hartman has some great info on intake manifold design/tuning & how it effects VE. (Not that this helps at all with Zfuel, but it's a nice rabbit trail to follow) One thing I'm anxious to do is see how my calculated pulse widths based on MAF & the Zcars Stock engine/injectors match the pulse widths measured on both the car and the test bench. In theory they should be very close, but bear in mind, the ECMs I have to compare to are 40yrs old, likewise for the AFMs. More to come, and as always any questions or comments are welcome. Feel free to critique, hassle, praise, call BS, encourage (a lot of that would be good), or ask technical details. Lenny

Wade, I can agree with that, but I think the reason the two AFM readings are similar are because the loads are similar. I do think the raw AFM reading is proportional to load. (with a small temperature dependent caveat - see below) Consider this argument: 1) In order to maintain a steady speed, the instantaneous power generated by an engine must equal the current load required of it. 2) If the load increases & power stays same, you will slow down...(You're driving your beer trailer @ 20mph flat and level though town & 40 of your closest drinking buddies jump on the trailer. You will slow down unless you step on the gas to shake those pesky drunkards, friendly as they are) 3) Once you punch the gas & they fly off into the ditch, you now have an excess of power than your load requires and you speed up. If we agree on the above, now consider: 4) Power generated is a direct function of the mass of air flowing through the engine. All other things being equal, more air=more fuel = more power. 5) The stock AFM measures the mass of air flowing into the engine. Technically it measures volume of air & incoming air temp (IAT) & then uses (Boyles law) pv=nRt to calculate mass. ( A side note for others following along as I everyone discussing knows this) -- Our LJet ECMs don't calculate anything but just implement the final transfer function of the math via analog circuits to create a pulse width that is proportional to the mass of air entering engine.-- Regardless of how the ECM does it's task, what it does is meter FUEL mass to match AIR mass. Having said all that, now back to the original question: Is the AFM proportional to Load? I say yes. We have shown that 1) load drives power requirement. 2) power generated is a function of MASS air flow through engine 3) MASS air flow is proportional to AFM volume air flow (albeit modified with Incoming Air Temp) Therefore the position of the AFM vane & resultant signal is proportional to the load. Again with the caveat that IAT modifies it slightly. Now, don't ask me about the EGR. I blocked mine off a long time ago & haven't thought about it since. Although after this discussion, I'm now rethinking that I have placed it on my list of things to investigate. Lenny

Wade I 100% agree with Captain. 1) At 2000rpm and a light throttle position (light load), L-Jet is going to meter out X amount of fuel (small pulse width) to match the incoming air flow. 2) At 2000rpm and WOT (heavy load, going up steep hill, trailer full of beer in tow), your engine is going to flow more air, & L-Jet is going to meter out X + Y amount of fuel to match. Your statement has the phrase "just about the same amount of air". That's subjective and I'm assuming your "just about" may be a lot more than Captain & mines. I think the two conditions described will have greatly different air flows. This is assuming operating at steady state. If one is cruising at 2000rpm and then steps on it, for an instant it will still be the same, as it will take a bit for the air flow to increase, but it surely will. Lenny

Hey, why are my cornflakes all soggy? I agree Megasquirt is a perfectly acceptable solution to many. However, in my case I just like doing things from scratch & I think there are a few others that would like something similar to my concept of a Digital L Jet replacement. And while I will offer units for sale to the Z community, the primary reason for the project is because I personally want to design one. Superlen

Fast, I agree on the ignition being iffy sometimes, so I am designing the hardware to handle ignition as well, all the inputs/outputs will be there via an auxiliary non-stock connector. In fact, the hardware will be able to handle crank trigger and coil on plug if someone is crazy enough to want that (and I am. ) However, I'll wait on the software until the stock fuel program is working. You won't need any other distributer other than the stock unit. Zfuel can read the pulse from the reluctor, filter/square it up & then fire any aftermarket ignition box such as the MSD unit as well as the tach. Those inputs will be on the auxiliary connector. I will be using the existing heatsinks in the ECM & possibly another extruded piece internal. No fans are planned as they are just a point of failure. I'll do a thermal analysis & then as is usually the case, throw it out the window once a real unit is on the bench/car and some actual case temps (Transistor cases, not ZCar ecm cases) are recorded. Core exchange can be just an empty case and connector, or find a salvage unit to send in so you can keep your stock original one. I'll start building up a few in inventory as well. I have a few now as you can imagine, and I think most Z enthusiast that have been picking in bone yards probably have some stashed as well. And yes there will be a GPD (Guinea pig discount). Feedback early on will be important as I can tune the initial map to my bone stock 77 & it may work for most, but it's also likely that my bone stock 77 sensors are so old and have drifted so much that further tweaking with several other stock cars to average these out may be needed. Superlen

Captain, That connector certainly looks like it. I would have bet money that it wasn't still being produced. It's a non stock connector for them with 0 in stock. 176 is certainly the min/mult qty. (Amp probably ships them in 176 piece cases). The non stock stuff at DK is common now. Many years ago, pretty much EVERY item the DK catalog was in stock. Not so anymore, but for prototypes, they still rock. This part could still be a pain to get in smaller quantities. I have an AMP rep that calls on us, I'll sick him on finding some of these. Hopefully, he'll turn them up. The stock connector on the ECM's I've inspected have all been in great shape, so worst case, I'll just pull them from the core exchanges. Superlen