ZFuel

[superlen]

New Update:

Just finished routing the circuit board a few minutes ago. I'll turn it loose to the board house next week so I should have raw boards a week or so after that. I'll take some pics when they come in. Woot Woot!

Not much new to report on software. I did add some nice sensor calibration windows to the Gui. No one but me will probably need to use it as the ECM will already be calibrated for the stock sensors. However, if someone wants to add different sensors for custom applications, this will be the cat's meow.

For instance, if you make your own custom nifty intake manifold with a throttle body from a K24 engine or some other donor car, you can easily calibrate to the new Intake Air Temp sensor & wouldn't have to use the stock Bosh unit from your Z. The same goes for water temp sensors, throttle position sensors, ect. ect. Anything you want to throw at it, you can tune/calibrate.

Also, I will tweak this calibration screen for the Air Flow Meter. This will make it easy to bring your AFM back into spec without adjusting the internal spring. Basically you will be able to tweak the "SPRING" electronically. I think most everyone might want to play with this to get peak performance out of there engine. (or just because it's fun)

I imagine that if we took 10 cars and tested their AFMs we would get 10 different curves of voltage vs airflow. All would be close, but not SPOT on like they were calibrated at the factory. I plan to sample as many of these AFMs as possible and adjust the factory shipped calibration numbers to the middle of the road.

As always, any thoughts/comments are welcomed.

Superlen

[FastWoman]

Lenny, great news! Very exciting!

FAIW, I would kick out the "outlying" AFM data and shoot just a bit towards the rich side of the tuning. The reason is that it's better to be a bit too rich than a bit too lean. At least I have always erred just a tad towards rich. Not only is lean running hard on the engine, but a lean mixture can cause a flaky idle and possibly harmful backfiring. The consequences of rich running are fewer -- less motor oil life, harder on the cat (which most of our cars don't have), fouling of the plugs.

[Captain Obvious]

Lenny, A while ago I derived the Steinhart-Hart coefficients for the air and water temperature sensors.

Don't know if you're beyond this point already or you were even planning to use this method to determine temperatures, but here's what I got:

C = 1.89571E-07

B = 0.000257545

A = 0.001305386

These numbers are based on info from the FSM and I believe they are slightly suspect. If you find from experiment that they are off a little, let me know and I've got a different set of cooefs that were derived from info directly from Bosch instead of from Datsun.

[superlen]

Sarah,

That's exactly the plan..just a touch rich as shipped. Also don't forget power falls off much faster when you are too lean rather than rich.

Captain,

I looked at implementing the equations directly in the firmware, but went with a lookup table with linear interpolation between the points. Of course the table has to be calculated ahead of time and stored. That's where we can either measure & log real world data and/or use the equation within the GUI to make building the table easier/better. The first pass, I have just implemented the numbers out of the FSM & plan on checking/tweaking the results when hardware gets here & I can get real numbers.

Len

[Zedyone_kenobi]

I am going to print this an save it the next time somebody tells me tuning triples is in ANY way difficult.

good luck my fellow engineers and tinkerers extrodiare!

[Captain Obvious]

Lenny, are you kidding me??? All that floating point and you're gonna use a look-up table for the conversion? You don't have to be embarrassed... I'm embarrassed for you.

I'm just kidding of course. But if it were me, I wouldn't even ever convert the resistance to a temperature. The ECU doesn't really even ever need to know the "real" temperature in degree units. The only reason you need that is so you can display it on your interface. All the ECU really needs to know is how much fuel to add to base at that resistance (voltage actually) sensor input.

Lookup table... Volts in, and increment to base pulse width out. Who cares what that is in "degrees".

And BTW, there was some problem with the numbers in the FSM. I did a post about it a while ago. Let me see if I can dig that up.

On edit - Found it:

http://www.classiczcars.com/forums/fuel-injection-s30/48782-water-temp-sensor-air-temp-sensor-resistance-charts-typos-manuals.html

Edited September 27, 2013 by Captain Obvious

[Captain Obvious]

I am going to print this an save it the next time somebody tells me tuning triples is in ANY way difficult.

Haha! Honestly, I'm not sure which I'd rather tune... Off the top of my head though, I'm going with the triples.

[Captain Obvious]

And by the way, the other thing you do with the Steinhart-Hart coefficients is use them to build your look-up table. There aren't nearly enough data points in the FSM and if you try to linearly interpolate between only what's published, your error will be huge at the midpoint between your table points.

Back in the Mesozoic Era when I used to do this...

First thing you need to do is determine the amount of acceptable error. Then you calculate enough data points along the curve such that the linear interpolation between your table points never varies more than your max error budget from ideal. Works out such that the table points will be farther apart in areas where the curve is naturally more linear, but in the areas where the curve is nasty, you'll need more points.

Did I say that right?

[siteunseen]

I skipped over this thread thinking it was about the difference in 87 octane and 93.:stupid: I remembered reading this before I put the potentiometer in coolant sensor line thinking I might get myself one, Simple Digital System EM-5, I like what Lenny's doing better though. He's a Z man.

[superlen]

Captain,

Thanks for the link to the numbers post. I'll have to investigate. The reason for the lookup table was that I have a common structure/component that I use for all the sensor inputs, and the lookup table is way easier to implement across different types of sensors, temp MAF,AFM, TPS, ect. Some are simple such as TPS, it's just two points as it's a linear pot, others such as temp sensor will need more.

Yes, you said it right. And my lookup tables are configurable for both the number of points and the locations along the x axis, so you can spread them out where the curve is nice & linear and squeeze them together where its curving. I can just keep adding points until the error % is down to what is acceptable for any sensor.

Using Steinhart-Hart in the gui is a distinct possibility to help generate the tables, but my guess is that if I have tables already figured out for the stock sensors, plus a few other common temp sensors used such as GM and Ford, those tables would work for most people.

Oh also, I need actual degrees when I'm doing speed-density calculations. If I implemented only the stock LJet version, you're right I could just adjust the numbers of how much extra fuel to dump for colder air and I wouldn't need to know or care what the actual temp was.

Here's some more related info, and I'd like your feedback on it.

Note: for the following discussion we aren't considering any type of enrichments such as acceleration, or different target Air-Fuel ratios, ect. We just care about matching 1 part fuel to 14.7parts air.

The way I have the code architecture set up is that the primary fuel calculation function takes MASS of air flowing into the engine as one of the variables. I will use this function regardless of what type of air input method is on someones car. The following are three common methods to tell the ECM how much air is flowing into the engine.

M1. Hot wire Mass Air Flow (MAF)

M2. Speed-Density using Manifold Pressure, rpm, & VE table.

M3. Stock Bosh Vane type AFM

Of the three, M1 (MAF) is the easiest for the software as this sensor typically give you an output that is proportional to the MASS of air flowing into the engine. This is perfect as the temperature of the air you don't care about because the sensor is compensating for that. This method I already have written and tested in the firmware.

Now lets look at M2 (MAP) This method uses manifold pressure and a table called the Volumetric efficiency table (VE) to determine at any given RPM/MAP combo how much air is flowing into the engine in VOLUME (not mass). This is where we need the real temperature (in Kelvin no less) and use Boyles Ideal gas law pv=nRT to convert volume of air to mass of air at this temperature and pressure. Zedyone_kenobi are you following along? I may end up just buying triples as well. JK, I have this one already figured out and the code written/tested as well.

Now on to M3 (our stock AFM). This one is of course the most interest to us. It is also the one that I don't understand the physics of exactly. The vane meter output measures airflow, but is that output related mostly to volume of air or mass of air?

Consider two possibilities:

a) volume of air flowing past without ANY regard to the density of the air

volume of air flowing past but vane position changes depending on the density of the air cold/hot.

The ECU definitely samples the air temp (IAT) & corrects for cold heavy dense air vs light warm air, and I'll do the same. What I'm not 100% clear on is this. Does the AFM output *also* get affected by cold vs warm air? I think it does. Maybe not by a tremendous amount but I think cold dense air flowing at a given cfm will move the vane farther that warm light air flowing at the same cfm.

Regardless of how much (if any) the air temperature affects the vane position, my lookup tables will adjust it out. However, I would like to understand the physics behind it.

Lenny

[240260280z]

Sarah,

That's exactly the plan..just a touch rich as shipped. Also don't forget power falls off much faster when you are too lean rather than rich.

Captain,

I looked at implementing the equations directly in the firmware, but went with a lookup table with linear interpolation between the points. Of course the table has to be calculated ahead of time and stored. That's where we can either measure & log real world data and/or use the equation within the GUI to make building the table easier/better. The first pass, I have just implemented the numbers out of the FSM & plan on checking/tweaking the results when hardware gets here & I can get real numbers.

Len

I use software called curve expert for analysing data and generating formulas and tables to represent it accurately. Works nicely for "applied" theory. A geeky example at the bottom of this old page: http://atlanticz.ca/zclub/techtips/tempsensor/index.html

[superlen]

Blue,

Thanks for the link, I'll check it out.

Also, after more research and learning about specific heat ratios and formulas involving the speed of sound, I have it figured out. The final result of all of this is that for our purposes, the AFM could only vary by about 0.2% across a temp range of 0-200C! That's a pretty small number and for my purposes, I can assume the AFM to be a perfect volume measurement device INsensitive to air temperature.

The AFM's output will be *slightly* larger with colder air, but tiny tiny. The reason I kept thinking it should be affected more is because air is a compressible fluid so the density does not play a large factor in the pressure applied to the vane. For a compressible fluid, it's all about the speed. If we were trying to measure an INcompressible fluid, then the density change that occurs with temperature would be much more pronounced.

Len