RomRaider

Here, this might help.

This is how you can add "VE" to your existing logs based on IAT, MAP (psiG), RPM, and MAF g/s.



Replace 14.35 with the absolute pressure you see in your area. This is for IAT in Celcius. You can replace the (D2 + 273.15) with ((5/9)*(D2-32)+273.15) for Fahrenheit.

Example spreadsheet.
http://freon.shackspace.com/car/ecu%20a ... _ve_01.xls

This is the best way to see your VE. You can add this to old logs, and just scroll through the log while working on your VE map and put the VE value in at the closest matching RPM and MAP point in the VE map.

If you can somehow go back and do some sort of bucket-ized pivot table on axes MAP and RPM with data VE you could "see" your VE as logged and almost copy/paste it into your map. It should work out almost perfectly this way. Ecuedit has a custom graph utility that does this for you (not adding VE to the CSV, that still takes Excel or adding the equation to a custom logger item, but it does the statistical averaging and bucket-izing), but you can probably do it in Excel somehow.

Yea,thanks! I used excel and a graphing tool and mapped out my ve. I was using incorrect g/s data in your spread sheet. I was using more g/s around idle to compensate for a cai. I think if my latency was more in line that my g/s in the maf wouldn't have been off in the spread sheet.

Question, I've been told this sd map won't work with a gm 3 bar map sensor. Any truth to this and if so why??

Who told you that? Can they post here?

It was third party info. He thought he read that on this forum. I think he just misunderstood what he read. I just had to ask you as I have a 3 bar map. I couldn't see any probs with it.

I use a Zeitronix 3.5 bar MAP sensor with the sd code. Works. Can't imagine why the GM wouldn't work.

Well, I was fishing because I'd like to know why this person thinks it would not work. Hey, I could be missing something.

There is no reason any MAP sensor that can be calibrated with the factory ECU would not work with this code (i.e. anything with a linear response to absolute pressure, MAP = A*voltage + B) . If it were to not work, it would imply the sensor wasn't reading properly with the ECU anyway. If you can log a valid, reasonable accurate MAP value it would work.

I am using the MAP value in immediately after conversion from analog to digital and conversion from a 16bit integer to floating point Torr (mmHG). That value cascades to all uses of manifold pressure in the entire ECU. If it won't work for SD, it likely wouldn't work for things like boost control.

I suppose there is some subtlety with regards to how fast the sensor reacts to change (i.e. slew rate), signal noise issues, or quality problems, but I'm pretty confident this will work just fine on any MAP sensor of reasonable quality with proper MAP calibration.

I really really really really really really need this for my '05

Another user on this board and I have talked frequently for the past few years. He's running this on his '04 and it has cured all the problems that we have been trying to battle with regard to the FMIC rich spike (as hoped and expected). I really want this but don't have the time/experience to port it.

t

Freon, would the lc and ffs work with this rom??

I asked this on Nasioc on the lc/ffs thread, and got this reply...

http://forums.nasioc.com/forums/showpos ... stcount=79

Couldn't find this idea posted before, think I should ask there...
There are 2 tables in MAF section
- Engine Load Compensation (Manifold Pressure)
- MAF Compensation (Intake Temp)
If these 2 applied properly, accurate tune can convert MAF measurement to SD in way like this:
1. Blowthru MAF location for temp readings
2. MAF Scaling Table Filled with constant values.
3 Engine Load Compensation (MP) rescaled & calibrated
4. MAF Compensation Table (Intake Temp) calibrated

Again, I don't know will this work, there are few possibilities it willn't
- Some logic uses MAF g/s's.
- Corrections are not applied under all circumstances

I don't think ur idea will work because mafv is still being used. With this rom mafv has been taken out of the equation.

Well, I've already presented a solution that is much, much more powerful than what you propose. Not that what I've produced is the only way to do it, but it is one of only two or three alternatives that I feel are truly viable.

I did look at the engine load comp table before and had thought about reusing it as the VE table, but it doesn't make sense since I rearchitectured it anyway. If you're going to hack in new code might as well do it right and design it exactly the way needed.

Like you said, some logic uses MAF g/s. I took great care to only come up with a new way to produce the MAF g/s number so the remainder of the ECU will now know the difference between having a MAF g/s coming from the MAF sensor or an SD calcuation. Fuel trims would be the #1 problem.

I think to make this work like you think you'd have to hack in new code anyway. At that point, why bother when this is available? It would take less effort to port the source code I've posted to another ROM than it would trying to make this work. But, I'm not stopping you either.

In other news:
I've now been running SD over a year and a half. Still running strong, still running the same code as originally designed. I do think I've spotted a few minor issues with VE right after shifting, possibly VE being affected by the turbo's speed and sucking air through the engine, or something with fast changes to MAP, or the AVCS lagging a bit, but it is pretty minor. I'm thinking of finally putting in the dyn_def back into the code on my car to see if that will help a bit. I've started on the 05 STI and 06 STI, honest. They will be released some time this summer at least.

I noticed the same thing. I have a wideband gauge on my cluster and can see it pretty clearly. It is very fast, but it is there.


What is this?

I put in a 2D compensation map into the code, you can see it in the source code. It just adjusts the value based on whatever input. It can easily be changed to compensate against any available floating point value stored in memory, but I had originally intended to use delta MAP or delta throttle.