Cool, I didn't mean for all of them. Maybe just one or two like ECM Link does.

 

Quick question - Are you guys looking for a scenario where load = boost and then VE is only used to tweak fuel and not the load calcuation?

 

That sounds like that will be much easier to tune. But as far as I understand that scenario will make everything boost-related, and the current SD is an attempt to make everything airflow-related. Am I right?

 

1. I'm all in for subsidizing the development of new software. We can't expect $0.99 apps with free updates for life. [Hey Hamid@EvoScan, this includes you too. There's so much that can be done with your product..!]

2. I pretty much agree with 03whitegsr in that it's a LOAD based ECU and should be kept that way. What's missing is that most people don't seem to think of LOAD as cylinder filling. 0 is an empty cylinder, 100 LOAD is a fully filled cylinder, 200 LOAD is a double full cylinder. It then makes sense that as LOAD increases you're going to want to add more fuel, and likely need less timing to burn it. From there we can see that it's okay for the timing table to be affected by the 3D-SD table (VE or LOAD translation). If LOAD at a given RPM/MAP point goes down, cylinder filling is reduced, and therefore you probably want some more timing.*

3. From the comments it appears most people are going to be more comfortable with entering LOAD into an RPM vs. MAP table. Isn't it really the same data to the ECU either way... VE is just a transform being displayed to the user as [LOAD/MAP]? Seems like there could be a toggle that simply displayed the data either way. Maybe just another line in the .xml file? [ME waving his SW hands in the air.]

4. On the topic of logging a MAF car to get LOAD[MAP, RPM], is the value EvoScan logs pre- or post-molestered by all the other correction tables? From what 03whitegsr posted it seems like the numbers might not be all that good especially at low loads which would make filling in the 3D-SD table harder.

5. I can't resist but to inquire if eMAP is being considered in the LOAD calculation? Was a strong influence ever seen in the logged data? If implemented, it could have some odd consequences in these tables if they were built with LOAD(3D-SD[iMAP-eMAP,RPM]).

 

Load or VE - My impression is that some people would like to have VE adjust fuel only, but I could be wrong. I asked for clarification, but didn't hear back.

A challengine with using emap is that it complicates building the load translation table from MAF data. I haven't given any thought to how I would implement it. My first thought of having an emap multiplier on the translated data would be odd. In that case the load table translation would be somewhat of an idealized table, but it would still include VE, so it would be totally idealized. Sounds messy, but I am interested in trying to do something.

 

Ve fuel only for sure. I guess? That's how I thought of it working to begin with. But how does timing axis get adjusted?

 

AFAIK By changing VE you change load at certain rpm and boost, moving to other cells of the map. Fuel and Ignition. VE represents relation of Map sensor KPA to Load axis. Load axis=KPA*VE.


If you are hitting 25psi of boost (~270kpa absolute) at 3500rpm and you have 100%VE in VE table at this load and rpm - you hit 3500rpm 270load cells in your Ignition and Fuel map..

Now if you adjust your VE to 110% at 25psi boost (~270kpa absolute) at 3500rpm - you will hit 270*1.1=297load at 3500rpm in your Ignition and Fuel map.

Correct me if I am wrong.

 

Doesn't the Subaru 32bit implementation somehow use airflow for fuel but another variable as the lookup for timing? I think that's what mrfred is getting at. not sure never tuned one just looked at the ECUfLASH maps.

 

Yes, a VE table that only affects fuel would be nice.

 

Has there been any developments with this? I would gladly donate towards a new (easier) style of SD tuning.

 

So would I.... waiting on mrfred.

 

While I know this can be "achieved" scaling the SD MAP Calibration and keeping your RPMVE closer to 100%.. I feel like setting it up as you stated would be most ideal and easiest to understand. It's frustrating for the people that feel like the Fuel Map is not "arbitrary" values so we scale the RPMVE table to get our Wideband AFRs in line with the Fuel Map, but then we jack up the load values we hit.

This thread brought up an interesting perspective though, if I'm understanding correctly, a lot of people adjust the SD MAP Calibration to set your boost inline with load, keeping the RPMVE roughly around 100% only adjusting for small fuel changes, and using the MAF scalings to adjust fuel to reach target AFRs outlined in the Fuel Map. Please correct me if I'm misinterpreting.

 

Hey MrFred, any update on your work here? Surely a bunch of us are very interested.

 

I wanna get it done, but too damn busy with my job.

 

Since I finally want to try SD in my own Evo, I've made significant progress in the last few weeks on finishing this. For this version, I have decided against using MAP in place of load because I like a true load model.

Besides 3D SD, are there any other features people would like to see incorporated? I'm only asking for SD. Here's what I've already done:

1) I believe that I have the stutter issue fully fixed.
2) Simplified integration of MAP sensors. All that's needed is a slope and offset. No need to mess with any of the OBD MAP sensor values anymore.
3) Baro compensation for idle and whereever else its needed. However, I have removed baro compensation from the OEM load calculation since SD intrinsically accounts for baro in the load calculation.
4) For the self-tuners who are still on MAF and want to covert to SD, I will add a means to log and adjust SD load while still on MAF so as to simplify building the SD load table.
5) The 3D table will be available either as a direct load value or a VE.