Mixture Map

[RyanG]

A couple of notes I made while using the mixture map that I thought would be worth looking at. Feel free to discuss, there's likely reasons why some aspects are the way they are, but I thought I'd share anyway.

- CLL corrected lambda channel would be handy to have, without having to use a math block. I feel like mixture map is something people use while sifting through large logs from a period of driving that wasn't an active tuning session, so for most people I assume CLL would be active.

- Percentage of change towards target. With ECUmaster a friend says he can choose the percentage of change, so if mixture map calculates it needs another 2% in that cell, if you select "50%" it will adjust it by only 1%.

- Lambda delay. Transport delay to the sensor is obviously going to effect mixture map readings. I'm not sure what the best way is to tackle this, but it's something that needs to be considered while using mixture map at current.

- Additional filter slots would be a really big help. I flick through a couple different conditions/filters to see which is playing the largest role for that log, but it would be nice to have them all included.

- This could be an alternative to the above, but would be awesome to have both. The ability to use multiple "<" or ">" signs for a condition parameter on a single filter. Eg., "70C < ECT < 95C" or "-5% < TPS Delta < 5%", etc.

- The highlight range doesn't seem to save, it always goes back to 0.27La.

- Ability to apply all changes with a single click. If there was a greater level of filtering this may be handy.

- Ability to ctrl+z mixture map changes. Maybe I'm missing something, but I can't seem to undo a change after applying a mixture map correction.

- Lockout for engine cuts? Can use CLL < 9.5 I think, but already limited on condition slots.

- Transient filters are units/s, but TPS and MAP delta channels are units/100ms? I think units/s makes sense for most other channels, and ideally I'd use a conditional filter for TPS and MAP delta seeming they are already logged, but can't really do this if restricted to 3 conditional filters. Which means I then use TPS and MAP as a transient filter, but it's a different unit scale.

- Ability to use either a zoomed in section of the log only and/or the ability to trim log files.

 

[mapper]

good suggestions
I would also add a time delay to each filter setting. So for example when transient rpm was detected, mixture map sampling is delayed by X secs or better engine cycles until Lambda reading has stabilized

 

[Vaughan]

On 3/9/2023 at 1:13 PM, RyanG said:

CLL corrected lambda channel would be handy to have, without having to use a math block. I feel like mixture map is something people use while sifting through large logs from a period of driving that wasn't an active tuning session, so for most people I assume CLL would be active.

Would something like this be suitable where you can select a percentage fuel trim runtime to 'remove' from the mixture map (i.e. if this trim is adding 20% fuel the lambda value at that point in time will have 20% added to it so that Lambda value displayed is what the lambda would have theoretically been if the trim was at 0%)

On 3/9/2023 at 1:13 PM, RyanG said:

- Percentage of change towards target. With ECUmaster a friend says he can choose the percentage of change, so if mixture map calculates it needs another 2% in that cell, if you select "50%" it will adjust it by only 1%.

Not sure how much value I see in this but will look into it.

On 3/9/2023 at 1:13 PM, RyanG said:

- Lambda delay. Transport delay to the sensor is obviously going to effect mixture map readings. I'm not sure what the best way is to tackle this, but it's something that needs to be considered while using mixture map at current.

Best way to tackle this is to use the conditional filters to remove transients

On 3/9/2023 at 1:13 PM, RyanG said:

- Additional filter slots would be a really big help. I flick through a couple different conditions/filters to see which is playing the largest role for that log, but it would be nice to have them all included.

What filter conditions do you normally use and what would you want to use in addition to your current filters

On 3/9/2023 at 1:13 PM, RyanG said:

- This could be an alternative to the above, but would be awesome to have both. The ability to use multiple "<" or ">" signs for a condition parameter on a single filter. Eg., "70C < ECT < 95C" or "-5% < TPS Delta < 5%", etc.

For more complicated filter setups if you know what filtering you want ahead of time you could setup a gp output, gp pwm or mathblock to create an easy to use conditional runtime.

On 3/9/2023 at 1:13 PM, RyanG said:

- The highlight range doesn't seem to save, it always goes back to 0.27La.

will look into this

[RyanG]

On 3/17/2023 at 8:48 AM, Vaughan said:

Would something like this be suitable where you can select a percentage fuel trim runtime to 'remove' from the mixture map (i.e. if this trim is adding 20% fuel the lambda value at that point in time will have 20% added to it so that Lambda value displayed is what the lambda would have theoretically been if the trim was at 0%)

Yep, that's basically all I'm doing with a math block (and then using that as the lambda source).

On 3/17/2023 at 8:48 AM, Vaughan said:

For more complicated filter setups if you know what filtering you want ahead of time you could setup a gp output, gp pwm or mathblock to create an easy to use conditional runtime.

Hadn't thought of that actually. Will have a play and see what I can come up with, thanks.

Also I agree with Mapper, a reactivation delay for transient filters would be awesome. Perhaps CLL status as a conditional filter is sufficient to achieve this.

[koracing]

On 3/16/2023 at 2:48 PM, Vaughan said:

On 3/8/2023 at 4:13 PM, RyanG said:

- Percentage of change towards target. With ECUmaster a friend says he can choose the percentage of change, so if mixture map calculates it needs another 2% in that cell, if you select "50%" it will adjust it by only 1%.

Not sure how much value I see in this but will look into it.

The make changes by half or applying a percentage to the change can help in overshooting a target and is present in HP Tuners for example.  I personally use a somewhat complicated excel sheet to do this stuff for me with all the multipliers and filters in place, but it would be really nice if it was built in.

[DerekAE86]

On 3/21/2023 at 11:05 PM, RyanG said:

Yep, that's basically all I'm doing with a math block (and then using that as the lambda source).

 

Can you share this math block please?

[RyanG]

23 hours ago, DerekAE86 said:

 

Can you share this math block please?

a = Lambda 1
b = LTFT
c = STFT

a+((b/100)+(c/100))

Obviously need to be mindful that it wont be accurate during transients due to transport delay.

[DerekAE86]

9 hours ago, RyanG said:

a = Lambda 1
b = LTFT
c = STFT

a+((b/100)+(c/100))

Obviously need to be mindful that it wont be accurate during transients due to transport delay.

Does this actually work though? I wouldn't have thought the % adjustment being applied to the fuel trims would be 1 for 1 the same % the Lambda source needs to be adjusted by to "undo" the result of the fuel corrections.

[RyanG]

6 minutes ago, DerekAE86 said:

Does this actually work though? I wouldn't have thought the % adjustment being applied to the fuel trims would be 1 for 1 the same % the Lambda source needs to be adjusted by to "undo" the result of the fuel corrections.

Seems to. That's the whole point of using Lambda right? Percent change in fuel results in a equal percent change in Lambda (if injector data is correct).

Unless there's something else I'm missing?

[koracing]

On 3/29/2023 at 5:33 PM, RyanG said:

a = Lambda 1
b = LTFT
c = STFT

a+((b/100)+(c/100))

Obviously need to be mindful that it wont be accurate during transients due to transport delay.

One problem with that math is that 10% of .8 lambda is not the same as 10% of 1.0 lambda.  It would still be close but ideally you would modify your math as follows:  a*(1+(b/100)+(c/100))

[Electredge]

1 hour ago, koracing said:

One problem with that math is that 10% of .8 lambda is not the same as 10% of 1.0 lambda.  It would still be close but ideally you would modify your math as follows:  a*(1+(b/100)+(c/100))

this is what I usually use but math ends up with same result

[koracing]

The lack of parenthesis in that equation hurts my brain a little.  The math comes out ok on that?  And your label says "without CLL" but it looks like you're adding it in in the equation?

[DerekAE86]

3 hours ago, koracing said:

The lack of parenthesis in that equation hurts my brain a little.  The math comes out ok on that?  And your label says "without CLL" but it looks like you're adding it in in the equation?

I assume it means "What Lambda would have read without the CLL correction"?

[koracing]

Good call.  That makes sense.

[RyanG]

Thanks guys, I've updated my formula to match!

For reference; at 0.8La, 2% ST and 2% LT you should get 0.832, but I was previously getting 0.84 in this example.

This error also translated into my "VE% Required Corrected" math channel. Which is: ("Corrected La" - "La Target" + 1) * "Fuel Table 1"

[koracing]

I'm going to try using this with the mixture map - seems like it could be decent and easy enough to implement. 

Beyond that, I think it should be possible to use further math blocks to apply the difference from target at some fraction of the total if the measured value is richer than target, but 100% of the total difference if it's leaner.  I'll have to play with this idea a bit...

[RyanG]

4 minutes ago, koracing said:

I'm going to try using this with the mixture map - seems like it could be decent and easy enough to implement. 

Beyond that, I think it should be possible to use further math blocks to apply the difference from target at some fraction of the total if the measured value is richer than target, but 100% of the total difference if it's leaner.  I'll have to play with this idea a bit...

I haven't used mixture map all that much, I still make changes manually by going through logs which is getting a bit time consuming. I felt it was a bit limited in its filtering, but I'm going to have another look at it this weekend using GP outputs and math blocks as filters to see if I can get good results.