ZFuel

[EuroDat]

Hi Lenny,

What you are doing certainly has WOW effect. All the option are better than what I have now, but if I had a choice I would prefer 3a with yellow highlight than "compile" or "send"

The ECU should update the flash in one go.

This is like releasing the Zed from the dark ages without giving it a complete brain transplant, by that I mean installing a Megasquirt system. Great work your doing.

Chas

[superlen]

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.

[Captain Obvious]

Ha! Classic batch style user interface questions. Before I get into any thoughts about them, let me make sure of one other thing first:

Make sure you have a bullet proof, iron-clad, robust, absolutely all situation covering way of recovering from a half-completed config download or flash burn. You're always at the risk of interrupted communications halfway through a configuration download and you want to make sure you don't end up with a half-lobotomized patient that's stone dead because if can't make heads or tails out of the configuration data.

Someone trips over and yanks out the USB cable.

Someone shuts the car off at just the wrong moment.

Someone disconnects the battery at just the wrong moment.

Someone gets a "You've got mail" at just the wrong moment.

As a last resort, an NMI driven H/W "RESET" button on the ECU itself that restores some sort of factory default config?

As for the question at hand... I'm sure you remember in the olden days, the classic reason for not burning to flash every time was that they had a limited number of burn cycles. If you've got the cycles to burn (pun intended), then I'm thinking burning every parameter when you hit "ENTER" is the way to go. That way, it would be easier to tell if you screwed something up.

Of course, the drawback of that would be (other than the number of flash burns) is that if you're changing multiple parameters at the same time that are related in some way, you could wish to dump them all at the same time.

I'm thinking that offering an option to work on a config either "online" or "offline", with the default being on?

At the end of the day, my real answer would be "Doesn't really matter. It's going to work so well and be so kick-arse right out of the box that you shouldn't have to be messing with it that much."

[superlen]

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.

Of course, the drawback of that would be (other than the number of flash burns) is that if you're changing multiple parameters at the same time that are related in some way, you could wish to dump them all at the same time.

- 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

[superlen]

Here's another status update for anyone following.

Today was a small milestone as I connected a full EFI harness to the HellFire. For a few weeks now, I've been playing with the software and sensor calibration routines. The stimulus to the board has always been my breakout/simulator board. Additionally, I wasn't running +12V power. The usb connection was providing +5V that powered all the circuitry. I did this just for ease of development (no need for lab supply on desk, no extra pesky wires in the way, ect).

This morning, I connected a stock harness ( I think from a '75) & powered up. All sensor inputs worked flawless!!!! WOOT WOOT.

The IAT, CLT, TPS (idle & WOT switches of course), cranking signal, Battery voltage & AFM output were all showing on screen as they should.

I have an AFM lying on my desk with the cover off. I can move the vane from 0 to full scale and watch my sensor input go smoothly from 0 - 100%. Changing the scaling works great and I can scale it to give me raw A/d Counts, or the voltage at the ecu pin, % full scale, or cc/sec of air flowing through it. I still need to calibrate to determine the cc/sec of air. This is of course the critical measurement we need but for now it's set to just show voltage.

The IAT was showing 28.9 deg C which is a little high for my office but I am running a space heater below my desk keeping my feet warm. More likely I thought was that my calibration numbers that I calculated based upon the FSM are a little off. They are definitely coarse as I'm only using 5 data points and I need more. Both Captain and Blue have volunteered to calculate some better numbers & I'm ready to take them up on it and buy some beer. For grins I took the AFM and set it down in front of the space heater & immediately the IAT on the computer screen started rising.

The on board MAP sensor is tested and working great as well. I have also ordered a MAF sensor off a Infinity q45 to test as well. I already know the transfer function of it in grams of air/sec, so I'm going to plumb it in front of my stock AFM while the car is running and use it to get a baseline calibration curve on the stock AFM flowrate vs output voltage.

The next thing is to test the circuitry that detects the coil firing and test the injector drivers.

So far knock on wood, No smoke from the prototype board, and not even any blue wire jumpers needed.

Lenny

[FastWoman]

Very impressive! So will I have it in my Xmas stocking on the morning of the 25th? Hmmmm????

That's a nice method you have of cross-referencing the AFM output to actual airflow. Dumb question: Have you confirmed the spring calibration is correct on your AFM?

I think I'm going to pop a champagne cork when you have your Hellfire board running your Z! The anticipation is too much!

[240260280z]

I'll do what I can Lenny. I have a lot of spare EFI parts and a 77 280z at your disposal.

I can also transform curves to equations for compactness in code and smooth transitioning.

[superlen]

Sarah,

I was hoping to have at least a steady state baseline map running (read Idling with at least a halfway close 14.7 AFR) in the Z by New Years. It's still a possibility, but with some Christmas travel and such, i don't think I'll make it.

And, I'm still laughing at even the thought that I would have a calibrated AFM. :) As you probably guessed,like most all of us, I have an old worn out AFM that who knows how much it has drifted/spring weakened or how much the spring has been tinkered with.

I have several thoughts on this:

1. My assumption is that most don't have a clue where their AFM is really at.

2. My GUI can easily adapt to any slight (or even fairly major) drift as long as the internal wiper is smooth and doesn't have dead spots. However, tweaking a bunch of numbers that aren't even close to linear by hand doesn't sound fun or productive at all.

3. In the GUI, I'll have a virtual "wheel" that the user can advance or decrease. This will simulate popping the cover & manually changing the spring rate. It will adjust the numbers on the fly for you. The benefit is that a) it's easier You don't have to worry about risking the integrity of the seal on your cover & use gobs of silicone to make sure it's water tight when done. c) you can easily go back to stock by clicking a button as opposed to remembering where your wheel started at. d) It's far easier to click a button while the car is idling, than to loosen the bolt adjust, retighten, ect. (usually with the car off) I feel this virtual feature will allow the user to "tune" their particular AFM's drive in pretty good. Experimentation will tell. I can't wait to get to that point.

4. How do we know if our AFM has dead spots? Testing with a voltmeter is a great start, but somewhat time consuming, and I never know if indeed there was a tiny dead spot I just missed. Plus, what if the dead spots only show up during vibration. People who have investigated their AFM internals know that the wiper is just held in place by the pressure of the arm. What if your wiper is just barely touching and sometimes you get a hiccup? Wouldn't it be nice to know the overall AFM Wiper health? I have a great solution. Anytime the HellFire is running, it will be building a histogram of all the data points it sees on the AFM input. The GUI can show a bar graph of where the AFM mostly hangs out at. Obviously down at the rest position & idle there will be much greater activity & then one should see a somewhat smooth bell curve. The key is that if you see one spot in the middle of that smooth bell curve that is down in the weeds. Voila! That's a point where the wiper has a dead spot!

5. Ok, all the cool stuff aside, we still have the problem of whats the calibration supposed to be? What is the standard? Two possibilities: a) calculate/measure what a factory tuned brand new AFM is & use that as the gold standard. Measure as many unmolested 40yr old AFMs as possible to calculate what the normal drift is for these things and use that as the standard. For now, I'm leaning towards a. (with a caveat). The base calibration should be as close to possible as a factory new AFM. However, I would like to ship the HellFire Classic configured with the golden calibration, but with the virtual wheel set to what is most likely the best setting for a tired old AFM. In reality that may just not work perfect, & some tweaking of the wheel may be necessary for the absolute *best* setting. However, one thing for sure is that it will work better than the stock ECU hands down.

Blue,

Thanks, I'll try and post later today my input circuit & a picture of the calibration screen for the IAT/CLT. Here are some quick details. I have a 6.2K pullup to 5V, the sensor is of course the other resistor to form the voltage divider. The 12bit A/D maxes out at 3.3V. (0- 4096 counts = 0-3.3V input)

Lenny

[Captain Obvious]

Great progress!

As for the temp sensors... The data points in the FSM for the temp sensors are wrong.

Use these instead:

Steinhart-Hart coefficients for the temp sensor RTD's. Same ones for both the IAT and WTS.

C = 1.89571E-07

B = 0.000257545

A = 0.001305386

Graph it in Excel and you can pick off as many points as you need... You want me to send you my file?

[FastWoman]

Hi Lennyclaus

I think it's true we have very little idea what the true tension should be on the clock spring. Someone had to wind up the things and calibrate them on the assembly line back in the late 70's. I wonder whether the calibration specs/procedures could be obtained from Nissan. Hmmmm... I wonder whether Mr. K could be the conduit for this information?

Absent any useful info from Nissan, here's my take on the AFM, and this comes down to speculation and opinion. (I think Blue and I might disagree somewhat on some of the details.) Firstly, Blue (John) measured a couple of AFMs that he believed were unmolested and came up with a spring calibration procedure here: http://atlanticz.ca/zclub/techtips/afm/calibration/index.html. We can only guess what has happened to these springs over time. They are surely weakened, but by how much? And are they simply deformed, or has their spring constant changed? I'm sure it's a some combination.

However, assuming this calibration is correct, it could become the closest thing we have to a gold standard, unless someone somewhere has a better AFM, perhaps a NOS unit, from which we could take measurements. I'm not confident that a refurb AFM is really calibrated any better, using any more "correct" standards, than what could be done with the AltlanticZ method.

And you may say none of this matters, but this is where I disagree somewhat, and I think this is where John and I disagree. During high'ish RPM (maybe 4500'ish?), WOT operation, the AFM will supposedly open fully ("pegging out"). Perhaps there is some enrichment function as RPMs continue to increase. I haven't found any useful info as to how this might happen, and I think this is where we get into mysterious territory. Perhaps John knows something I don't.

Anyway, it seems to me that the AFM will peg out at an "incorrect" airflow rate with the wrong spring tension. For instance, if a system is enriched by loosening the clock spring, the AFM will peg out prematurely, possibly resulting in a lean mixture at high RPMs. So I think it's important to have the right spring tension.

My thesis has always been that the ECUs, being analog devices operating under severe thermal conditions, have drifted over the decades, apparently towards shorter injector pulse widths. The correct compensation for the leaner condition is then to widen the pulse width at the ECU, and the best way to do that is by adding resistance to the CTS circuit. I disagree with the approach of loosening the clock spring, not only because of the AFM pegging out too soon, but also because the clock spring, if anything, is probably ALREADY looser because of the ravages of time and use.

Anyway, my suggestion is to adopt some sort of gold standard for clock spring calibration. John's is probably the best we have. For the Hellfire to work properly out of the box with an OEM configuration, I think it is essential for the user to ensure at the very least that the fuel pressure is right, the CTS resistance is right, the AFM's potentiometer is functioning to spec, and the AFM's clock spring is calibrated to John's spec. As you say, these AFMs are all over the place now, mostly because of ham fisted adjustments by previous owners and/or their mechanics.

Anyway, that's my 2c.

Edited December 22, 2013 by FastWoman

[240260280z]

I'll make a flow bench and map AFM flap movement to CFM/Flow.

The volumetric efficiency and engine size can easily be used to map CFM against RPM and CFM against HP.

btw John is baddog, philip is blue.

[Zed Head]

Seems like it might be easiest, though not as fun, to just install it, drive it, watch the AFR's, and use the GUI "wheel" to change the slope and the base pulse width to set the "y". Just sayin', the time spent on figuring out stock AFM flow-voltage curves might be moot. That's the point of adjustability, right? So we can tune to our set of old used parts.

The AFM's are also complicated by the shape of the air passage. It's not a vane in a straight tube, it's a vane in a contoured passage. Nissan must have spent a lot of trial and error time getting things just right.