Since more people have gotten setup on JCSBank’s speed density patch, I was wondering if it would be beneficial to do a 2.0 version that was based on suggestions that could help reduce some of the setup and tuning issues?

I don't think it needs anything real major, as it works pretty well as is. Just thinking of things that would make it easier to tune and slightly more versital.

One thing I’d like to see is separating out the MAP calibration from the MAP based VE table. This would allow people to compare VE values directly, without scaling parameters and MAP sensors being an issue. It would also allow us to say “if you are using XXX sensor, use YYY values to calibrate for that map sensor,” and those values would be based on the sensor technical data and not experimental testing. Map sensors are VERY accurate and repeatable from one to the other at the resolution level we are looking at. Every Omni 4bar should fit a given curve, just as every JDM 3 bar fitting a different curve. All it would take for input values is an offset and a gain setting to cover just about every MAP sensor out there.

 

I figured some of the talk about 3D tables would make it over here to...

Just a thought, most standalones that use VE compensation actually have a fairly simple AFR table. Quite a bit smaller then the VE table, say 15 RPM x 12 MAP.

If a 3D table was introduced to help account for some problem areas (particularly at low throttle conditions where the losses due to throttling are signifigant) it could be implemented in this manner.

Changing the fuel map table scaling for a VE scaling and then setting up the additional 3D table as a target AFR table.

It really doesn't change much in the idea behind implementation. Just changes how things are tuned.

Then again though, the VE tables mess with the MAF frequency and that really isn't needed. If anything, on a MAP based system, you DO NOT want load to move around as you tune the car.

I guess implementing this way would actually just require a direct f(MAP,RPM)=MAF Frequency and then an additional multiplier table similar to how the main fuel table is treated.

Yeah, I think trying to go 3D may actually cause more problems because it will allow more dramatic changes in VE, which would then cause more dramatic changes in load -> more accel/decel comp... Probably explains why some have had success trying to patch up bad AFRs in trouble spots using the fuel map instead of using the VE tables. Using the VE table pretty much screws you over because it moves load around as you mess with it.

Anyway, just throwing out some thoughts. I've seen 3D tables mentioned, not sure if they would help or hurt.

 

Good point on the 3D table that I wasn't even thinking of.

When I tuned my SD setup a long time ago, I matched my loads perfectly from my maf based setup and drivability was perfect. The '3D' VE is really only needed for the RPM adjustments.

Maybe for now, keeping the two tables isn't a bad idea? I'm one for knowing 'true' load and mass airflow values though. Some don't seem to care though and tune for arbitrary load numbers. Both methods are fine as long as you know what you are doing.

 

Great Idea! !

We should possibly thing of doing 2.0 for the MAF based as well. There are so many particulars to get v7 to run well regardless of the format.

 

...

 

I don't think separating out the kpa vs map table is a good idea. I also don't think you will ever be able to compare VE values across the board. Depending on how different turbos spool I will alter my kpa vs map scaling to suit.

Right now I'd like to see 3d VE tables with rpm vs kpa if anything. The problem I find myself tuning around is my normal cruising area is say 3000rpm and 90kpa. However I can also do 25psi at 3000rpm going up a hill, so I have to make the kpa value to suit load at say 300kpa. Then you run into the problem where at 6000rpm and 300kpa the VE is different than it was at 3000rpm. So you are always chasing yourself a little.

THe hardest part is probably getting the car to go rich going into boost at low rpm but not running rich during low load cruising. This is why I would like 3d VE maps, even just a small one as that is all that should be needed. Most of my maps less load than kpa under 100kpa then make a hard switch to more load than kpa above 100kpa to help the car go rich.

 

As it seems 3D table would help you all i will dive into implementation of it,
but alfa release will follow only next week for testing 96531706, better said 96532706

 

How would a 3-D table be implemented?

Make the MAP Sensor table 1:1, then add a kPa axis to the RPM table and have VE% lookups.

or

Add a RPM axis to the MAP table, and drop the RPM table, and have Load lookups.

 

Edit: I started to comment before I really read what Ceddy was referring to. I will retract my answer until I can research further, as I have forgotten most of how the patch was already implemented, code-wise.

 

96532706 is already used for Live Mapping and 96533706 is already used for Live Mapping with SD.

This would prob. have to be something like:

96531806

OR

96534706

Any suggestions?

 

Ceddy, now that is the question isn't it. I guess I need someone to verify how the SD works at the moment. I think it basically simulates a maf Hz and load for the ecu so that it thinks it is buisness as usual. With that said a VE table would consist of RPM vs kpa. But how that would relate to making a simulated maf Hz and load value? IF the SD code interjects after the ecu does the internal calculations for Hz and load then I think this is the best place for a VE table to be inputted. The math would simply involve kpa, VE, and target AFR.

With more work with the SD in the coming springtime and racing months I will have better input. I think John Bradley's input would be good here.

 

The SD routine is actually pretty simple, its amazing JCSBanks wrote it with so little code.

It emulates the MAFs signal (MAF ticks/rev)

MAP VE & Calibration[kPa] x RPM VE[rpm] = AirCounts [MAF ticks/rev](Also called MasterLoad)


Then in the normal code:

AirCounts / Time_Per_Rev = MAF Hz

AirCounts x MAFSize / 65536 = Load

So you can think of the SD code as emulating Load, even though its not its immediate output.


But table wise you can't just have a VE% table, you also need the Calibration table, its what transforms kPa into "Load".

I think a RPM x kPa table with VE% lookups, and the Calibration table locked 1:1(kPa:Load), is probably the ideal setup for 3-D tables.

 

Nice recap, Ceddy. Saves us the time to go back over everything.

On that note, I would agree with your suggestion. It will make it very easy to tune other load based maps as well (ie, fuel/ignition), since map will be locked 1:1 with load. Although we still run into the issue of the different loads (uncompensated, baro, baro+temp).

That was sort of the basis of John's 'easy speed density' tuning, where he locked map RPM 1:1 and RPM VE at 100% and use the maf tables as the VE table.

Edit: I wasn't thinking right. The load for the ignition and fuel maps would still be baro+temp compensated I assume? At least I hope. But the VE table would be easy to tune with this method.

 

1. Fuel & timing maps should be based of real KPa pressure, not the fake load or whatever it is now that makes it a pain to get the timing where I want it.

2. 3D VE map similar to the DS-Map Jackal one.

3. The idle, cold start and accel enrich issues dealt with so each of us don't have to screw around with them quite as much.

 

I was thinking in direction of VE[%]=f(RPM,kPa) lookup, and transform function AirCount[ticks/rev] = f(VE), as a first approach. Then we could have it tested, if the difficulty of tuning is acceptable, we could get rid of MAF calculation and go for pure SD.