nAst1: Progress and Concepts Thread

[SappySE107]

I was wondering why my idle kpa was in the mid 40s, when every stock 3.1 I had seen was in the mid 30s. Freescan shows 37, Tunerpro shows 43-44. I am tuning based on tunerpro, and it seems 60+ is all damn near the same if not exact so i don't know what to make of it.

[pocket-rocket]

I took the 92 out on a small trip on "deserted private roads" today. I raise the rev limiter to a more normal level. The car still drives nice, but with less power, which is expected since it hasn't been tuned yet and is basically on a stock tune. It drove and idled fine, although at light cruise there was a slight jitter. I wasn't watching my laptop, but I assume it was the double fire and single fire switching over. Other than that, it ran fine, no DTCs set, nothing out of the ordinary that my novice eyes could pick up. It ran fine up to 7k without a hiccup. I would upload a copy of the ~10 minute run, but it's on my laptop out in the garage at the moment.

I don't mind being a guinea pig, after all, I was Ben's guinea pig for both of his DOHC chips, lol.

[SappySE107]

nast1 1.04 BP.adx

And I had to add the adx file extension so we can upload them anyway

[robertisaar]

when you go into the Acquisition -> Edit section, there is the option to save changes to the ADX that way.

[SappySE107]

cause I don't know what is what I see load, import, edit, new, and recent under acquisition. I don't see save for the adx file so I assumed it was part of the xdf.

[robertisaar]

why upload the XDF? the ADX is what you changed.

[SappySE107]

nAst1 1.04 BP.xdf

I made a few new histograms and monitors. I use the monitor for spark now, so I can see when there is KR and not just avg or min or max or whatever. The INT is for after BLM is good and locked. I was using the STFT but this last go around I wanted to see something familiar and do it by hand rather than the auto tune file.

[SappySE107]

Those articles are discussing 30k feet+. For 99.99% of us, the MAF is going to see a linear rate for air mass and oxygen. Im not driving to the top of Mt Everest .

[robertisaar]

so.... "inspired oxygen" drops as altitude rises, but it sounds like the actual mixture of air contains the same amount of oxygen regardless of elevation.... so the MAF should take care of it on it's own. i guess if it doesn't in the real-world, i'll have to patch a patch to add in barometric compensation.

[SappySE107]

http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1114067/

"Although the percentage of oxygen in inspired air is constant at different altitudes, the fall in atmospheric pressure at higher altitude decreases the partial pressure of inspired oxygen and hence the driving pressure for gas exchange in the lungs. An ocean of air is present up to 9-10 000 m, where the troposphere ends and the stratosphere begins. The weight of air above us is responsible for the atmospheric pressure, which is normally about 100 kPa at sea level. This atmospheric pressure is the sum of the partial pressures of the constituent gases, oxygen and nitrogen, and also the partial pressure of water vapour (6.3 kPa at 37°C). As oxygen is 21% of dry air, the inspired oxygen pressure is 0.21×(100−6.3)=19.6 kPa at sea level.
Atmospheric pressure and inspired oxygen pressure fall roughly linearly with altitude to be 50% of the sea level value at 5500 m and only 30% of the sea level value at 8900 m (the height of the summit of Everest). A fall in inspired oxygen pressure reduces the driving pressure for gas exchange in the lungs and in turn produces a cascade of effects right down to the level of the mitochondria, the final destination of the oxygen."

[robertisaar]

I like the OBD2 MAF and MAP setup. I don't think a P4 can process all that though:P MAP based spark and MAF based fuel with MAP backup would be ok with me.

I am not sure on the MAF vs Altitude but I would guess that the engine will take in less air and thus, automatically correct no matter how high you get. Does the oxygen content of the air get less, or is the air simply less dense with the same % of elements? I figure its the latter.

that's the part i can't get a straight answer on.

if it is the air simply being less dense, then yeah the MAF itself will take care of it, i guess i could make the multiplier table and just leave all of the values at a mult of 1 regardless of barometric and it would be correct, but then i would need to waste time on an unnecessary 8 X 16 multiply... and taken up code space... guess i need to do some more research.

i COULD do a simple blend when the MAF - speed density(or speed-density - MAF) transitions take place, just keep track of the last BPW calculated, add it with the new BPW, div by 2 to make an average of them, then on the next cycle go with a 100% derived from one or the other BPW.



i guess it really depends on how lean i can make the MAF code as to whether or not they can be blended at all times.

[SappySE107]

I like the OBD2 MAF and MAP setup. I don't think a P4 can process all that though:P MAP based spark and MAF based fuel with MAP backup would be ok with me.

I am not sure on the MAF vs Altitude but I would guess that the engine will take in less air and thus, automatically correct no matter how high you get. Does the oxygen content of the air get less, or is the air simply less dense with the same % of elements? I figure its the latter.

[robertisaar]

the final BPW number that eventually gets sent to the injector register will only be from one or the other(speed-density or MAF, that is). it's possible to have one engine cycle be MAF and the next speed-density, but i'm not planning on blending the two, even though it is possible, since it would be redundant and eat up a lot of processing cycles.

basically, right before the start of BPW calculating algorithm, i'll have an option bit setup that will allow for MAF to be calculated instead of speed-density. MAF will likely be a faster algorithm to execute, but the program will only execute one or the other for a given BPW calculation. there will also be(adjustable) qualifiers that only allow MAF in certain situations, such as D-TPS since the last check cannot change too quickly or frequency cannot be too high or too low(i'll probably setup DTCs for these that will illuminate the SES light), stuff like that.



also: discussion topic: what effect does altitude have on MAFs? i've read conflicting information about oxygen content changing at different elevations, not sure if a barometric correction factor will be needed for the MAF.

[SappySE107]

I almost posted before that it would be great to have 3 bar and MAF at the same time but that seemed like a bit of overkill at the same time. That and I am not sure how much the computer can do at once.

[robertisaar]

also, for the MAF code, i'll be implimenting another table: injector flowrate vs MAP. the speed-density code in A1 may or may not account for this and rely only on the VE table to adjust for the fact that at lower MAP values, fuel pressure(and flow) decrease. then again, raw MAP may get used in the final BPW calc, i can't remember off-hand, but the point is: by design MAF doesn't know about MAP values, so MAP needs to be referenced to adjust the injector constant to account for different fuel pressure. if you unhooked vacuum from the FPR, then the same value in the entire table can be used, otherwise, lower injector flowrates need to be filled in at lower MAP values.

now, the question: should i make the table setup for 1BAR or 3? technically, 3BAR would be able to get around it by adding a touch more to the above atmospheric pressure BPW multipler table, but opinions?