btw having the engine set up for two fuel modes: Economy and Power (with an optional USB switch would be a nice feature).

One target would be 12.5 and another would be 15 to 16

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

Yes, I think the economy override is a feature that should be on all programmable EFI systems. Making use of the speed flexibility of software reconfiguration is what software programmers seem to lack these days.

For example why the hell can't Microsoft just make a kernel and maintain the GUI's as a separate modules so that when you buy windows 8 you can choose the GUI you are comfortable with and quick with? Seems like the power of software has been abandoned.

Your hardware with the ability to flip between a few maps would be great and fairly unique however it should have been standard for years.

I would do tables like this:

1. lean cruise with rich power (hybrid1 12.5 and 16.5)

2. shoich cruise with rich power (hybrid2 12.5 and 14.7)

3. rich all around (power1 with target ~ 12.5)

4 rich all around (power2 with target ~ 13.5)

5. Stoich (target ~ 14.7)

6. lean all around (distance1 with target ~15.5)

7. lean all around (distance2 with target ~ 16.5)

Edited December 3, 201311 yr by Blue

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.

That was my thought as well, but I didn't have the time to investigate. I didn't want to just go raising the amplitude without investigation first. I didn't want to pop anything.

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

In the beginning, they actually used a thin wafer of silicon, like a potato chip, but thinner.

Exciting stuff here for the Z community!! Don't understand half the poop you are talking about, but it sounds impressive. I should know more since I am in the middle of a MS3x install-

With this Hell-Fire set-up and a day at the dyno, Z owners might get a new respect for their car.

All I can do is to cheer Lenny on at this point. Lacking anything more intelligent to say...

Go, Lenny, go! Go, Lenny, go!

I second that FastWomen! Go Lenny! Wish there was something more I could do besides cheer Lenny on.

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

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

I think first getting a dump from the ECU and comparing to a back up in the GUI application should be done before most new loads.

Keep these as ECU restore states for backing out....keep the last 10 to 20 and date/time stamp them automatically.

Having an "Are you sure?" is a good thing but make an option where it can be disabled. (this will help with fast changes for comparisons)... no one wants to wait for a computer in a car.