Magnumpsi

iTrader: (2)

I think for a lot of people it would make more sense to have it based on MAP and RPM. It is easier to read and log and understand, especially when you have a solid method for datalogging accurate boost levels as well as Barometric pressure.

I for one would love to see it done with seperate tables for baro additions in fuel and timing. For people that live up in the mountains there is always a change in altitude and it would be nice to be able to adjust, rather than just have the ECU run off the same tables and try and do it for itself. I would imagine that the barometric pressure segment would have to be changed and it would be nice if the user had final control.

The other thing that I think you may have to watch is a lot of systems like the AEM that you run a boost comped map on has a Boost Fuel Correction that helps to dictate fuel to always be linear. This could be beneficial or not depending on what route you end up taking.

Just ideas,


Mitch

tephra

iTrader: (6)

Yeah the VE table definitely needs to have RPM AND MAP as the 2 axis's - I don't think there is any argument to that???

That just leaves FUEL and Timing.

I think using MAP as the axis for F+T is a bit of a 'cop out' - I mean its not a true representation of how much fuel you want, since the temp correction (although it will be linear) occurs later.

Happy to choose the general consensus option thou

tephra

iTrader: (6)

Mitch - sorry you replied to quick

Isn't Baro somewhat irrelevant? I mean you are measuring MAP and IAT (CAT) post turbo, so you now know what pressure the air is at.

Really having a baro only gives you a psi in terms of atmo for boost targeting, ie if your atmo psi is 10psi (high mountains anyone) then to hit 25PSI you turbo needs to work 4.7 psi harder than at sea level.

From what I can see (could be wrong here) baro won't affect fuel or timing

Magnumpsi

iTrader: (2)

Yes I guess with enough backups you could. It really would not hard to just figure out density of air with IAT and then make tables that can trim based off of IAT vs Fuel.

Most SD systems out there still have Barometric Pressure and it adds user adjustability if you find you need to make small changes. The big thing is Mitsu spent a lot of time working on the Baro tables and in theory they will all be gone or changed and it will take a bit of tuning to get them right, even if you just base them off of IATs.

Mitch

tephra

iTrader: (6)

I am confused.

Baro is just air pressure right? So how is a MAP sensor different to Baro apart from range of measurement?

MR Turco

iTrader: (16)

Tephra have you PM'd mixmastermix, now Tuner@Swift, and see if he can tell you how Bez's system works?

tephra

iTrader: (6)

I have him on email but I havn't asked him too much.

I wanted to sort of do this for my self without stealing Bez's work if you know what I mean...

l2r99gst

iTrader: (2)

I think one major point that a lot of people are missing is that the stock ECU already has g/rev as the axis for it's fuel and timing tables. That's what our load is. Someone just chose to use an arbitrary number for load, probably because they didn't completely understand, they were following OBD based loggers, or they didn't know the exact units.

Most speed density setups has MAP as an axis simply because it makes it easy for a lot of people to understand. Does that make it right? I don't think so, but again, this is just my opinion. For the person that said you would be transversing the cells diagonally at a constant boost...yes of course, that's how most of us transverse the cells now. It's because of changing VE with RPM, which changes your mass airflow/rev.

Remember, mass airflow through your engine is a function of RPM, VE, displacement, pressure, and temperature. If you use g/rev as the axis (like our stock ECU does now), then you are taking all of those variables, except VE, out of the equation. All we would need is an adjustable VE table.

If you use MAP, then you need tables that need to be adjusted for all of those variables and we'll be getting a million posts by people saying 'what is you timing/fuel at 22psi?'. And of course, there is no answer to that...it depends on your mass airflow/rev. So, we need to know your RPM, the temp, the absolute pressure.

Now, if you said, I am running 3g/rev at 7000RPM, then that tune can be compared from car to car to car....the only changing variable is VE. Much easier to compare apples to apples and help each other with tuning, etc.

Again, it's a difficult concept to grasp by some people, and I even see people (good tuners) state that the axis in the fuel and timing maps are kpa. It just shows that they don't understand what mass airflow is and what it means to the ECU in calculating fuel requirements.

Anyway, enough of my babbling. I'm sure there are advantages to both ways and probably a ton of stuff that I am missing for either way. I think it would be great to have a speed density option, no matter how it is developed, for our stock ECU.


Eric

03whitegsr

iTrader: (8)

Yeah, RPM is for total airflow, I was just in a bit of a hurry and thinking of VE being RPM dependent so it accidentally ended up in there.

That map is a good example of some tuning that I have seen that is incorrect for the maps being used. The VE table looks dramatic because it is showing very low VE at low MAP values and high VE at high MAP values. However, this really isn't the case. If the Boost Enrichment vs. Map table was setup based on the ideal gas law, you would find that the VE table no longer sits at an angle, but would sit flat with a hump in the center where true engine VE peaks. That table is very similar to what you would see on an IPW table. To me, I dislike that type of table because it doesn't match reality. The motor is not 132% VE at 2 atmosphere of pressure simply because it is ingesting that amount of air. It is ingesting 2 atmospheres of air at ~66% VE.

But if we are recoding the major parameters of the ECU to support MAP based operation, why stick to what the factory uses when it was obviously designed around a MAF based system? If sticking to load makes more sense on other operations besides the main fuel and ignition tables, I can see this. But to me, if you are just trying to add on additional code to convert from Map to load, you may as well just pick up a MAFT Pro. I think recoding the ECU in the end for a true MAP operation would be much more beneficial. However, I also realize that it may be more practical to approach it in the manner you have suggested simply because it may allow for easier integration with the other functions of the ECU.

It seems odd to me that you would prefer to be limited to load and trying to incorporate VE and every other correction into the calculation before you tune. Then to have a VE table on top of this that adjusting will completely change your load which in turn will change where your tune is on the main fuel map. Seems like a quick way to end up chasing your own tail?

Why limit the capabilities of the ECU simply because a few people don't want to take the time to understand what they are really doing? Further, there is more then 1 way to get 3g/rev. Low boost high VE, high boost low VE, cold temps, warm temps...every single one of them will need different fuel and timing settings so just because a car has a given airflow/rev it does not mean you can give any kind of real answer about what kind of timing or fuel it needs.

I came from DSMLink so I knew almost right away what the load axis was really about. I pretty much just divided by 100 to put the load numbers into a number I was familiar with. DSMLink is also just about the simplest system out there to use and tune and it has great mass appeal. I know you also came from that area so I think I get where you are coming from. However, personally, I thought DSMLink was terribly limited on capability. It made it easy to get a decent running car, but once you got to a certain level, it was like you were playing around with piggybacks again (fake MAF, MAFComp, etc.)

I will say this though, I can't agree more, I love the idea of MAP in the stock ECU. Also if somebody could write up a GUI that worked like DSMLink where the main item of the software is not the tuning but the datalogging, I would be in love. I hate jumping between several different programs to tune a car and usually ending up with communication issues with each program. Getting the sample rate up there like DSMLink would be awesome too.

justboosted02

iTrader: (31)

yes +1

l2r99gst

iTrader: (2)

Yep, I came from DSMLink as well. That definitely helped in understand a g/rev value. I do agree that DSMLink was limited, too. Most of that limitation, though, was because of the simplified menus that Tom and Dave provided with the interface. We couldn't actually change individual cells in the tables, etc. There mafcomp, fake maf, etc, was there simple solution to a condition-based speed density type setup and I agree it wasn't a super-powerful tuning tool, but they made it very simple and easy to use, so the masses could at least understand. And this, at least, enabled people to use SD in a range where the stock MAF wasn't reliable.


As far as the rest of your post, I think we generally agree that it would be great to have a SD patch for our Evo ECU, but I think we differ in our opinions about the g/rev or map axes. All I am saying is that if using a g/rev axes, then we incorporate many of the variables already, rather than using many other tables to tune for those variables. Mitsu didn't do this because it was a MAF based system...they did it because it logically made sense to do it that way. Heck, it was difficult for Mitsu to get from a Karman Hz value to a mass airflow/rev value. Take a look at mrfred mass airflow patch for 88590015 that I just ported over to 96940011. It shows you all of the calculation that go into it. But, the meaning behind it is now you have a number that can produce an IPW that you need and that number is part of your axis.

You know, as well as I do, that a simple map axis really means nothing in the ultimate goal of IPW calculation or timing calculation and accomplishes nothing except and easy to read human interface. That's it. What we are really after is a mass airflow value, so that other values like IPW and timing can be applied to that. That's why Mitsu had the tables setup like that in the first place.

So, I guess the ultimate question is simply do we make it nice and legible and use MAP as an axis because everyone know what boost is or do we make it a g/rev value for the axis because that is what the main maps need to use anyway? It's all a matter of preference and what your comfortable with and what the data means to you.

03whitegsr

iTrader: (8)

Yeah, I agree complete on speed density implementation being the key goal, and I'll use it either way it comes out in the end.

I agree that, generally speaking, an airflow/rev number is slightly more meaningful on tuning, since it is a better indicator of cylinder pressure. However, like I said, you can end up at the same load through very different means and I think this will make tuning much more complicated. With the method most MAP systems use, the VE table would more or less be a constant (on a given setup) and any tuning issues would be resolved in the compensation maps and AFR map. With the way you are suggesting, it seems like you could run into some issues where ambient condition changes will require you to change the "MAP to load" table. This in turn messes with where you fall on the load table, changing your tune again and forcing a remap of the load table.

The Hydra Nemesis tuned by Element Tuning for the Subarus is actually somewhat setup in this manner. To simplify setup, they decided to use the factor MAF sensor as the IAT sensor and just left it connected but exposed to free air. Thus, instead of using true air temp correction, they effectively built in the intercooler efficiency into the main fuel map. On a friend’s car, we went over to a true charge air sensor and it absolutely destroyed the map. The entire map had to be redone. But in the end, it made for a much better and more consistent running car and changes in external mods did not affect the tune unless them changed engine VE. When you start to account for multiple variables with one lump sum parameter, I think you get in trouble. Yes, it can be easier to setup initially. But in the end, I think it causes more problems then what it is worth. There are some very simple equations that govern air mass in an engine. While you may end up with a few more additional maps, and some additional back ground processes in the ECU on the method I am suggesting, I think in the end, it provides a better solution.

I personally believe tuning is simpler if you can separate engine parameter tuning from environmental parameter tuning. Doing the tables in MAP removes the environment from the majority of the tuning and merely applies a correction for the environment at the end of the calculations. Otherwise, ambient conditions will change where you find yourself on the LOAD table and environmentally changed load does not directly correlate to a given change in engine tune.

Either way, I think we would end up with the same tune. I just feel it would be more straight forward to tune with a MAP based axis system. Once you establish compensation mapping, it would be fairly constant between all cars. If the compensation is built into the load map, I think it would make it more difficult for people to compare maps and figure out where issues are really coming from. Like I mentioned though, if using load would greatly reduce the amount of work needed to implement speed density, I think it will work fine in the end.

l2r99gst

iTrader: (2)

I think we are on the same page, but I think you are suggesting that a map based map will help with environmental changes and I am stating that a mass airflow map will help.

For example, 25psi of boost at 200* intake temps results in a much different mass airflow/rev (load) than 25psi of boost with 30* intake temps (let's say middle of hot summer to middle of cold winter). With a map based map, you would have the same value of timing and fuel at that 25psi for both of those situations. That wouldn't work.

If you had a mass airflow/rev as the axis, like it is now, that colder temperature will result in a higher mass airflow/rev, so you will be in a different cell now. So, you can easily tune for any environmental changes, whereas with MAP as an axis you cannot. You have to use many other tables for those adjustments.

If you let the ECU do that calculation for you, providing the inputs of the IAT and MAP sensor, then you don't have to worry about it, so to speak. All we would need is a VE table to fine tune for modifications. The MAP table, on the other hand, is nice to use, since if you want to tune for 22psi, you just go to the 22 psi column, but whenever temps change, then your 22psi isn't the same anymore, in regards to timing and fueling requirements. You then need a separate temp correction table as well. But why have more correction tables than we need, when mass airflow can and is already being calculated by the ECU. Leave it simple and give us one table, such as VE, for modification changes and fine tuning.

mrfred

iTrader: (50)

I think the only way you'll succeed here is to use the MAP, CAT, TPS data to create a load variable, not only for the practical aspect of writing a patch without having to rewrite the entire engine control code, but as l2r99gst said, load is already an approx measure of airflow/rev.

I have a few other thoughts to toss out there:

1) Does the ADC conversion have sufficient resolution for good airflow resolution? Currently we are all using the 1-byte ADC conversion for the MAP sensor. This surely is not sufficient resolution. There is also a 2-byte conversion (availabe at r6 in the ADC routine), but it tops out at 1023.

2) The MIVEC system on the Evo 9 creates an additional challenge to creating a MAP-based system because it affects VE. At the minimum, you'll need to have an additional table that scales VE based on the current MIVEC value.

justboosted02

iTrader: (31)

I think you are really hitting the nail on the head in terms of setting up the tuning maps. I does not make sense to me to use MAP as an axis just for the fact that it is a poor indicatior of the actual airflow into the engine. with out the corresponding temp factor you have no idea of the density and actual mass of air flowing in.


I would rather have my map set up for g/rev simply because it will respond better to temperature changes and make the maps more robust