superlen

Twas the night before Christmas and all through the shop, not an injector was firing, not even a pop! The harness was strung on the engine with care, with hopes that a HellFire would soon be there...... (I hear ya' & more to come)

Capt, Are you sure we're not related? You really have great ideas!!! FYI, I have a fail safe for the download. Here's how it works. I actually keep multiple "tunes" stored in the flash: Tune F: Factory default (can't ever be changed by user - ever ever. Period.) Tune L: Last known successful Tune downloaded. Tune 1: User Tune #1 (This is where you normally download to) Tune 2: User Tune #2 (This is if you want multiple tunes stored for testing on the road A/B comparisons quickly) Tune X: User Tune #X (I can have as many as we want, but 2,3,4...yada yada is even overkill I think) When the user downloads a tune, it goes to User Tune 1,2,3,x & assuming that the complete Tune download is successful, HellFire runs with this. If your dog happens to chase a squirrel though the shop & exits with the usb cable attached screwing up your download, I'll blow away your screwy download with the last known download. I'm waffling on a hard switch to revert back to a factory default....I would really like to mandate that the user use the GUI to perform this, but I do like having the backup of another method. I have spare GPIO inputs that I could use for this. The Flash has 100k cycles on each location so we can Tune, tune, tune...till the cows come home. Plus I have a bit of wear leveling code that will take place as well. - Yes... This was my thinking too & I considered having the user be able to toggle between instant update/batch. I'm really just leaning towards always being in instant so it's just like you're inside the ECU tweaking with a screwdriver. Instant feedback. Then, if you need to change several things at once, just turn off the engine, make them all then restart.One could also just download the new tune to User Tune 2 (while the car is running UTune#1) & when happy, just flip the switch. Blue touched on this earlier as he wanted it to be fast/easy to make a change while testing. I think to do A/B comparisons. (Blue, correct me if I assumed wrongly). There's also a method to completely burn in a new version of firmware via the gui, so we are field upgradeable. The bootloader is located in a protected bootblock of flash so it can never be erased. The only way to brick the ecu is to have an actual hardware problem. The user can try to download "War & Peace" if they like, it won't brick it. Len

I found this thread while doing some research on the HellFire ECU replacement design. I know this is an old thread, but I just wanted to clear up some misinformation. The basics are below. More wiring details are buried in this thread. (http://www.classiczcars.com/forums/fuel-injection-s30/49964-zfuel.html) ALL ECUs from 75-77 will work in any car from 75-77 regardless of how many pins the ECU has. In fact many of these pins are not even connected internal to the ECU, they just happen to be on the connector. The confusion comes from the fact that if you look at the schematics, you will see wiring such as the wire from the fuel pump relay to pin20 present which makes one think there is a difference. However, once again in NONE of the ECUs (even the ones with all the pins) are these terminals connected internal to the ECU. For 1978 things changed a little on the fuel pump relay/AFM contacts, but I'm not 100% on the ECU exchange at this point so I don't want to comment either way for now. When I have that information accurate, I'll post back here. For 1979-up, the ECUs are NOT a drop in for the early FI Zs. I'm also not up to speed on these yet either. Lenny

Blue, Good idea on the last 10-20-30 (however many) burned. I can do that automatically hidden from the user no problem. Every time they burn a copy to the Hellfire I can store a local copy on the hard drive time stamped. And Yes there will be an "are you sure" popup of some sort. I hadn't thought about letting the user turn on/off that feature. I have it OFF now just because I don't want to click the button 50 zillion times while testing the communication. Chas, Thanks for the feedback and kudos. Releasing the Zed from the dark ages is indeed what I was going for. Plus blinking leds and realtime GUI screens showing your engine status are just plain COOl.

Inquiring minds update. - Nothing...at least not much. I've been trying to catch up from the snow storm. I did clean up the GUI a bit & I received in some new 2.5 bar MAP sensors to test. Also I modified the communication protocol to save some size while transferring data to/from the ECU. My goal is to transfer ALL setup data up to the computer within 2sec after plugging in. You jack in & "poof" all the data is now fresh live and realtime! I have also confirmed that I can successfully do the following for all the Sensors Setup Information: - load/save the setup from a file on the computer hard drive - read/write that setup to/from the HellFire ECU's local ram. - load/save the ECUs ram copy to the onboard Flash (make it sticky so it stays there after power cycle) - Reset the Sensor information in the ECU Flash to Factory Defaults. The next step is to duplicate all of this for the other setup information like general purpose Fuel Injection setup, MAP tables, Target Lambda tables, ect. ect. Some of this is already done, but I need to test thoroughly before moving on. I do have a question to throw out for feedback. It pertains to how the GUI should handle sending changes to the Hellfire. Consider the following: 1. - For no reason you decide to hookup the laptop to the HellFire to play with it. (Obviously, it's running your car better than it ever has before and ever will. ) But still you can't resist the urge to "tweak" something, or show off to you're friends your new toy. 2. You jack in. "Poof" you have all this cool data in front of you & you decide to change the target AFR (Air to Fuel Ratio - normally around 14.7) to slightly more rich when warming up in the mornings. You change it from 13 to 12.5. 3. Now you have just changed it in the GUI (but only the GUI at this stage, it hasn't been sent down yet). Which would you rather have happen right after you hit "Enter" upon changing the data. a) Alert you that you just changed the GUI and highlight the change in yellow as it now does NOT match what is in the ECU. The assumption is you may change several things, look at them, decide that indeed is what you want and then hit a big button labeled something like "Download your changes to the Kick-arse HellFire ECU". or... As soon as you change something, automatically send that data to the ECU's ram (thus keeping the ECU and the GUI always in sync). To be clear, each time you change something it would be sent down and take effect immediately on the ECU. You can download all the parameters while the ECU is running so you would get instant feedback without have to also click an additional button to update. However, if you want to make several changes at the same time (while the car is running) this method wouldn't allow that. And then once the data is received by the ECU I have two options as well. a) Just store the copy in RAM and let the engine run with the new paramaters until you are happy and want them to be saved to flash (make 'em sticky). If you don't also tell the ECU to save by clicking the "SAVE to FLASH" button, the changes you just made will be lost on a power cycle. Every time you send something to the ECU, just go ahead and write it to Flash. I tend to think this one is better as I can't think of a good reason to NOT do this. The only reason is if you want to test some changes and after playing with them you want to revert what you had before easily (cycling power). You should always save your tune to a backup file on the pc & thus could always get back to a tune you liked by just loading it from the hard drive and sending it down. Thanks in advance for any feedback. Len

+1 on what others have said. With the FSM/EFI Bible & a simple voltmeter you will be able to check all the engine harness/external sensors. Even if you aren't super mechanical you can do this. You may have to ask some questions on here (don't be afraid to ask simple questions. We are great with those. ) to get it figured out, but this forum has some very helpful peeps. Absolute worse case, you learn more about your car and have a better idea of where to steer your mechanic should you decide to have him or someone else look at it. Len

Thanks for the cheers everyone. I'm still making progress. I've mostly been playing in the snow with the kids, but have done some work on low-level boring stuff to get all my sensors reading/scaling properly. Nothing new to really show yet that's exciting, but maybe later this evening I can post some more fun stuff. MadKaw, Let me know if you have any issues getting your MS up and going. I don't really know anything about MS specific details as I've never installed one, but I'm fresh up to speed as you can imagine on general Fuel Injection settings/tuning. Helping you (if you in fact need some, which you probably don't but still it's fun to discuss) would help me I'm sure. superlen

robox, Glad you're back on the road to get everything tuned in. I just now noticed the thread & couldn't offer any more help than the others (particularly since I'm more of an EFI guy), but just wanted to say hi. My wife and I were in Taos in May for the first time & loved it. Other than a bit of altitude sickness from staying at TSV (probably would have been better to have slept at a little lower altitude), we had a great time & will be returning again this Spring sometime to explore some more & find that stinkin' treasure Lenny

Inquiring Minds Update - Still making steady progress on board bring up. - Have basic Analog Sensor reading all functional & values being passed along to the GUI for realtime viewing. I'm just passing raw a/d counts for now. - I have to add in some more read/write commands to the communication code in order to send down the sensor calibration structures & then...I should be able to see realtime calibrated values in the GUI. TPS goes to 33%, GUI shows 33%. Coolant sensor reads 88degs, Gui reads 88deg. Yay! Of course, there is tons more to do, but we have 1/2" of ice and 6" of snow on top of it. I've got some free time. Lenny

JR, You may be at the point it's time to swap out with a known good ECU and make sure it didn't get tweaked a little too much with whatever crazy wiring combinations it had before it reached your shop. If you don't have one available, pm me. I have a few and can ship you one to test with. I just need it or your old one back after you test. Also the resistance check will confirm the wiring connection from the sensor to the ecu. The pigtails up there are a problem area & this test will confirm that they are either good/bad. Lenny

Sarah, That truck was HellFire prototype 1. JK. That was my friends Dodge 1 ton. It was a really sweet truck. It sprung a diesel leak onto the exhaust manifold. The sad thing was that he was hauling a skyjack out to my house to help with a pool install when it caught fire. Blue, I have a AFR table that is adjustable (similar to a VE table). It's normally programmed for Economy (14+) when you're driving around in the "cruise" portion, but when you "tip in", or punch it to pass, or under any conditions where you want power, it will drop down into (12ish) AFRs. It might still be nice to have a remote switch override to force economy as with my driving I'm usually flooring it & would always be in the cells that are set to power. The tables are completely adjustable so if one wanted a fixed 14.7 or 12AFR or whatever, they could do so. Len

Chas, Thanks for the compliment. Blue, I may take you up on that a little later on. I remember us discussing the curve fit software you have & it was pretty cool. While I'm not implementing equations in the realtime code, it would be useful in calibrating different non-stock sensors. Len

+1 again on what Zed said about coolant sensor. The cold start valve could also be a contributing factor, but I think you're on the right track with the coolant sensor wiring. You can take the cold start valve out of the equation by pinching off the fuel line going to it with a pair of small vice grips. Then if you are still running way rich you will know its just the ecu. Oh, and there is ZERO diagnostic feedback from the ECU. It's only function is reading inputs & firing injectors. There is no way to read sensors & not even an idiot light to look at. That's another reason I wanted to do the HellFire project. Len

+1 on what Zed said. This is definitely a special case. And JR...eeks on guessing 50/50. Had you been wrong you would have reverse biased the ECU. I'm not sure if that will kill it or not, but its not a great idea. I'll have to try with one I have lying around. I hope at least it was an educated guess. Zed. One thing that I have noticed on all of the FI harness' that I have looked at is that this ground wire is not connected to the frame anywhere. It is only connected to the battery (-). In the FSM it shows a star ground where all the wires connect, but I think that is just referring to the splice in the harness not an actual physical star ground to the frame. I think Bosch was trying to isolate this circuit from everything else in the car. The ECU case gets grounded to the frame when it's bolted in, but the case isn't connected to the gnd on the circuit boards inside. The schematic I'm referring to is the one in the '77 FSM & the Z EFI theory/troubleshooting.. I haven't checked others, they may show it as a star gnd to frame. And the one in the FSM could certainly be interpreted as a frame grounding point. I've just never seen the frame gnd in the wild. Len

Here are some latest GUI pics. I do want to stress that most people are NEVER going to have to see any of this. Just plug the HellFire in place of your stock ECU and party on. But for those who want to modify, tweak, play, or twiddle, the GUI is going to be nifty. Also note in these pics you might see random buttons and hacks that I have in there for testing. Ignore anything that looks silly. Here is the main configuration screen for the overall system showing how to set which method of Air measurement you like. You can also see some of the other settings such as fuel pump prime seconds. Here is the screen showing the Sensor list. Each sensor has its own calibration data (shown later) that can be tweaked to accommodate any analog sensor you throw at it. The unit will ship with calibration for the stock sensor obviously, but if you find yourself wanting to use a coolant sensor from a Ford Escort or a Yugo, you can. I will however, make fun of anyone who puts a Yugo part on a Z car. And finally, here is a shot of the calibration screen showing the coolant sensor. By adjusting the numbers in the table at the left one can tweak around the curve that fits your sensor. The graph is mostly just for visualization to give some feedback that you aren't typing in something stupid in the table. The graph for most all sensors should be a fairly smooth curve. The number of data points to fit the curve is limited to 16. You can use as little as 2 points or a max of 16. The ECU then does a piecewise linear interpolation between the closest two input points when calculating the output. As always, feed back is appreciated. Len

Captain, Thanks for posting the pics in the thread. For the life of me I couldn't get the tags to work properly. On your test setup I'm guessing it was your ignition pulses weren't high enough voltage. I have the same problem firing the stock ECU on the bench. The ECU is set up to work from the flyback on the coil & there is a threshold (I don't know what it is yet - maybe 30-40V???) that has to be met. Neither of our signal generators were hitting this mark. I hadn't thought about that when I made the breakout board or I would have put some sort of HV pulser on there. Lenny

Zed, Yes, I'm a hardware/firmware design engineer & I've been writing windows code for almost 10 years. I posted a screen shot early on in this thread. The gui has changed a lot of course, but this gives a general idea. Look back up to post #25 for details on it. I'll try to include the picture here as well. screenshot1 | Flickr - Photo Sharing! Apparently with all my mad ECU design/software skills I've been touting I can't make this picture show up in this forum.. Just the link. Lenny

Captain, Yes, my plan is to first simulate just as you outlined. However, I'm cheating. I also layed out a breakout interface pcb at the same time as the HellFire (I should post pics of it too) This board connects to the engine harness and has two pigtails that come out of it. One for the stock ECU , one for the HellFire. In theory I will be able to hot swap between the two ECUS while the engine is running as both see the same input signals. I buffered the inputs to the stock ECU and routed a path to the HellFire so it sees what the Stock ECU sees. There's a bit of head scratching I'll need to do to make sure the sensor scaling matches. The outputs are switched via relays and one toggle to run the engine from either ECU depending on the toggle switch position. There's also pots and switches on the board to simulate the engine sensor so I can just use it and the HellFire on the bench. I stopped short of adding a timer on it to simulate RPM. I'll just use a function generator. Lenny

JCB, I haven't determined the selling price yet. I can already tell it is going to be more than I originally hoped for, but it won't be astronomical or out of line with any other similar system. (except for rcb who said price is not an issue for him. His will be wicked expensive! ) I do have the models & respective capabilities defined. There will be two models available: the HellFire Classic & HellFire Hybrid. Both models will be 100% configurable via the GUI for all fuel delivery maps & can support any intake manifold, throttle body, head, piston/cam upgrade ect. Both will also allow you to run any stock or after market sensors such as (stock vane style AFM, MAP, MAF, analog TPS, non-stock temp sensors, ect.) Both can control the fuel pump to give you a configurable # of sec prime pulse when ignition is turned on. Yay! no more hot start problems. Both will support a bone stock engine compartment or a highly customized one with AFM missing, custom intake, big bore Throttle Body, ect. The major difference between the two is that the Hybrid will be able to take over ignition duties & will have additional IO necessary for things like crank position sensors, turbo capability, shift lights, & similar. For 90% of us the HellFire Classic will fit the bill. However, if you are crazy and want to go all out with a crank trigger wheel, full on ignition control, coil on plug, & sequential injection you'll want the HellFire Hybrid. Tomohawk, Once I get the prototype operating a car & have something tangible to show, I'll contact a few of the Z channels to get more feedback. For now, the push is to continue development and testing. Inquiring Minds Update - I haven't had much time to work on it over the holiday, but I have the serial communication protocol fully implemented. I can now easily transfer command & data to/from the ECU. Data is transmitted with packets using a 32bit CRC so we have 100% reliable data. This is more of a pain than just simple ascii commands with carriage returns but in my opinion is mandatory for something that is controlling your fuel & ignition. One wrong bit when downloading a fuel map using simple ascii and you could seriously lean out an engine. I know it's a remote possiblity, but why worry. The communication protocol I used is a derivative of a custom one that I wrote about 7 years ago & is currently being used in well over 50,000 units in the field. It's on an industrial controller in an extremely noisy environment. It's time tested, and we will have no problems. The GUI now autodetects the ECU as soon as it plugged in to any USB port, and then both the GUI/ECU maintain the connection & keep the user informed of the status. The GUI has a connected ICON & shows details at the bottom of the screen in the status bar. The ECU has an led dedicated to the communication link. I want the connection to be seamless & simple for the user. I'm chomping at the bit to get this thing connected to the Z and some real world sensors, but I'm being patient. The GUI will be the primary debug tool for me as I bring the system up so I'm spending a lot of time making it solid and useful. Most users will probably never ever see it, but the ones that do connect their laptop I want to blow away by how simple it is to use. This is not an easy task as there is a lot of capabilities to the system. Lenny

JR, Glad you're on the right track now. I don't think you harmed the ECU. It's possible, but it was wired with +12V on both the supply and ground on the ECU, it wasn't reversed so I think it will be fine. No other parts on that gnd circuit would be damaged by the miswiring. Just check for injector pulses. If you are getting any at all the ECU should be good enough shape to get you started. Lenny

JR, Something definitely not right here. P72 should be connected to GND already in the harness. If you are seeing +12V there, we have an issue already. P72 is the ground side of both coils in the relay. This would also explain why (12V to p36=no pump.) as the coil gets +12V from you on p36 via jumper wire, but the other side of the coil isn't grounded. The following tests would be of no use until we figure out why P72 is showing power. This same ground is the ground for the ECU as well, so that might also explain why the ECU is not firing injectors. One thing I might bring up is that Datsun did some crazy color schemes on the FI harness power supply. Such as the ground wire (The same one I'm talking about) where it connects to the battery is a large 8awg or so "RED" wire. Sometimes its Black, but I have seen them RED. Where it connects to the battery is just a big spade connector (stock) but might have been changed over the years, but someone could have mistook it for a power connection and have it connected to +12V instead of gnd. It runs right up to the battery & looks like it should be tied to +12V because its' red. To find out, pull the connector off the ECU and measure the voltage at pin 35. It should be GND. Actually pins 35,17,16 & 5 at the ECU connector are all tied directly to GND. If one of these is gnd all should be. Lenny

Captain, Love the tantalum line...it was beginning to stink. And yes..the planer is a 1920's Porter 24" thickness planer. 5hp 3ph on the cutterhead. I just finished restoring it & have been using to plane a bunch of quartersawn white oak for trim in the house. I should have been doing that today as the weather was nice, but some deer hunting and Hellfire bringup took precedence. Sarah, I love the vaccum tube idea. That would be quite cool. One thing I just realized on the LJETS is that some of the later models actually have dip part ICs in them instead of the old style can ICs. I didn't run the numbers, but I'm sure they are opamps or maybe some comparators for the multistable vibrator circuit. I have too much on my plate now, but I would still like to reverse engineer the analog details of an l-jet. Hellfire Update: 1. Status leds are blinking. 2. Communication is tested & I'm reading to/from unit via the USB. The classic "Hello World" or in this case, "Hello Z World", came across the link first pass. 3. Beginning on testing the rest of the basic I/O functionality and integrating my existing communications framework for the GUI. Lenny

Happy Thanksgiving to all my fellow Z Heads. ....oh and another update for those playing along at home. The HellFire digital ECU Board is populated & powered up!! (No smoke yet Captain, but it's still early! - and to be honest there was a bit of a close call on a tantalum cap loaded backwards on the 3.3V supply input on first power up. ) I was running off current a limited power supply for initial power up as a precaution so there wasn't enough "ooomph" to smoke it. Had I connected directly to a full 12V battery.....well it would have been a little exciting when the power came on. Virgin power up.. Pop! & parts fly off the board. That's not how to start a project. :laugh: Thankfully, that didn't happen. Once I swapped out the cap for a new one (& not soldered on backwards), the board came right up. The laptop detected the onboard USB interface, installed drivers appropriately & the JTAG programmer connected & allowed me to download code. Woot! Woot! I now have a development platform!! :classic: Here's a populated pic: And here is a picture of the target car & the test harness/bench. Hmmm. Picture looks like it cuts off top half. Try here: ImageShack - test harness.jpg I have limited time over the holiday but hope to have serial communications up and going between the HellFire and the Windows GUI & begin testing all the analog inputs. Len

JR. FYI, you can stop worrying about pin 20 going to the ECU. It's not even connected inside the ECU. My thoughts on why are that Bosch engineers were planning ahead to control the FP relay at some point via the ECU, but for your year model, they didn't. If you look at the ECU connector (Not the harness, the ECU itself), most likely there won't even be a pin installed in location 20. (Some do, but most of the 75-77 ecus I have taken apart don't have pins there). And, even if the pin is there, it's not connected to the circuit board inside. The ONLY ground you need to worry about on the relay is pin 72 on it. Both internal coils ground through this connector. If you have good gnd there, the relay will be satisfied. Here's the path for the fuel pump to turn on via the flap. 1. Bat + at pin 70. (all the time regardless of key pos) 2. You turn key to ON. This first one coil inside the relay block and connects p70 to P43 (dropping resistors), & P39(one side of AFM switch) P43 and P39 are connected inside the relay. 3. Now move the AFM vane. This runs the +12v back to the relay onto to Pin36 which fires the second coil in the FP relay. That relay will then close and connect P73(+12 via fusible link) to P74(the pump). If I were troubleshooting I would do these in order. 1. GND pin 72, hot wire +12V to pin 36. (This should FIRE fuel pump by connecting p73 & p74) 2. If that works, then your problem is with the signal getting to Pin36 by way of the AFM switch. 3. If that doesn't work, then you either don't have +12v reaching pin 73 via the fusible link or the relay it'self isn't passing the signal to p74 or the wire from p74 to the FPump is open, or the pump doesn't have ground. Another way is to work backwards with a +12V jumper wire. 1. With the key OFF. 2. Jumper +12V to P74 (pump should run - as P74 is the actual wire going to + side of pump) 3. Jumper +12V to P36 (pump should run ) - tests one of internal coil/contacts of relay 4. Jumper +12V to P39 & Move AFM flap off idle (pump should run) - tests AFM contacts 5. Now turn key ON & Move AFM flap off idle (pump should run) - tests the second internal coil/contact. I'll be heavily involved in fuel pump relay wiring & general purpose ECU testing Friday. If you are working on it then, PM me and I can give you contact info to call me. With a diagram in front of you and some quick conversation I bet we can figure it out. The Z's relay scheme isn't quite straightforward, but once you wrap your head around it, it makes sense. Happy Turkey Day! Lenny

Cap, I'll populate it myself....well when I say myself, I'll have one of my SMT employees do it for me. For just the one board, it will be placed by hand, but otherwise goes through the same process as production boards. It's screen printed with solder past, part's placed, then ran through the reflow oven. This is much faster than hand soldering every component (however, not as fast as the 13,000 part/hr pick&place) & as a bonus you get a nicely soldered board with a process controlled temperature curve. At least it will look good to start with . After I get through debugging/modifying/destructive testing it'll look like hell. Oh, and check your email. - General Update for anyone interested. - I had purchasing order all the parts that I didn't already have in inventory & I'm hoping to get a prototype built next week by Thanksgiving. Lenny