Anyone here self-tuning with ECUTEK?

[tomm.brz]

that s subjective.. in closed loop is still ok a 10% error.. not a big deal

In open loop though i disable ltft and scale the best i can with 0% fixed ltft/stft on open loop

I do not use the speed density method they suggest, i use the vgi tool and then Manually refine

[Tatsu333]

After reading through the various threads here and info elsewhere on MAF scaling, I just wanted to put these thoughts down for reference - no feedback needed, but feel free to comment if you have a different take on it.

I remember reading in another thread here that some folks were worrying that rescaling the MAF would throw off the load calculations used for almost everything else in the ECU because it would essentially present the wrong data for the calculations and have the ECU use a higher or lower load cell in the fuel / timing / other tables than it should.

That didn't make sense to me, because one would logically think the load calculations use the output of the MAF scaling table (the airflow value) rather than the input (the raw MAF voltage) in the calculation, and scaling the MAF vs. LTFT's should theoretically make that output more accurate.

I think that rescaling the MAF via the MAF Scaling table was being confused with old school "MAF trickery" where you'd tweak the voltage output from the sensor to present different info to a non-programmable factory ECU to richen the mixture by making it think it was flowing more air than it really was - I.E. the input to the ECU was being altered so that it no longer accurately correlated with the measured airflow to "fool" the ECU into providing more fuel. Lots of piggyback fuel tuners work on this principle as well (presenting false info to the ECU by altering signal voltages), which is why they suck...LOL. Back in the day on some other platforms, though, this was one of the only avenues we had to try and get richer mixtures.

I do not believe this is what we're doing on this platform with MAF scaling vs. LTFT's.

In this case, the AFR "error" represented by the LTFT's suggests that the measured airflow value (again, the output value of the MAF Scaling table) is incorrect if we work on the presumption that the load calculation formula AND the formulae / tables used behind the scenes for injector pulse width for a given load/rpm are also good (since I don't think we can alter the latter, we have to presume they're correct). We fix that erroneous airflow measurement by rescaling the MAF so it is reporting the RIGHT amount of airflow for use in the load calculations.

Not sure if I'm missing something obvious here, but that's my understanding.

[tomm.brz]

you make it look like there is only one particular "engine load" curve to have, but to me that s not the case.. changing the maf or the speed density will of corse change the engine load values, but you can just adapt to it and adapt the tables accordigly

Thwre are tuner in US who strictly tune in speed density in open loop, to have always the same engine load. curve for similar car configurations, and they let the ltft + the ecutek closed loop fueling to correct the afr (even if it has huge errors), to do less work and have already a known AFR target and ignition timing curve

[Tatsu333]

Originally Posted by tomm.brz

you make it look like there is only one particular "engine load" curve to have, but to me that s not the case.. changing the maf or the speed density will of corse change the engine load values, but you can just adapt to it and adapt the tables accordigly

I totally agree with you that there isn't just one perfect "engine load" curve we should aim for.

What I'm saying is that I don't believe that rescaling the MAF is actually "changing the load" in a negative way. I.E. we're not trying to fool the ECU with false data, but instead using the AFR feedback from the O2 sensors (via the LTFT's) to ensure that we're feeding the CORRECT airflow data to the load calculation. MAF Scaling done properly is ultimately a sensor calibration, nothing more.

Yes, it would mean that you end up in a higher or lower load cell on the other critical maps for a given MAF voltage, but you are ending up in the RIGHT cell because the correct amount of measured airflow is being used to calculate that load. The old load value was wrong, because the sensor was not calibrated correctly.

Now, it's kind of a simplistic example, but think of it like having a thermometer that only reads 90 degrees C / 190.8 degrees F when water boils at sea level. If you recalibrate the thermometer so that it correctly reads 100 degrees C / 212 degrees F when the water boils, you haven't changed the temperature of the water, you've just made the tool you use to measure the temperature more accurate, so if you specifically need 80 degrees C water for some reason, you can have more confidence that the thermometer is giving you the right info.

Sure, MAF Scaling *could* be used like the example I gave of the piggyback fuel tuners to intentionally feed false, higher airflow numbers to the ECU, but because we are able to work directly in the tables to set AFR targets, etc. and we have the feedback of the O2 sensors to see how close we are, there's no need to use such a crude method.

Again, this is all presuming that Subaru's calculations behind the scenes are correct RE: the injector opening time / pulse width needed to achieve the target AFR for each load / rpm. Since those aren't something we can edit, we just have to work with them as-is.

[Tatsu333]

OK - next question, this time about setup of RaceROM custom maps:

I'd like to be able to back-to-back test different cam timing settings without having to go through the reflash process while I'm out on the road, but unlike fuel and ignition timing, there aren't Mode 2-4 maps for cam timing.

To work around this and let me be able to test out my new cam timings by switching maps, I've set up RaceROM custom maps using the 30x24 custom maps A and B to output "Cam Angle Inlet" and "Cam Angle Exhaust", but I had to flip the X and Y axes to have enough cells to cover off the full RPM range, so the X axis is engine speed and Y axis is engine load. I don't *think* flipping the axes will matter, because it should still find and output the intended value for a given rpm / load. Am I wrong here - is there a problem with flipping the axes, or is it only the output value that matters?

I copied over the data from the "Cam Timing - Intake Low Det" and "Cam Timing - Exhaust Low Det" maps, transposing the X and Y axes when I pasted it, and then made the changes I wanted. To allow for the extra blocks at the end of each range and not create conflicts, I just extended the axis values out (rpm up to 8000 and load up to 2.0) and copied the values from the highest row / column across. I'm not sure whether I could / should have just left the unused ranges' axis values and cell values at 0 instead. Any feedback?

I've set both of them up to enable under Map Mode 2, with activation channel "unused" and set to always active (which I think means they will always be active when mode 2 is active). Is this correct, or should I use the activation channel "Mapswitch mode" and set it to be active when threshold values are between 2 and 2?

NOTE: This is just a temporary measure to enable me to switch cam timing maps via the 4-way map switching. Once I've settled on cam timings I want to stick with, I'll then just update the "Cam Timing - Intake Low Det" and "Cam Timing - Exhaust Low Det" maps with the new values and eliminate the custom maps.

Anything else I'm missing here, or should the above work?

[tomm.brz]

I Did something similar but i think it won t work, i Did it and it was always bugged, when the output of the custom map was set to "Replace the map output" referred to the cams

But you can try and see if your idea works

What should work though, is you use the output result as a maximum limiter or as a value to add or. remove to the main channel
Meaning, you could set a table with a custom input in an axis and engine load in the other and for +1 of custom input, you set +1 of intake cam, for example

[Tatsu333]

Originally Posted by tomm.brz

I Did something similar but i think it won t work, i Did it and it was always bugged, when the output of the custom map was set to "Replace the map output" referred to the cams

But you can try and see if your idea works

What should work though, is you use the output result as a maximum limiter or as a value to add or. remove to the main channel
Meaning, you could set a table with a custom input in an axis and engine load in the other and for +1 of custom input, you set +1 of intake cam, for example

Interesting...OK, I'll try it as-is first (replacing the output), and if that doesn't work, I'll re-work the custom maps as an overlay of sorts that will add to the main channel.

EDIT: Actually, I'll set up the overlay / add to output option to run on Mode 3 so I can test and log them back-to-back-to-back. I have at least a couple more days before I'll be able to drive again (due to a foot injury), so I've got the time...LOL.

EDIT #2: Crap - there are only three 30x24 custom maps available, so I can't do two full maps for intake and exhaust cam timing simultaneously. So much for that idea...or maybe not!

I guess since I'm just overlaying the output and I haven't modified more than an 8x12 section I don't need to overlay the full map. I'll use a couple of the 12x8 custom maps for the overlay option instead.

Thanks again for your feedback!

[tomm.brz]

Any of these idea of course sound good, because one would presume any input, output, axis value, settings etc etc that ecutek provide to us to modify, would work exactly as intended
But unfortunately not everything work

Try&See

[Tatsu333]

Originally Posted by tomm.brz

Any of these idea of course sound good, because one would presume any input, output, axis value, settings etc etc that ecutek provide to us to modify, would work exactly as intended
But unfortunately not everything work

Try&See

Yup - I see a LOT of tweak, test/log, repeat in my future!

[tomm.brz]

about the activation, you were just right with the enable tick only on a specifico map to work and keep activation channel unused, that s enough and it will work

[Tatsu333]

OK - so, a couple of notes from testing the custom maps for cam timing:

• The custom maps that used overlays to ADD to the existing channel output DID NOT work as intended, with pretty erratic results in terms of the cam timing targets that didn't really reflect anything close to what the results should have been. It felt weird too, and with the timing all over the place, it was basically no faster than stock (only about 0.04 seconds from 3000 - 7000 rpm on the pull).
  
  
• The custom maps for cam timing that had full maps that REPLACED the existing channel output DID work as intended, and the actual intake and exhaust cams tracked the targets quite well. There was a whopping 1.3% improvement (LOL) in the time it took to go from 3000 - 7000 rpm on the pull vs. stock.

Now, is that teeny, tiny gain repeatable? Who knows. Considering it was a pretty conservative change, I'll take a gain of 0.12 seconds and the fun I had learning.

[tomm.brz]

good job buddy